Bug#1019824: 3depict: Please transition to wxwidgets3.2

[D Haley]

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#990395: depends on deprecated qhull library

[D Haley]

Thanks for reporting this. Upstream (ie, me) has support for this, which
is now merged into the main branch (default, 8f9d2fe3d9dd).  This was
previously blocked by 925540.

Some build targets still use the old qhull library, so I will modify it
to support both old and new versions at configure time.


Thanks.

Bug#982939: RFS: libatomprobe/0+20210207-1 [ITP] -- Development files for libatomprobe

[D Haley]

Hi,

Firstly thanks for looking at the package.

I've updated the copyright file (MIT), and fixed the swig build error.
I've checked the build under cowbuild, and it works OK now. This was a
missed build-depend as I already have swig installed.

Thanks!

On 17.02.21 10:31, Adam Borowski wrote:
> On Tue, Feb 16, 2021 at 11:06:05PM +0000, D Haley wrote:
>>  * Package name: libatomprobe
>>Version : 0+20210207-1
>>  * URL : http://apttools.sourceforge.io/index.html
>>   libatomprobe-dev - Development files for libatomprobe
>>   libatomprobe0 - Library for processing Atom Probe Tomography (APT) data
> Hi!
> The copyright file misses at least Expat-licensed data/naturalAbundance.xml
> (Copyright (c) 2007, 2008 Metamolecular, LLC).
>
> Building fails with:
> CMake Error at 
> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 
> (message):
>   Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
>
> (Full log attached).
>
>
> Meow!

Bug#982939: RFS: libatomprobe/0+20210207-1 [ITP] -- Development files for libatomprobe

[D Haley]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libatomprobe":

 * Package name: libatomprobe
   Version : 0+20210207-1
   Upstream Author : my...@gmx.com
 * URL : http://apttools.sourceforge.io/index.html
 * License : GPL-3+, CC-BY-SA-3.0
 * Vcs : https://salsa.debian.org/science-team/libatomprobe
   Section : science

It builds those binary packages:

  libatomprobe-dev - Development files for libatomprobe
  libatomprobe0 - Library for processing Atom Probe Tomography (APT) data

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/libatomprobe/

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/liba/libatomprobe/libatomprobe_0+20210207-1.dsc

Changes for the initial release:

 libatomprobe (0+20210207-1) unstable; urgency=low
 .
   * Initial release (Closes: #982265)
   * Upstream revision 548:69015288bab7

Regards,

D. Haley

Bug#982265: ITP: libatomprobe -- Library for Atom Probe Tomography computations

[D Haley]

Package: wnpp
Severity: wishlist
Owner: D Haley 

* Package name: libatomprobe
  Version : 20210207
  Upstream Author : D Haley 
* URL : http://apttools.sourceforge.io/
* License : GPLv3
  Programming Lang: C++, Python
  Description : Library for processing Atom Probe Tomography (APT) data

 This provides a C++ library for the scientific analysis
 of real valued point data (x,y,z,value). This is primarily targeted
 towards Atom probe tomography applications, but may prove useful to
 other applications as well.
 .
 The package includes both its own C++ and SWIG based python interfaces

This package provide tools for processing mass spectra data from Atom
Probe systems, such as developed by Ametek. Functions in the library
include spectra processing algorithms, 3D point data computation, and
file IO routines for specific APT types.

It is anticipated that this will become a future dependency for the
existing 3Depict package. This is intended to be maintained as part of
the Debian Science team.

There are no other packages that provide the coverage of data processing
routines in APT, as this is specialised research equipment.

A sponsor is needed, to quality-check and ultimately for upload.

Bug#925540: qhull: add libqhullcpp to installed libraries

[D Haley]

Hi and thanks for the quick feedback,

> Normally we don't install static libraries in Debian. Shared libraries
> need to have SONAMES, and hopefully fairly stable ABIs. Do you know if
> those conditions are met? If so, it would need to be in a seperate
> package named after the SONAME.

Upstream's comment in their release notes are:
"Qhull's C++ interface is likely to change.  Stay current with GitHub.".
  [1] So, no there is no upstream SONAME, and the ABI is declared
unstable. However, updates to qhull are historically at most yearly.

As a downstream consumer of the library, this is unfortunate for me.

However, Policy (8.3) [2] is that the static may be installed,
particularly if the ABI is unstable, but doesn't really say anything
about not installing the static at all?

The current behaviour is - no static nor shared for the C++ interface,
but both for the C interface...

$ apt-file show libqhull-dev | grep 'lib/'
libqhull-dev: /usr/lib/x86_64-linux-gnu/libqhull.a
libqhull-dev: /usr/lib/x86_64-linux-gnu/libqhull.so
libqhull-dev: /usr/lib/x86_64-linux-gnu/libqhull_r.so
libqhull-dev: /usr/lib/x86_64-linux-gnu/libqhullstatic_r.a

So we could take out libqhull*.a, or add libqhullcpp*.a? Maybe I'm
missing something, and omitting libqhullcpp is a deliberate choice?

Thanks.

[1] http://www.qhull.org/README.txt
[2] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

On 10/10/2019 18:39, David Bremner wrote:
> D Haley  writes:
>
>>
>> The Qhull package does not install the libqhullcpp shared libraries. The
>> headers are installed, but the library is built statically, and does
>> not get installed.
>>
>> I have attached a patch against ea54d22bba5fb2cedf106a58bd11904370bfeb4f,
>> which changes the library to shared and adds it to the relevant .install
>> files.
>
>
>
> d
>

Bug#925540: qhull: add libqhullcpp to installed libraries

[D Haley]

Hi,

Just re-pinging this bug. I can try to arrange for an NMU if this is
acceptable.

Thanks.

On 26/03/2019 15:21, D Haley wrote:
> Source: qhull
> Version: 2015.2-4
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> The Qhull package does not install the libqhullcpp shared libraries. The
> headers are installed, but the library is built statically, and does
> not get installed.
>
> I have attached a patch against ea54d22bba5fb2cedf106a58bd11904370bfeb4f,
> which changes the library to shared and adds it to the relevant .install
> files.
>
> If the patch or similar is not suitable, and it is not desired to
> distribute the C++ library,  perhaps the C++ qhull headers should
> be removed?
>
>
> -- System Information:
> Debian Release: 9.8
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.9.0-8-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)
>

Bug#934859: undertime: Add major cities to available timezones

[D Haley]

Location to timezone seems to be supported by pytzwhere [1].

I had a quick play, and I was able to get most of those cities by
scraping the wikipedia output. Its pretty nasty, but it works about 80%
of the time, which is close enough. Some manual tuning should fix the
result.

This should be able to be fed into tzwhere -- however tzwhere is not in
debian :(


[1] https://github.com/pegler/pytzwhere

On 16.08.19 00:43, Antoine Beaupré wrote:
> On 2019-08-15 23:23:06, D Haley wrote:
>> Package: undertime
>> Version: 1.7.0
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>> I am reporting this here, as gitlab does not allow me to create an account - 
>> please do forward upstream as needed.
>>
>> Having the ability to type in a name of a regional capital city to undertime 
>> and have it recognised would be great. For example, "Moscow" works, however 
>> "Boston" does not. Similarly, "Lagos" (population 21M) also is not valid. I 
>> assume the English transliteration would be the best route forward.
>>
>> Perhaps as an arbitrary cutoff, a list such as from eg. here : 
>> https://data.mongabay.com/cities_pop_01.htm could be used, with a population 
>> cutoff specified in Millions. 2M : 170 cities, 4M : 73 cities.
>
> Hello!
>
> That's a fair point. I thought about this a little, and settled on using
> whatever Python gave me, which is from:
>
> https://pypi.org/project/pytz/
>
> ... which is based (more or less) on this list:
>
> https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
>
> The list you provided is great except it doesn't specify the timezone,
> which basically makes it useless. ;)
>
> For making this work, I'd need a list that:
>
>  * maps a string (city name or location) to a timezone
>  * is reliably updated
>
> So far, the only thing that qualifies, as far as I know, is the tzdata
> stuff, which is why I'm using it.
>
> But I'd be happy to have another source! As a rule, however, it should
> be available offline.
>
> A.
>



script.sh
Description: application/shellscript

Bug#934859: undertime: Add major cities to available timezones

[D Haley]

Package: undertime
Version: 1.7.0
Severity: wishlist

Dear Maintainer,

I am reporting this here, as gitlab does not allow me to create an account - 
please do forward upstream as needed.

Having the ability to type in a name of a regional capital city to undertime 
and have it recognised would be great. For example, "Moscow" works, however 
"Boston" does not. Similarly, "Lagos" (population 21M) also is not valid. I 
assume the English transliteration would be the best route forward.

Perhaps as an arbitrary cutoff, a list such as from eg. here : 
https://data.mongabay.com/cities_pop_01.htm could be used, with a population 
cutoff specified in Millions. 2M : 170 cities, 4M : 73 cities.

Thanks!

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 undertime depends on:
ii  python3 3.7.2-1
ii  python3-parsedatetime   2.4-2
ii  python3-termcolor   1.1.0-2
ii  python3-terminaltables  3.1.0-2
ii  python3-tz  2019.1-1
ii  python3-yaml3.13-2

undertime recommends no packages.

undertime suggests no packages.

-- no debconf information

Bug#929696: Upgrading PSToedit fixes this

[D Haley]

Hi,

I experienced the same problem. Manually rebuilding and installing
pstoedit-3.74-1 fixed the problem for me.

Currently 3.74 is stuck in unstable.

Bug#931007: ghkl: Homepage link broken

[D Haley]

Package: ghkl
Version: 5.0.0.2456-1
Severity: normal

Dear Maintainer,

The listed URL for the external resource (homepage) for ghkl does not appear to 
be functional, and simply directs back to the institutional home page

Specifically, the listed URL:
https://www.synchrotron-soleil.fr/portal/page/portal/Instrumentation/EnvironnementInstrumental/hkl


redirects to:
https://www.synchrotron-soleil.fr/fr/savoir-faire

which has no information on the program (that I can find after a short browse).

Thanks!

-- System Information:
Debian Release: 9.6
  APT prefers testing
  APT policy: (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-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 ghkl depends on:
pn  libbullet2.87 
ii  libc6 2.28-2
pn  libg3d0   
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglib2.0-0  2.58.2-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgtk2.0-0   2.24.31-2
ii  libgtkglext1  1.2.0-4
pn  libhkl5   
ii  libstdc++68.2.0-14
ii  libyaml-0-2   0.1.7-2

ghkl recommends no packages.

ghkl suggests no packages.

Bug#928687: remmina: Segfaults when recommends is missing on connection

[D Haley]

Package: remmina
Version: 1.3.3+dfsg-2
Severity: normal

Dear Maintainer,

I recently upgraded to buster, and during the process remmina-plugin-rdp
was removed, but not the main remmina package (I was removing orphan
packages, and I recall seeing it being removed). 

I tried to use remmina
to connect to a remote RDP system (windows), as I normally do, and  the
program immediately segfaults with the following backtrace.

5558e735 in remmina_protocol_widget_query_feature_by_type ()
(gdb) bt
#0  0x5558e735 in remmina_protocol_widget_query_feature_by_type ()
#1  0x5559d9d3 in ?? ()
#2  0x555a2142 in rch_update_toolbar ()
#3  0x555a3f09 in rch_create_overlay_ftb_overlay ()
#4  0x555a4554 in rch_create_fullscreen ()
#5  0x555a5532 in rcw_open_from_file_full ()
#6  0x555a5566 in rcw_open_from_filename ()
#7  0x55581f84 in remmina_main_on_action_connection_connect ()
...

By manually reinstalling remmina-plugin-rdp, the problem goes away, so I
suspect that remmina_protocol_widget_query_feature_by_type is implicitly
assuming the plugin is present - I've not checked the code itself.

Perhaps one solution is that reminna could require remmina-plugin-rdp,
rather than recommends? Or alternately, there should be a check that
the protocol is available before trying to use it, to avoid the segfault
(maybe with a message to detail the issue)?

Thanks!


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-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 remmina depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.12-1
ii  libatk1.0-0  2.22.0-1
ii  libavahi-client3 0.7-4+b1
ii  libavahi-common3 0.7-4+b1
ii  libavahi-ui-gtk3-0   0.7-4+b1
ii  libayatana-appindicator3-1   0.5.3-4
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libgcrypt20  1.8.4-5
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk-3-0   3.22.11-1
ii  libice6  2:1.0.9-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-6
ii  libsm6   2:1.2.3-1
ii  libsoup2.4-1 2.64.2-2
ii  libssh-4 0.8.6-3+b1
ii  libssl1.11.1.1b-2
ii  libvte-2.91-00.54.2-2
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  remmina-common   1.3.3+dfsg-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.3.3+dfsg-2
pn  remmina-plugin-secret  
pn  remmina-plugin-vnc 

Versions of packages remmina suggests:
pn  remmina-plugin-exec   
pn  remmina-plugin-nx 
pn  remmina-plugin-spice  
pn  remmina-plugin-telepathy  
pn  remmina-plugin-xdmcp  

-- no debconf information

Bug#925540: qhull: add libqhullcpp to installed libraries

[D Haley]

Source: qhull
Version: 2015.2-4
Severity: normal
Tags: patch

Dear Maintainer,

The Qhull package does not install the libqhullcpp shared libraries. The
headers are installed, but the library is built statically, and does
not get installed.

I have attached a patch against ea54d22bba5fb2cedf106a58bd11904370bfeb4f,
which changes the library to shared and adds it to the relevant .install
files.

If the patch or similar is not suitable, and it is not desired to
distribute the C++ library,  perhaps the C++ qhull headers should
be removed?


-- System Information:
Debian Release: 9.8
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-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)
>From c60f19ce512bf00ed4e735cbd513fde2a5d9e510 Mon Sep 17 00:00:00 2001
From: D Haley 
Date: Tue, 26 Mar 2019 14:59:11 +
Subject: * Fix qhullcpp not installed as .so


diff --git a/debian/libqhull-dev.install b/debian/libqhull-dev.install
index af11adb..0bdb24d 100755
--- a/debian/libqhull-dev.install
+++ b/debian/libqhull-dev.install
@@ -3,4 +3,5 @@ usr/lib/libqhull.a /usr/lib/${DEB_HOST_MULTIARCH}/
 usr/lib/libqhull.so /usr/lib/${DEB_HOST_MULTIARCH}/
 usr/lib/libqhullstatic_r.a /usr/lib/${DEB_HOST_MULTIARCH}/
 usr/lib/libqhull_r.so /usr/lib/${DEB_HOST_MULTIARCH}/
+usr/lib/libqhullcpp.so /usr/lib/${DEB_HOST_MULTIARCH}/
 usr/include
diff --git a/debian/libqhull7.install b/debian/libqhull7.install
index c6d117e..c66bdc1 100755
--- a/debian/libqhull7.install
+++ b/debian/libqhull7.install
@@ -1,2 +1,3 @@
 #! /usr/bin/dh-exec
 usr/lib/libqhull.so.* /usr/lib/${DEB_HOST_MULTIARCH}/
+usr/lib/libqhullcpp.so.* /usr/lib/${DEB_HOST_MULTIARCH}/
diff --git a/debian/patches/0004-qhullcpp-shared.patch 
b/debian/patches/0004-qhullcpp-shared.patch
new file mode 100644
index 000..14bf6dd
--- /dev/null
+++ b/debian/patches/0004-qhullcpp-shared.patch
@@ -0,0 +1,12 @@
+diff -r 4c7aa6ab184e CMakeLists.txt
+--- a/CMakeLists.txt   Wed Mar 20 22:44:13 2019 +
 b/CMakeLists.txt   Wed Mar 20 23:19:18 2019 +
+@@ -459,7 +459,7 @@
+ # Do not create libqhullcpp as a shared library.  Qhull C++ classes may 
change layout and size. 
+ # ---
+ 
+-add_library(${qhull_CPP} STATIC ${libqhullcpp_SOURCES})
++add_library(${qhull_CPP} SHARED ${libqhullcpp_SOURCES})
+ set_target_properties(${qhull_CPP} PROPERTIES
+ VERSION ${qhull_VERSION})
+ 
diff --git a/debian/patches/series b/debian/patches/series
index a57e26b..1494b1a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 0001-debianize-test-failure-msg.patch
 0002-QHpointer.patch
 0003-spelling.patch
+0004-qhullcpp-shared.patch

Bug#919289: [Pkg-kde-extras] Bug#919289: kile: After upgrade, kile will not open until okular installed

[D Haley]

Hi,

Thanks for the quick reply.

> Which kind of system is this?
>
> You have a mixup of stable and testing/unstable.  This situation is not
> supported.

Its a stable system that I was upgrading to testing.  It normally runs
stable.

The upgrade is incomplete because  I was upgrading from inside a DE, and
it wanted to pull the X server, so I was upgrading piecewise whilst
trying to work.

So yes, its incomplete. If this is an is an issue, please feel free to
close the bug.

> What is the exact error you saw?

It looks like the message is from main.cpp:175-176,

175:KMessageBox::sorry(Q_NULLPTR, i18n("Kile cannot start as
a recent version the Okular library could not be found.\n\n"
176:   "Please install the
Okular library before running Kile."),

Thanks!

Bug#919289: kile: After upgrade, kile will not open until okular installed

[D Haley]

Package: kile
Version: 4:2.9.92-1
Severity: normal

Dear Maintainer,

After upgrading kile from 4:2.1.3-4+b1 to 4:2.9.92-1, kile would not
open, giving an error along the lines of missing libokular. Okular was
installed on my system, but was an older version. I suspect there is a
missing depends on libokular5core8, or something along these lines

Manually installing okular fixes the problem .

The installation steps were as follows :

Upgrading Kile:

Start-Date: 2019-01-14  15:09:15
Commandline: apt install kile
Requested-By: USER
Install: libx265-165:amd64 (2.9-3, automatic), libavformat58:amd64 (7:4.1-1, 
automatic), libkf5texteditor5:amd64 (5.51.0-3, automatic), 
libqt5texttospeech5:amd64 (5.11.3-2, automatic), libmbedtls12:amd64 (2.16.0-1, 
automatic), libcom-err2:amd64 (1.44.5-1, automatic), libcom-err2:i386 
(1.44.5-1, automatic), gnupg-utils:amd64 (2.2.12-1, automatic), 
ktexteditor-katepart:amd64 (5.51.0-3, automatic), gpg-wks-client:amd64 
(2.2.12-1, automatic), libkf5pty5:amd64 (5.51.0-1, automatic), libllvm7:amd64 
(1:7.0.1-4, automatic), gnupg-l10n:amd64 (2.2.12-1, automatic), 
libmbedcrypto3:amd64 (2.16.0-1, automatic), va-driver-all:amd64 (2.3.0-2, 
automatic), libswresample3:amd64 (7:4.1-1, automatic), libkf5kiogui5:amd64 
(5.51.0-1, automatic), gcc-8-base:i386 (8.2.0-14, automatic), 
libkf5kirigami2-5:amd64 (5.51.0-1, automatic), libqt5quicktemplates2-5:amd64 
(5.11.3+dfsg-2, automatic), gpg-wks-server:amd64 (2.2.12-1, automatic), 
gpg:amd64 (2.2.12-1, automatic), qml-module-qtquick-controls2:amd64 (5.11.3+
 dfsg-2, automatic), qml-module-qtqml-models2:amd64 (5.11.3-2, automatic), 
libkf5khtml-bin:amd64 (5.51.0-1, automatic), libkf5js5:amd64 (5.51.0-1, 
automatic), libvpx5:amd64 (1.7.0-3, automatic), libqt5quickcontrols2-5:amd64 
(5.11.3+dfsg-2, automatic), ktexteditor-data:amd64 (5.51.0-3, automatic), 
libaom0:amd64 (1.0.0-3, automatic), libkf5pty-data:amd64 (5.51.0-1, automatic), 
libkf5syntaxhighlighting5:amd64 (5.51.0-1, automatic), libva2:amd64 (2.3.0-2, 
automatic), libva2:i386 (2.3.0-2, automatic), libeditorconfig0:amd64 
(0.12.1-1.1, automatic), libx264-155:amd64 (2:0.155.2917+git0a84d98-2, 
automatic), libhttp-parser2.8:amd64 (2.8.1-1, automatic), 
qml-module-org-kde-newstuff:amd64 (5.51.0-1, automatic), libavcodec58:amd64 
(7:4.1-1, automatic), libmbedx509-0:amd64 (2.16.0-1, automatic), 
keditbookmarks:amd64 (17.08.3-2, automatic), libavutil56:amd64 (7:4.1-1, 
automatic), libwebpmux3:amd64 (0.6.1-2, automatic), 
qml-module-qtquick-templates2:amd64 (5.11.3+dfsg-2, automatic), libkf5newstuff
 core5:amd64 (5.51.0-1, automatic), libkf5khtml-data:amd64 (5.51.0-1, 
automatic), konsole-kpart:amd64 (4:18.04.0-1, automatic), libva-x11-2:amd64 
(2.3.0-2, automatic), libva-drm2:amd64 (2.3.0-2, automatic), 
libkf5texteditor-bin:amd64 (5.51.0-3, automatic), libkf5doctools5:amd64 
(5.51.0-1, automatic), i965-va-driver:amd64 (2.2.0+dfsg1-2, automatic), 
gpg-agent:amd64 (2.2.12-1, automatic), libgit2-27:amd64 (0.27.7+dfsg.1-0.1, 
automatic), libkf5syntaxhighlighting-data:amd64 (5.51.0-1, automatic), 
libbluray2:amd64 (1:1.0.2-3, automatic), gpgconf:amd64 (2.2.12-1, automatic), 
libkf5khtml5:amd64 (5.51.0-1, automatic), mesa-va-drivers:amd64 (18.2.8-2, 
automatic), libcodec2-0.8.1:amd64 (0.8.1-2, automatic), gpgsm:amd64 (2.2.12-1, 
automatic), qml-module-org-kde-kirigami2:amd64 (5.51.0-1, automatic)
Upgrade: libkf5kiowidgets5:amd64 (5.28.0-2, 5.51.0-1), libcomerr2:amd64 
(1.43.4-2, 1.44.5-1), libcomerr2:i386 (1.43.4-2, 1.44.5-1), libgpgmepp6:amd64 
(1.8.0-3+b2, 1.12.0-4), libkf5attica5:amd64 (5.28.0-1, 5.51.0-1), 
comerr-dev:amd64 (2.1-1.43.4-2, 2.1-1.44.5-1), libkf5xmlgui-bin:amd64 
(5.28.0-1, 5.51.0-1+b1), kinit:amd64 (5.28.0-1, 5.51.0-2), 
libkwalletbackend5-5:amd64 (5.28.0-3, 5.51.0-1), gnupg-agent:amd64 
(2.1.18-8~deb9u3, 2.2.12-1), libgnutls-openssl27:amd64 (3.5.8-5+deb9u4, 
3.6.5-2), libkf5kiofilewidgets5:amd64 (5.28.0-2, 5.51.0-1), gcc-8-base:amd64 
(8.2.0-13, 8.2.0-14), libkf5bookmarks-data:amd64 (5.28.0-1, 5.51.0-1), 
libkf5service-bin:amd64 (5.28.0-1, 5.51.0-1), libgpgme11:amd64 (1.8.0-3+b2, 
1.12.0-4), libopenmpt0:amd64 (0.2.7386~beta20.3-3+deb9u3, 0.4.1-1), 
libmp3lame0:amd64 (3.99.5+repack1-9+b2, 3.100-2+b1), libmp3lame0:i386 
(3.99.5+repack1-9+b2, 3.100-2+b1), libkf5notifyconfig-data:amd64 (5.28.0-1, 
5.51.0-1), libkf5wallet-bin:amd64 (5.28.0-3, 5.51.0-1), kded5:amd64 (5.28.0-
 1, 5.51.0-1), kile:amd64 (4:2.1.3-4+b1, 4:2.9.92-1), 
libkf5textwidgets-data:amd64 (5.28.0-1, 5.51.0-1), libassuan0:amd64 (2.4.3-2, 
2.5.2-1), libkf5bookmarks5:amd64 (5.28.0-1, 5.51.0-1), kio:amd64 (5.28.0-2, 
5.51.0-1), p11-kit-modules:amd64 (0.23.3-2, 0.23.14-2), 
libkf5notifyconfig5:amd64 (5.28.0-1, 5.51.0-1), dirmngr:amd64 (2.1.18-8~deb9u3, 
2.2.12-1), libkf5service5:amd64 (5.28.0-1, 5.51.0-1), libkf5wallet-data:amd64 
(5.28.0-3, 5.51.0-1), libkf5newstuff5:amd64 (5.28.0-1, 5.51.0-1), 
libkf5wallet5:amd64 (5.28.0-3, 5.51.0-1), libkf5newstuff-data:amd64 (5.28.0-1, 
5.51.0-1), 

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

[D Haley]

Hi,

I've attached a patch that might suit - however I am a bit unsure about
modifying a non-leaf package, such as GSL.

Most of the references to delete were of the form xxx_delete, which are
not relevant to the current problem (as this does not conflict with the
C++ operator).  The only externally visible (in header files) clash that
I could find was in the gsl_movstat.h file. This is referenced in a few
files in movstat/ internally, and needed to be adjusted.

This fixes the problem for me, and can be used as a patch in the debian
gsl git, c3eee7ef (as a file in debian/patches/). I've rebuilt the .deb
on a VM, and made a few quick tests using g++.

Thanks!
--- a/movstat/apply.c
+++ b/movstat/apply.c
@@ -91,7 +91,7 @@
   for (i = 0; i < H; ++i)
 (accum->insert)(x1, w->state);
 }
-  else if (accum->delete == NULL) /* FIXME XXX */
+  else if (accum->del== NULL) /* FIXME XXX */
 {
   /* save last K - 1 samples of x for later (needed for in-place 
input/output) */
   int idx1 = GSL_MAX(n - J - H, 0);
@@ -125,7 +125,7 @@
   int idx1 = GSL_MAX(n - J, 0);
   int idx2 = n - 1;
 
-  if (accum->delete == NULL)
+  if (accum->del== NULL)
 {
   int wsize = n - GSL_MAX(n - J - H, 0); /* size of work array */
 
@@ -154,7 +154,7 @@
   if (i - H > 0)
 {
   /* delete oldest window sample as we move closer to edge 
*/
-  (accum->delete)(w->state);
+  (accum->del)(w->state);
 }
 
   /* yi = acc_get [ work(i:K-2) ] */
--- a/movstat/gsl_movstat.h
+++ b/movstat/gsl_movstat.h
@@ -55,7 +55,7 @@
   size_t (*size) (const size_t n);
   int (*init) (const size_t n, void * vstate);
   int (*insert) (const double x, void * vstate);
-  int (*delete) (void * vstate);
+  int (*del) (void * vstate);
   int (*get) (void * params, double * result, const void * vstate);
 } gsl_movstat_accum;
 
--- a/filter/rmedian.c
+++ b/filter/rmedian.c
@@ -188,7 +188,7 @@
 rmedian_delete(void * vstate)
 {
   rmedian_state_t * state = (rmedian_state_t *) vstate;
-  return (state->minmax_acc->delete)(state->minmax_state);
+  return (state->minmax_acc->del)(state->minmax_state);
 }
 
 static int

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

[D Haley]

Hi,

Thanks for the very quick response.

On my system, it is gsl/gsl_filter.h, rather than
gsl/filter/gsl_filter.h . I'm not sure why - I'm running stable and have
manually backported the testing release, as gsl_filter.h is new and I'm
using it in my code.

$ apt-file find gsl_filter.h
libgsl-dev: /usr/include/gsl/gsl_filter.h

I've raised the original concern upstream:
https://savannah.gnu.org/bugs/index.php?54921

Just for reference - I thought that Debian policy was to report to
Debian, and have the maintainer contact upstream? [1,2] Perhaps I am
mistaken?

Is it possible that this can be patched in Debian in the meantime, so
others don't have this problem?

I've fixed it locally, so I am fine.

Thanks!

[1] https://www.debian.org/Bugs/Reporting ("If necessary, the maintainer
of the package will forward the bug upstream.")
[2] https://wiki.debian.org/BugTriage#Forwarding_reports_upstream

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

[D Haley]

Package: libgsl23
Version: 2.5+dfsg-5
Severity: normal

Dear Maintainer,

The following program will not compile when using a c++ compiler:

#include 

int main()
{
}

This gives the following error:
$ g++ tmp.cpp -o tmp
In file included from /usr/include/gsl/gsl_filter.h:25:0,
from tmp.cpp:1:
/usr/include/gsl/gsl_movstat.h:58:9: error: expected unqualified-id before 
‘delete’
int (*delete) (void * vstate);
^~
/usr/include/gsl/gsl_movstat.h:58:9: error: expected ‘)’ before ‘delete’

This is due to C++ conflicting with the delete operator in the header. This 
should have been fixed upstream [1], but I can't see that this has actually 
been pushed to the gsl git repo [2].

Without this fix it is not possible for a user to use the new filter functions, 
unless they manually alter gsl_movstat.h

[1] https://lists.nongnu.org/archive/html/help-gsl/2018-08/msg2.html
[2] 
http://git.savannah.gnu.org/cgit/gsl.git/tree/movstat/gsl_movstat.h?h=release-2-5=4be1af794429e80137b2bc177e66fb106ee58976



-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (900, 'stable'), (1, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-7-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 libgsl23 depends on:
ii  libc6 2.24-11+deb9u3
ii  libgslcblas0  2.5+dfsg-5

libgsl23 recommends no packages.

Versions of packages libgsl23 suggests:
pn  gsl-ref-psdoc | gsl-doc-pdf | gsl-doc-info | gsl-ref-html  

-- no debconf information

Bug#908904: /usr/include/mgl2/config.h: error: unable to find numeric literal operator ‘operator""i’

[D Haley]

Hi Marius,

I've raised this with upstream, and they believe have a fix in their
repository (r1587 and up). If you have a chance, can you check their
patch against the Debian package?

Otherwise I will check this in the coming weeks.

Thanks!

On Sat, 15 Sep 2018 20:04:33 +0200 Marius Mikucionis
 wrote:
> Package: libmgl-dev
> Version: 2.4.2.1-2
> Severity: normal
> File: /usr/include/mgl2/config.h
> 
> Dear Maintainer,
> 
> The package is unusable in the context "g++ -std=c++11" or newer (c++14, 
> c++17).
> The same issue is in bug report 800460, but it is archived.
> Here is a sample program:
> 
> #include 
> int main() {
>   mglGraph gr;
>   gr.FPlot("sin(pi*x)");
>   gr.WriteFrame("mgl_test.svg");
> }
> 
> The compiler responds as follows:
> 
> In file included 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 tests.cpp:16:
> /usr/include/mgl2/define.h:304:19: error: unable to find numeric literal 
> operator ‘operator""i’
>  const mdual mgl_I=_Complex_I;
>^~
> /usr/include/mgl2/define.h:304:19: note: add ‘using namespace 
> std::complex_literals’ (from ) to enable the C++14 user-defined 
> literal suffixes
> 
> 
> I believe this is due to syntax clash between C99 and C++11
> (C++14 introduces complex literals to support expressions like "1i").
> libmgl-dev is trying to support both but C complex numbers do not make sense 
> in C++ context.
> I cannot see any userspace workaround other than downgrade my code to 
> pre-C++11.
> 
> I propose to disable C complex numbers starting with C++11:
> 
> --- /usr/include/mgl2/config.h2018-09-15 19:57:46.661432502 +0200
> +++ /usr/include/mgl2/config.h.orig   2018-09-15 19:25:14.843095200 +0200
> @@ -28,11 +28,7 @@
>  #define MGL_HAVE_PTHREAD 1
>  #define MGL_HAVE_PTHR_WIDGET 1
>  #define MGL_HAVE_ATTRIBUTE   1
> -#if defined(__cplusplus) && __cplusplus < 201103
>  #define MGL_HAVE_C99_COMPLEX 1
> -#else
> -#define MGL_HAVE_C99_COMPLEX 0
> -#endif
>  #endif
>  
>  #define MGL_SIZEOF_LONG  8
> 
> 
> Marius
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing

Bug#892331: 3depict: Please use 'pkg-config' to find FreeType 2

[D Haley]

Hi,

I've picked a patch from upstream to fix this, it is now in the git
repository, and should be fixed at next upload.

https://salsa.debian.org/science-team/3depict/commit/964dba2bda590d1e9ab1ec8705159b99df7bc9b6

Thanks.

Bug#895605: kakoune: Documentation paths incorrect

[D Haley]

Package: kakoune
Version: 0~2016.12.20.1.3a6167ae-1
Severity: normal

Dear Maintainer,

After installing kakoune, the :doc function does not work as expected. It seems 
to be looking for documentation in the wrong path.

Running ":doc keys marks", as suggsted in the getting started manual, returns
"No such doc file: /usr/share/kak/../doc/kak/manpages/keys.gz"

similar for 
:doc options

Looking at the contents of the kakoune package, it seems that these files
are actually located elsewhere.

$ apt-file list kakoune | grep options
kakoune: /usr/share/man/man1/kak_options.1.gz

The documentation code should point to /usr/share/man/man1, instead of 
/usr/share/doc/kak/manpages.

Thanks!


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-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 kakoune depends on:
ii  libboost-regex1.62.0  1.62.0+dfsg-4
ii  libc6 2.24-11+deb9u3
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libncursesw5  6.0+20161126-1+deb9u2
ii  libstdc++66.3.0-18+deb9u1
ii  libtinfo5 6.0+20161126-1+deb9u2

kakoune recommends no packages.

kakoune suggests no packages.

-- no debconf information

Bug#895440: jabref: [~Unable to connect to libreoffice

[D Haley]

Package: jabref
Version: 3.8.1+ds-3
Severity: normal

Dear Maintainer,

The Libreoffice "connect" feature does not appear to work in this version
of jabref by default.

The "manual connect" feature [1][2] fails as it is looking for several
.jar files:

unoil.jar
jurt.jar
juh.jar
ridl.jar

These files are located in some of these folders (but not all):
/usr/share/java/
/usr/lib/libreoffice/program/classes/
/usr/share/libreoffice/program/classes/

which are not in the default paths listed by the program.

Furthermore, as jabref insists on appending "program/classes/" to
any path that you specify, you can only access them by supplying
"/usr/lib/libreoffice/" as the path. Using /usr/share/java/ or
/usr/share/libreoffice/ does not work, as not all jars are in these
directories (for /usr/share/libreoffice/ OR under the apprpriate sub-path
(program/classes, as the case for /usr/share/java/).

Possible solutions:
1) The default path in the automatic or manual connect could pointed to 
/usr/lib/libreoffice/
2) Upstream could allow specifying multiple search paths 
3) Upstream could hard-code in multiple search locations, such
as /usr/share/java/ and drop the hard-coded requirement for the
"program/classes/" subfolder, and search these optionally
4) Libreoffice could be more consistent in where .jar files are 
symlinked/installed. The "ure" package does not use /usr/lib/ for .jar 
installation.

Thanks!

[1] https://help.jabref.org/en/OpenOfficeIntegration
[2] https://www.onetransistor.eu/2015/04/libreoffice-bibliography-jabref.html

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-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 jabref depends on:
ii  default-jre [java8-runtime] 2:1.8-58
ii  java-wrappers   0.1.28
ii  libandroid-json-java7.0.0+r33-1
ii  libantlr3-runtime-java  3.5.2-6
ii  libantlr4-runtime-java  4.5.3-1
ii  libbcprov-java  1.56-1+deb9u1
ii  libcommons-cli-java 1.3.1-3
ii  libcommons-lang3-java   3.5-1
ii  libcommons-logging-java 1.2-1
ii  libglazedlists-java 1.9.1-2
ii  libguava-java   19.0-1
ii  libhttpasyncclient-java 4.1.2-1
ii  libhttpclient-java  4.5.2-2
ii  libhttpmime-java4.5.2-2
ii  libjava-string-similarity-java  0.19-1
ii  libjempbox-java 1:1.8.12-1
ii  libjgoodies-common-java 1.8.1-2
ii  libjgoodies-forms-java  1.9.0-3
ii  libjgoodies-looks-java  2.7.0-2
ii  libjhlabs-filters-java  2.0.235-3
ii  libjsoup-java   1.10.2-1
ii  liblog4j2-java  2.7-2
ii  libmicroba-java 1:0.4.4.3-5
ii  libpdfbox-java  1:1.8.12-1
ii  libreoffice-java-common 1:6.0.2-1~bpo9+1
ii  libspin-java1.5+dfsg-8
ii  libswing-layout-java1.0.4-4
ii  libswingx-java  1:1.6.2-2
ii  libunirest-java-java1.4.8-2
ii  openjdk-8-jre [java8-runtime]   8u121-b13-4

Versions of packages jabref recommends:
ii  libmysql-java5.1.42-1
ii  libpostgresql-jdbc-java  9.4.1212-1
ii  libreoffice-writer   1:6.0.2-1~bpo9+1
ii  xdg-utils1.1.1-1

Versions of packages jabref suggests:
ii  evince [postscript-viewer]   3.22.1-3+deb9u1
ii  ghostscript [postscript-viewer]  9.20~dfsg-3.2+deb9u1
ii  mupdf [pdf-viewer]   1.9a+ds1-4+deb9u2
ii  okular [postscript-viewer]   4:16.08.2-1+b1

-- no debconf information

Bug#876363: octave fetches network resources when network access disabled

[D Haley]

Ah, ignore my last. I had incorrectly read the version numbering - I am
still running the same version as originally reported.

Apologies for the noise.

On 22/09/17 16:53, Mike Miller wrote:
> Control: forwarded -1 https://savannah.gnu.org/bugs/?52090
> 
> On Thu, Sep 21, 2017 at 23:03:57 +0100, D Haley wrote:
>> 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".
> 
> I've filed upstream bug https://savannah.gnu.org/bugs/?52090 to resolve
> this in Octave, so at least the settings and their behavior will agree.
> 
> Feel free to participate there, or reply here if you think I got
> something wrong in capturing this problem.
> 
>> 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
> 
> I will try to push for upstream to keep the default value to false. A
> compromise position might be to have the first run dialog suggest that
> it be enabled, but if the setting is ever deleted manually or corrupted
> or unable to read in any way, it should always default to disabled.
> 

Bug#876363: octave fetches network resources when network access disabled

[D Haley]

Hi,

> I will try to push for upstream to keep the default value to false. A
> compromise position might be to have the first run dialog suggest that
> it be enabled, but if the setting is ever deleted manually or corrupted
> or unable to read in any way, it should always default to disabled.
> 

I've noticed this problem again on my current octave install. Triggering
it is a little tricky, as it does not always pop up, but perhaps only
launches if there is a change on the remote server.

Do we know if there is a particular commit that upstream applied to fix
this?

Here is the info from my system
$ octave --version
GNU Octave, version 4.0.3
Copyright (C) 2016 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
...
$ grep allow_web_connection ~/.config/octave/qt-settings
$
$ head ~/.config/octave/qt-settings
[General]
connectOnStartup=true
showMessageOfTheDay=true
showTopic=true
customFileEditor=emacs +%l %f
autoIdentification=false
useProxyServer=false
proxyType=
proxyHostName=none
proxyPort=8080
$
$ apt show octave | head -n  5

WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.

Package: octave
Version: 4.0.3-3
Priority: optional
Section: math
Maintainer: Debian Octave Group 
$

In the QT UI, the "Allow Octave to connect to the Octave web site"
is unchecked, however periodically, I still receive updates from their
remote website (new versions available).

Is it an option to just patch out their network access entirely in the
debian package?

This would seem the much safer route, as accessing a random network
resource on untrusted networks (even if you do have https, which I am
unsure if it is the case), seems non-ideal, and contrary to policy.

Thanks!

Bug#888467: afl: ASAN error suggests nonexistant documentation

[D Haley]

Package: afl
Version: 2.36b-1
Severity: minor

Dear Maintainer,

When running afl, the following error is generated on a binary compiled with 
UBSAN (ASAN) support.

[-] Whoops, the target binary crashed suddenly, before receiving any input
from the fuzzer! Since it seems to be built with ASAN and you have a
restrictive memory limit configured, this is expected; please read
/usr/share/doc/afl/notes_for_asan.txt for help.

However this file does not exist. Expected result is that documentation 
suggested by program should exist.

Contents of doc dir:
$ ls /usr/share/doc/afl/*
/usr/share/doc/afl/buildinfo_amd64.gz
/usr/share/doc/afl/changelog.Debian.gz
/usr/share/doc/afl/changelog.gz
/usr/share/doc/afl/copyright
/usr/share/doc/afl/NEWS.Debian.gz
/usr/share/doc/afl/README

I belive this file is actually in /usr/share/doc/afl-doc/docs/ as part of the 
afl-doc package (in sid, 2.52b-1).

Thanks!


-- System Information:
Debian Release: 9.3
  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 afl depends on:
ii  build-essential  12.3
ii  libc62.24-11+deb9u1

Versions of packages afl recommends:
ii  afl-clang  2.36b-1
ii  afl-doc2.36b-1

Versions of packages afl suggests:
pn  gnuplot  

-- no debconf information

Bug#876620: 3depict: missing build dependency on rename

[D Haley]

Hi,

Thanks for the report. I've pushed a change to git [1] and will request
a sponsor to upload the changes.

Relevant changesets are:
 95090e76
 f5e5835b


[1] https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/

Bug#876363: octave fetches network resources when network access disabled

[D Haley]

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#876363: octave fetches network resources when network access disabled

[D Haley]

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

[D Haley]

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

[D Haley]

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

[D Haley]

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#876059: ITP: libvd -- Volume Development library

[D Haley]

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#876059: ITP: libvd -- Volume Development library

[D Haley]

Package: wnpp
Severity: wishlist
Owner: D Haley <my...@gmx.com>

* 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#869382: libwxgtk3.0-0: Drawing sample line test broken

[D Haley]

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#674135: Interest

[D Haley]

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#843594: ilmbase: Proprietary licence in halfExport.h

[D Haley]

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#836563: acbuild: example script contains too-short gpg id

[D Haley]

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#836562: python-tosca-parser: gpg key too short in test script

[D Haley]

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#836561: cairo-dock: gpg key in scripts too short

[D Haley]

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

[D Haley]

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#836558: sqlkit: gpg key too short in tutorial file

[D Haley]

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#836557: php-mongodb: gpg short id used in script

[D Haley]

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#836555: kivy: docs describe short gpg key usage

[D Haley]

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#836553: poretools: short gpg key used in script

[D Haley]

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#836551: gitlab: short gpg key used in script

[D Haley]

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#832749: kile: Freeze on close project when using virtualbox mounts

[D Haley]

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 

Bug#824226: openjdk-8-jre: ATK bridge causes segfault when loading JR

[D Haley]

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#798858: blocked

[D Haley]

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

[D Haley]

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#800460: Ping

[D Haley]

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: mathgl: Test program fails to build, syntax error in header

[D Haley]

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

[D Haley]

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#791173: libstxxl: library transition may be needed when GCC 5 is the default

[D Haley]

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#793107: octave: Find-replace hang when using regex searches with $

[D Haley]

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 1LF, where 
LF 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  none
pn  octave-htmldoc  none
pn  octave-info none

-- 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

[D Haley]

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#785657: RFA: opticalraytracer

[D Haley]

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

[D Haley]

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#764814: freecad downloads and executes code

[D Haley]

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  none
ii  zlib1g  1:1.2.8.dfsg-1

freecad recommends no packages.

Versions of packages freecad suggests:
pn  freecad-doc  none

-- no debconf information


--
To 

Bug#764814: freecad downloads and executes code

[D Haley]

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#746609: Fwd: Re: 3depict: Please update to use wxwidgets3.0

[D Haley]

 Original Message 
Subject: Re: 3depict: Please update to use wxwidgets3.0
Date: Thu, 24 Jul 2014 23:18:55 +0100
From: D Haley my...@gmx.com
To: Olly Betts o...@survex.com

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#754595: RFP: easymercurial -- Easy to use mercurial GUI

[D Haley]

Package: wnpp
Severity: wishlist

* Package name: easymercurial
  Version : 1.3.0
  Upstream Author : Chris Cannam i...@soundsoftware.ac.uk, 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#751474: thunar: Thunar hangs if unable to cleanly terminate SFTP session

[D Haley]

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

[D Haley]

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#747211: scilab: Allow scilab gui to start without opengl

[D Haley]

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 none
pn  scilab-doc-ja none
pn  scilab-doc-pt-br  none

-- 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

[D Haley]

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 none
pn  context   none
pn  dblatex   none
ii  ispell3.3.02-6
pn  kbibtex   none
pn  kile-doc  none
pn  kile-l10n none
pn  latex2htmlnone
pn  lilypond  none
pn  tex4htnone
pn  texlive-doc-base  none
pn  texlive-xetex none
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#746192: wx3.0-examples: Assertion failure in wxPropGrid tests

[D Haley]

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  
(wxFormatStringSpecifierT::value)) == argtype failed in wxArgNormalizer(): 
format specifier doesn't match argument type

BACKTRACE:
[1] wxArgNormalizerunsigned long::wxArgNormalizer(unsigned long, 
wxFormatString const*, unsigned int)
[2] wxArgNormalizerWcharunsigned long::wxArgNormalizerWchar(unsigned 
long, wxFormatString const*, unsigned int)
[3] wxString wxString::Formatunsigned long, wxCStrData(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
snipped gtk stuff

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-docnone

-- 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?

[D Haley]

+ 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#727768: gpx import fail

[D Haley]

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

[D Haley]

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#739080: ITP: tapsim -- Atom probe experiment simulator

[D Haley]

Package: wnpp
Severity: wishlist
Owner: D Haley my...@gmx.com

* Package name: tapsim
  Version : 1.0b.r766
  Upstream Author : Christian Oberforfer  oberdorc muenster
* URL : 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)

[D Haley]

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#738339: libqhull-dev: qhull overflows stack with null outputs

[D Haley]

Package: libqhull-dev
Version: 2009.1-3
Severity: wishlist

Dear Maintainer,
For qhull2012, 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#737653: libtet1.5-dev: consider enabling TETLIBRARY define

[D Haley]

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

[D Haley]

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#730100: 3depict: autopkgtest fails: missing dependencies, and syntax error

[D Haley]

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

[D Haley]

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#729077: libgl1-mesa-dri: opengl broken due to implicit dependency

[D Haley]

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 jcris...@debian.org) 
[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 default 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 

Bug#725904: mercurial-common: hg view tags only show last word in tag

[D Haley]

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   none
pn  python-openssl   none
pn  python-pygments  none
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#725401: libapt-pkg4.12: Crash in pkgCache::DepIterator::IsIgnorable

[D Haley]

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#721261: Prefer SVG over PNG

[D Haley]

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

[D Haley]

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#716788: hgsvn: get_svn_info shouldn't fail on stderr output

[D Haley]

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 module
  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#709547: RFS: mapcatcher/0.8.0.0-1 [put in ITP, ITA, RC, NMU if applicable]

[D Haley]

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#709234: xfce4-mixer: dependency problems fixed by installing

[D Haley]

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

[D Haley]

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#589254: Progress update

[D Haley]

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#589254: Info received (Debian packaging)

[D Haley]

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#589254: Debian packaging

[D Haley]

 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#687491: concur

[D Haley]

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 
pkg-gnome-maintain...@lists.alioth.debian.org

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 
pkg-gnome-maintain...@lists.alioth.debian.org

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 j...@debian.org
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: 

Bug#704828: nsis: CWD taken from symlink target, not symlink itself

[D. Haley]

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#704828: nsis: CWD taken from symlink target, not symlink itself

[D Haley]

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 none (no description available)
pn  nsis-doc  none (no description available)
pn  nsis-pluginapinone (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#703935: g++-mingw-w64-x86-64: stringstream has different results when using -D_GLIBCXX_DEBUG

[D Haley]

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 sstream
#include string
#include iostream

using namespace std;

templateclass T1, class T2 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   none (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#697899: Fix committed

[D. Haley]

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

[D Haley]

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 none (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  xinputnone (no description available)
pn  xscreensaver | xlockmore | xl none (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#674779: Noted

[D Haley]

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#658435: cross check changelog against bts for bug status

[D Haley]

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#655862: fixed in git

[D Haley]

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#656022: Segfault if ccache called from missing dir

[D Haley]

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  none

-- 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#640432: Acknowledgement (libqhull: Qhull requires __POWERPC__ to be defined to a value)

[D Haley]

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 ow...@bugs.debian.org wrote:

 From: Debian Bug Tracking System ow...@bugs.debian.org
 Subject: Bug#640432: Acknowledgement (libqhull: Qhull requires __POWERPC__ to 
 be defined to a value)
 To: mycae my...@yahoo.com
 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 
 debian-science-maintain...@lists.alioth.debian.org
 
 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#619386: Fix

[D Haley]

Hi All,

I think my emails to Sylvestre might be being dropped when sending directly :(

The fix has been in git for a while, and only affects the 1.2.x series -- the 
1.3.x was fixed before this bug opened, but I didn't backport it until this bug 
was reported:

Here is the 1.2.x fix, the head of the stable-1.2.x branch is pending upload.
http://git.debian.org/?p=debian-science/packages/libstxxl1.git;a=commit;h=4f5e11a2396f05de6adaf066829f8325930173fc

(note, as of time of posting, git.debian.org appears to be down).
Thanks.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org