Bug#1008854: Packages using gnuradio-dev FTBFS

[A. Maitland Bottoms]

>> affects -1 src:gr-limesdr src:gr-funcube src:gr-rds src:gr-hpsdr 
>> src:gr-fosphor src:gr-satellites src:gr-radar src:gr-iqbal
> Bug #1008854 [gnuradio-dev] Packages using gnuradio-dev FTBFS
> Added indication that 1008854 affects src:gr-limesdr, src:gr-funcube, 
> src:gr-rds, src:gr-hpsdr, src:gr-fosphor, src:gr-satellites, src:gr-radar, 
> and src:gr-iqbal
>
> -- 
> 1008854: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008854
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

OK.

I am preparing gnuradio_3.10.2.0-2 which explicitly uses 'posix_prefix'
from Python3's sysconfig in GrPython.cmake

The other gr-* packages will then have the expected python path for the
.install files to work as well.

Lots of other improvements - uploading to unstable.

-Maitland

Bug#962381: gqrx-sdr: gqrx segmentation fault at start time in testing

[A. Maitland Bottoms]

On Sun, 07 Jun 2020 10:36:54 +0200
Antonio Radici  wrote:

> gqrx does not start in testing, this renders the package unusable.

I'm sorry to hear this.

I noticed the -b3 version get upgraded today too, but it works for me
when I start it
(I have a box tracking testing, so no chroot here.)

> 
> The problem is reproducible by spinning up a testing chroot (as of
> today) and trying to start gqrx

gqrx without hardware can be fragile. For that there are run time
arguments. `gqrx --reset` and `gqrx --edit` handle initial
configuration problems. Does it then work for you selecting the input
device doing `gqrx --edit` ?

What device are you trying to use? Does your chroot expose it correctly
and with the right permissions?

-Maitland

Bug#858774: modes_rx: ImportError: cannot import name QtWebKit

[A. Maitland Bottoms]

Moritz Mühlenhoff  writes:

> Hi Maitland,
> per upstream issue 98 it doesn't sound as if it's going to be fixed,
> should be remove it or are you planning to port it yourself?

I was just talking to the upstream author at the gnuradio conference.
Our plan going forward is to just remove the GUI elements of the
package, but keep all the signal processing code and provide gnuradio
blocks.

I am travelling and away from my Debian keys. I'll upload a Qt4 free
version fixing this bug in the coming week..

>
> (We're closing in on the Qt4 removal)
>
> Cheers,
> Moritz

Maybe someday someone will use the gr-air-modes package to feed data to
a newer better map display.

Thanks for looking into this,
-Maitland

Bug#875160: [qthid-fcd-controller] Future Qt4 removal from Buster

[A. Maitland Bottoms]

On Sat, 7 Sep 2019 22:44:00 +0200
Moritz Mühlenhoff  wrote: 
> Hi Maitland,
> we're moving forward with the Qt4 removal.
> 
> qthid-fcd-controller seems dead upstream, are you planning to port it
> yourself or shall we remove it from the archive?
> 
> Cheers,
> Moritz

Yeah, I have tried to get other people to do it.
Thanks to your email, I am starting to port it myself.
(I have gotten other Qt4 code to build under Qt5, so I can no longer
claim ignorance.)

Give me until the end of the month? If I cannot do it myself this
weekend, I might get someone at the GNU Radio conference to do it the
week after next. (Some folk there got gnuradio from qt4 to qt5.)

How hard can it be?

Thanks for the prompting,
-Maitland

Bug#935733: libbladerf-doc: fails to upgrade from 'sid' - trying to overwrite /usr/share/doc/libbladerf-dev/CONTRIBUTORS

[A. Maitland Bottoms]

I got surprised by the result that adding a file to
debian/libbladerf-doc.docs resulted in a file being unpacked to
/usr/share/doc/libbladerf-dev/

Upload with Breaks:/Replaces: coming soon.
-Maitland

Bug#904592: predict-gsat: No executable is included

[A. Maitland Bottoms]

On Sat, 12 Jan 2019 16:02:02 +0100
Christoph Berg  wrote:
> Maitland, can we remove predict?
> 
> Christoph

Yes...
Certainly predict-gsat is obsolete and unmaintained - and gpredict is
the logical successor.

But...
There might be curses interface fans who would mourn its removal, but
the codebase has never been easy to adapt.

There is a voice mode in predict that I think is still on the TODO list
to migrate to gpredict.

So...
I won't stand in the way of a consensus to remove predict...
I find myself using gpredict or even Python sgp4 rather than predict.

-Maitland

Bug#913355: libuhd-dev: UHDConfig.cmake includes nonexisting UHDTargets.cmake

[A. Maitland Bottoms]

Before getting this bug report, I uploaded
uhd 3.13.0.2-3 which fixes this bug.

-Maitland

Bug#907226: cutesdr: FTBFS with Qt 5.11

[A. Maitland Bottoms]

Reiner Herrmann  writes:

> the attached patch fixes the FTBFS by including the missing header.
...
> ++#include 
Hi,

Thanks so much, but I see the upstream author Moe Wheatley has
now also included this fix, so I have pulled a few more commits
from upstreams work towards a version 1.21 onto a revised
Debian packaging for version 1.20.

I just want you to know that even though I did not apply your fix
directly, I appreciate receiving it.

-Maitland

Bug#898964: mrs: FTBFS: you don't seem to have log4cpp installed

[A. Maitland Bottoms]

If the problem can be traced to the .pc file and pkg-config I will take blame 
for a bug.  I am away from an appropriate computer right now, but will 
investigate further soon.

-Maitland


On May 18, 2018 7:20:55 AM EDT, Andrey Rahmatullin  wrote:
>On Fri, May 18, 2018 at 01:06:18PM +0200, Andreas Tille wrote:
>> > The reason for this: the configure script compiles the following
>code:
>> > 
>> > #include 
>> > #include 
>> > int main() { std::cout << 1 << '\t' << 0; return 0; }
>> > 
>> > in order to check that  exists.
>> > But this code still requires -llog4cpp:
>> 
>> Thanks for the explanation but may be I'm missing your point.  The
>> package installs liblog4cpp.a as well and the dynamic library
>installs
>> the according .so file.  So why should the requriement -llog4cpp not
>> fulfilled?
>The configure script doesn't pass -llog4cpp. It tests for the existence
>of
>the header and tries to find a correct -I option for it. Finding the
>correct -L is the next step.
>
>> > /tmp/cc41MUW4.o: In function
>`__static_initialization_and_destruction_0(int, int)':
>> > 2.cpp:(.text+0x5b): undefined reference to
>`log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
>> > 2.cpp:(.text+0x70): undefined reference to
>`log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
>> > collect2: error: ld returned 1 exit status
>> 
>> Isn't this rather a bug in log4cpp?
>No.
>
>-- 
>WBR, wRAR

Bug#873608: uhd: NEON-related FTBFS on armhf

[A. Maitland Bottoms]

So yeah, we cannot expect NEON on Debian armhf.

But I did not expect these compile time errors... I would hope that
one could at least compile some NEON code on Debian armhf, and then
maybe do some runtime conditional test to only execute NEON if it
is available.

This code has not compiled on Debian for a while, so I am bringing back
a debian-armhf-convert-without-neon patch I used before.

-Maitland

Bug#864452: vtkdata: do not ship in stretch

[A. Maitland Bottoms]

Anton Gladky  writes:
> So, I think vtkdata can safely be removed as requested by Mathieu.

I support removal of vtkdata from sid and testing, and agree it should
not be released with stretch.

Back when I created the vtkdata package, I was motivated by the need for
it in build-time test targets, as well as its usefulness in tutorial
examples and references from those teaching with VTK.

Notice that there are VTKData and VTKLargeData collections shipped from
vtk.org along with the source tarballs. (For some reason VTKLargeData is
a smaller file than VTKData.)

Perhaps as new VTK v8.0.x gets packaged we might want to re-instate a
vtkdata package, another approach might be to look at the data size
requirement of the `make test` target and see what is really useful to
keep. More discussion seems likely worthwhile to me, and if vtkdata has
to go through NEW processing again that might be another chance to build
consensus.

-Maitland

Bug#860147: gnuradio-dev in backports depends on liblog4cpp5-dev which isn't available

[A. Maitland Bottoms]

Andy Berkvam  writes:

> Package: gnuradio-dev
> Version: 3.7.10.1-1~bpo8+1
> Severity: grave
> Justification: renders package unusable

Unable to reproduce in Debian, on adm64 and i386 at least.

> Running jessie and gnuradio 3.7.5.  Configured jessie-backports and installed 
> gnuradio 3.7.10.1.  The Sources menu (rtlsdr) was missing. Tried to install 
> gnuradio-dev.  Got the following error:

OK. Both gnuradio 3.7.5 and gnuradio 3.7.10.1 build-depend upon
liblog4cpp5-dev, so the fact they are available means that the
build machines got it right.

Is there a Raspbian jessie-backports? Maybe armv7l is able to use
Debian's armhf. Check `volk-config-info --all-machines` and
`volk-config-info --avail-machines` and run volk_profile.
(From the libvolk1-bin package. gnuradio depends upon it.)

You'll need the gr-osmosdr package installed to get the RTL-SDR Source
block to appear.

Also, the "Sources menu" has moved around a bit. Blocks included in
gnuradio have a "Core" top level, and add-ons like RTL-SDR Source
and osmocomm Source end up grouped separately. Type / in the
blocks menu area and search.

> The following packages have unmet dependencies:
>  gnuradio-dev : Depends: liblog4cpp5-dev but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.

It does appear to be available in Raspbian GNU/Linux 8.0 (jessie):
Listed in
http://mirrordirector.raspbian.org/raspbian/dists/jessie/main/binary-armhf/Packages
Located in
http://mirrordirector.raspbian.org/raspbian/pool/main/l/log4cpp/liblog4cpp5-dev_1.0-4_armhf.deb

So it really should be available and installable.

I hope you "Configured jessie-backports" in addition to your standard
distribution source, rather than instead of.

> -- System Information:
> Distributor ID:   Raspbian
> Description:  Raspbian GNU/Linux 8.0 (jessie)
> Release:  8.0
> Codename: jessie
> Architecture: armv7l
>
> Kernel: Linux 4.4.50-v7+ (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

Good luck,
-Maitland

Bug#830459: log4cpp: FTBFS: configure.in:44: error: required file 'config/compile' not found

[A . Maitland Bottoms]

It seemed to me that a bit of modernization in log4cpp packaging would
help fix this. I noticed upstream states that the 1.1.1 is the newest
stable release, and refactored the packaging around dh and
dh-autoreconf.

(I have not had time yet to build and test my packages with this
newer log4cpp, and I do hope that I can run abi-compliance-checker
soon and not be too surprised.)

Hope this helps,
-Maitland


log4cpp_1.1.1-1.debian.tar.xz
Description: log4cpp_1.1.1-1.debian.tar.xz

Bug#830486: gr-air-modes: FTBFS: No rule to make target 'swig/air_modes_swig.py'

[A. Maitland Bottoms]

I am preparing a gr-air-modes 0.0.2.c29eb60-1 which has uptream
swig fixes that I expect will address this.
(current gr-air-modes git HEAD)

Thanks for your interest in this package. Yes, it has caused
me to learn more about swig, and this bug showed up trying
to merge multiple github features along with my swig refactoring.
So while that fix was upstream for a month, I got distracted
by the recent gnuradio release of version 3.7.10 and my updating
of all my gnuradio related packages following that.

-Maitland

Bug#799550: libuhd003v5 lost its v5 suffix...

[A. Maitland Bottoms]

Raphaël Hertzog writes:
 > Package: libuhd003
 > Version: 3.9.0-1
 > Severity: serious
 > User: de...@kali.org
 > Usertags: origin-kali
 > 
 > I just noticed that with uhd 3.9.0 libuhd003 lost the v5 suffix that had
 > been introduced with 3.8.5-2.1.
 > 
 > And the changelog has no explanation for this. So to avoid problems
 > when upgrading from jessie to stretch, this should be fixed again...
 > 
 > Thank you!

I've got uhd-3.9.1-1 conflicting with gnuradio << 3.7.8-3
and I am considering adding a versioned depends for gnuradio 3.7.8-4
and libgnuradio-osmosdr0.1.4 0.1.4-3 that requires libuhd003 >= 3.9.
Will that be enough to avoid problems when upgrading from jessie to stretch?

Upstream has been breaking ABI routinely. Another approach would be
to patch the soname and soversion for the Debian packaging resulting
in a new libuhd3.9 library package. At the moment I am preferring
this approach to the v5 suffix approach.

But if taking the v5 suffix approach is the recommended way forward,
I can certainly do that. But I would like your advice now that you
know upstream UHD often breaks ABI without soname/soversion bumps.

I think UHD upstream is interested in best practices for library
release management, but, like me, needs a bit of education and a
plan to move from the current state of release management to
something better.

Thanks,
-Maitland

also:
peter green writes regarding bug #794878:
 > It appears the library rename introduced in uhd 3.8.5-2.1 was reverted
 > in uhd 3.9.0-1. There was no mention of this revert in the changelog.
 >
 > Was the revert intentional and if so what was the reasoning behind it?

Yes it was intentional.
The reasoning is that uhd routinely changes ABI and API between versions.
I have been using versioned package dependencies to manage library ABI
changes. Since 3.9.0 was another ABI bump from 3.8.5, I went ahead and
reverted the library rename.

Not mentioning this in the changelog is my mistake and I do feel silly
for not doing it.

I used dh-acc to check that uhd 3.9.1 was compatible with uhd 3.9.0.
Also, upstream has told me that they were beginning to use the
abi-compliance-checker tool as well. So with luck better library
soname and soversion settings will make it easier to follow normal
library package name conventions in the future.

Thank you for your interest and attention. Library ABI/API release
management and soname/soversion practices are weaknesses of mine, so
I am eager to learn. Let me know any comments or advice you have,
and I'll pass it along to my upstreams too.

When faced with upstream libraries not bumping sonames, how many
Debian packages patch to do their own library release management
versus simply following upstream's conventions?

Thanks,
-Maitland

Bug#794878: fixed in uhd 3.8.5-2.1

[A. Maitland Bottoms]

peter green writes:
 > It appears the library rename introduced in uhd 3.8.5-2.1 was reverted 
 > in uhd 3.9.0-1. There was no mention of this revert in the changelog.
 > 
 > Was the revert intentional and if so what was the reasoning behind it?

Yes it was intentional.
The reasoning is that uhd routinely changes ABI and API between versions.
I have been using versioned package dependencies to manage library ABI
changes. Since 3.9.0 was another ABI bump from 3.8.5, I went ahead and
reverted the library rename.

Not mentioning this in the changelog is my mistake and I do feel silly
for not doing it.

I used dh-acc to check that uhd 3.9.1 was compatible with uhd 3.9.0.
Also, upstream has told me that they were beginning to use the
abi-compliance-checker tool as well. So with luck better library
soname and soversion settings will make it easier to follow normal
library package name conventions in the future.

Thank you for your interest and attention. Library ABI/API release
management and soname/soversion practices are weaknesses of mine, so
I am eager to learn. Let me know any comments or advice you have,
and I'll pass it along to my upstreams too.

When faced with upstream libraries not bumping sonames, how many
Debian packages patch to do their own library release management
versus simply following upstream's conventions?

Thanks,
-Maitland

Bug#770107: libdime-dev must depends on libdime1

[A. Maitland Bottoms]

There's more wrong with dime 0.20111205-1

Some libtool wrappers were installed into /usr/bin/dxf2vrml
and /usr/bin/dxf2sphere in the dime binary package - rather
then the correct compiled ELF binary executables. Therefore,
the dime package did not depend upon the libdime1 library
package either.

Correctly installing the dxf2vrml and dxf2sphere binaries
in the dime package, along with adding ${shlibs:Depends},
results in a dime package correctly depending upon libdime1
as well.

The Debian packaged view3dscene verifies the correct
operation of the dime package by displaying a sphere
made by dxfsphere converted to vrml by dxf2vrml.
(I had not done this verification step before uploading
dime 0.20111205-1)

Expect a dime 0.20111205-2 upload soon, followed by an
unblock request for Jessie.

-Maitland


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

Bug#770107: Bug#770270: unblock: dime/0.20111205-2

[A. Maitland Bottoms]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

See Bug#770270: unblock: dime/0.20111205-2
for my unblock request.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJUbW+PAAoJEFBB8YkfROCQ3jAP/jyCZifTQUSvmbBb21ngz5hI
7aqm12HFdDpAZsGWxr5z7H/xzv6FywpRHFfWVCPVqXKoFS0kyZmWt5Au3Z8rmDGJ
PKIOB/cLIi0aVas8wGzJBVl+2IkNZqqU3Z/PRG5ZxOp5sJIacmsQCatWXsOR4U2i
1stuMWzuCb8SI6XTvDsdzVlb46QkAvEh3KUQ/H11Wli4mBsOP/jiZTtmj5B6t0K6
H0qNiTN39AhonJugHwlaFpwQk3S9Btkddf0MGge/eQMo7j5TULq6kCDydZRejREu
w52rd4ETAr99GGewgOHQRRzhIHYZQQCS/HsazrexKgwv1QcIfrl/NjlarsRHU+OF
kCSXKknBgRLgz19w2KROWMT9w3HOO8+A9gtNMyA4SpBiO0WnMWyqEWNY7rLRvW+4
AVQQN4cYrKuNRu1pxF7NTROyMCuJ5FhPTOUPMRUkwbl7Sxx6VhN1fo9QBP9RhZRq
2c46sb2qFgvYXFZjQtJV5m38l/yI3rl+LcGhkA7GJyOOhETBmu+eB74J60cnSYFr
NvKtCxqcHPUMh08cwQ5DGy5cwNpUY4Snhc4ivecaiRhCav1u2U0khyxzjEamczsk
B+GpQx57o4KpxUMM1eGbl5Uw/Q/BvgYXSsidXakQth6auvyxqkPDVf2B7f0PgcSm
QlTw9SHkSd7n7Qdw2JIp
=LWF7
-END PGP SIGNATURE-


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

Bug#759927: gr-osmosdr: FTBFS on kfreebsd

[A. Maitland Bottoms]

It should be fine again soon.
bladerf 0.2014.09~rc2-4 just built fine on the kfreebsds.

-Maitland


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

Bug#749749: gqrx-sdr: gqrx segfaults when run

[A. Maitland Bottoms]

 Steven == Steven  steve...@gmail.com writes:
Steven I am unable to build a working gqrx-sdr from source due to this bug.

Yes. It is annoying that unstable is being unstable.
As maintainer, I am just goting to sit on my hands a bit longer - to
give a chance to the Boost Transition Team to complete the task
of moving everything to boost1.55.

Alas gqrx-sdr is among the top 5 packages with the longest dependency chain.

https://release.debian.org/transitions/html/boost1.55.html
https://wiki.debian.org/Teams/ReleaseTeam/Transitions
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744171

In other news, as soon as I can get gnuradio 3.7.3 accepted into
wheezy-backports, gqrx-sdr will also be installable from wheezy-backports.

Let's hope the transition binnmus apperat soon,
-Maitland


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

Bug#749749: gqrx-sdr: gqrx segfaults when run

[A. Maitland Bottoms]

Indeed.
This problem has arisen since libuhd003 got rebuilt with
boost 1.55.

I only hope that there will be soon a
Binary-only non-maintainer upload of gqrx-sdr 
and gnuradio to remedy this inconsistency.

Otherwise, I'm sure this particular bug will go away
upon my next upload of gqrx-sdr.

I'm CC'ing the Debian Boost Team to ask for any advice
they can provide about how I can best manage my boost
dependent packages.

-Maitland


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

Bug#733322: comedilib: FTBFS

[A. Maitland Bottoms]

Tags: patch

I pulled out some fixes from Ubuntu
https://launchpad.net/ubuntu/+source/comedilib/0.10.1-1ubuntu2
and added some other Debian bug fixes.

What is not addressed is #732685, since that will take
something beyond what debdiff can represent to get
a new debian source package tarball uploaded and installed...

This builds in current Debian unstable, so solves #733322.

-Maitland

diff -Nru comedilib-0.10.1/debian/changelog comedilib-0.10.1/debian/changelog
--- comedilib-0.10.1/debian/changelog   2013-08-18 04:32:17.0 -0400
+++ comedilib-0.10.1/debian/changelog   2014-03-31 19:11:16.0 -0400
@@ -1,3 +1,26 @@
+comedilib (0.10.1-2) unstable; urgency=low
+
+  * Bring in Ubuntu fixes (patch from A. Maitland Bottoms)
+   (Closes: #727345, #733322, #711203)
+
+ -- Gudjon I. Gudjonsson gud...@gudjon.org  Mon, 31 Mar 2014 22:40:31 +0200
+
+comedilib (0.10.1-1ubuntu2) trusty; urgency=low
+
+  * Use dh-autoreconf to resolve FTBFS on ppc64el.
+
+ -- Daniel T Chen crim...@ubuntu.com  Wed, 08 Jan 2014 13:12:42 -0500
+
+comedilib (0.10.1-1ubuntu1) trusty; urgency=low
+
+  * FTBFS fixes:
+- Backport upstream changesets 90ce9a9, cc0c9e7, f4e228e, c689eff,
+  and 2277e82;
+- Use explicit parameters.
+  * Closes: #733322. LP: #1264686.
+
+ -- Daniel T Chen crim...@ubuntu.com  Tue, 07 Jan 2014 17:22:30 -0500
+
 comedilib (0.10.1-1) unstable; urgency=low
 
   * New upstream release
diff -Nru comedilib-0.10.1/debian/control comedilib-0.10.1/debian/control
--- comedilib-0.10.1/debian/control 2013-04-27 17:12:24.0 -0400
+++ comedilib-0.10.1/debian/control 2014-03-31 18:43:02.0 -0400
@@ -2,7 +2,7 @@
 Section: devel
 Priority: optional
 Maintainer: Gudjon I. Gudjonsson gud...@gudjon.org
-Build-Depends: debhelper (= 9), dpkg-dev (= 1.16.1~), python-all-dev, 
autotools-dev,
+Build-Depends: debhelper (= 9), dpkg-dev (= 1.16.1~), python-all-dev, 
dh-autoreconf,
  swig, docbook-utils, dblatex, bison, flex, libtool, xmlto, imagemagick, fop,
  libboost-program-options-dev, libgsl0-dev, hardening-wrapper
 Standards-Version: 3.9.4
diff -Nru comedilib-0.10.1/debian/libcomedi0.dirs 
comedilib-0.10.1/debian/libcomedi0.dirs
--- comedilib-0.10.1/debian/libcomedi0.dirs 2012-06-03 19:35:26.0 
-0400
+++ comedilib-0.10.1/debian/libcomedi0.dirs 2014-03-31 19:14:12.0 
-0400
@@ -6,3 +6,4 @@
 usr/share/doc/libcomedi0/
 etc/pcmcia/
 lib/udev/rules.d/
+var/lib/comedi/calibrations
diff -Nru comedilib-0.10.1/debian/libcomedi0.install 
comedilib-0.10.1/debian/libcomedi0.install
--- comedilib-0.10.1/debian/libcomedi0.install  2012-06-03 19:35:38.0 
-0400
+++ comedilib-0.10.1/debian/libcomedi0.install  2014-03-31 19:10:51.0 
-0400
@@ -1,11 +1,12 @@
+etc/pcmcia/*
+lib/udev/*
 usr/lib/libcomedi.so.*
 #usr/lib/ruby/*
-usr/sbin/*
+usr/bin/comedi_board_info
 usr/bin/comedi_calibrate
+usr/bin/comedi_soft_calibrate
 usr/bin/comedi_test
+usr/sbin/*
 usr/share/man/man7/*
 usr/share/man/man8/*
 usr/share/doc/comedilib/*.conf usr/share/doc/libcomedi0/
-etc/pcmcia/*
-lib/udev/*
-
diff -Nru comedilib-0.10.1/debian/patches/04_bison.patch 
comedilib-0.10.1/debian/patches/04_bison.patch
--- comedilib-0.10.1/debian/patches/04_bison.patch  2013-08-14 
16:58:59.0 -0400
+++ comedilib-0.10.1/debian/patches/04_bison.patch  1969-12-31 
19:00:00.0 -0500
@@ -1,59 +0,0 @@
-Description: Fix build failure with bison 2.6
-Origin: upstream,
- 
http://comedi.org/git?p=comedi/comedilib.git;a=commitdiff;h=90ce9a94bdb6b26a9cbffdf2e9922b0b1f668a65;hp=3dfae5a6ee6040d294493f3856a3949e1b602af0
-Bug-Debian: http://bugs.debian.org/710622
-Last-Update: 2013-08-11
-
 comedilib-0.10.0.orig/lib/calib_yacc.y
-+++ comedilib-0.10.0/lib/calib_yacc.y
-@@ -28,13 +28,14 @@
- #include math.h
- #include string.h
- #include stdlib.h
--#include calib_yacc.h
--#include calib_lex.h
- 
- #define YYERROR_VERBOSE
- #define YYPARSE_PARAM parse_arg
- #define YYLEX_PARAM priv(YYPARSE_PARAM)-yyscanner
- 
-+#include calib_yacc.h
-+#include calib_lex.h
-+
- enum polynomial_direction
- {
-   POLYNOMIAL_TO_PHYS,
-@@ -347,6 +348,11 @@ extern comedi_calibration_t* _comedi_par
-   return priv.parsed_file;
- }
- 
-+static void yyerror(const char *s)
-+{
-+  fprintf(stderr, %s\n, s);
-+}
-+
- %}
- 
- %pure_parser
-@@ -504,10 +510,5 @@ extern comedi_calibration_t* _comedi_par
- 
- %%
- 
--void calib_yyerror(char *s)
--{
--  fprintf(stderr, %s\n, s);
--}
--
- 
- 
 comedilib-0.10.0.orig/lib/libinternal.h
-+++ comedilib-0.10.0/lib/libinternal.h
-@@ -146,8 +146,6 @@ int valid_chan(comedi_t *it,unsigned int
- int comedi_get_rangetype(comedi_t *it,unsigned int subdevice,unsigned int 
chan);
- 
- #define YY_DECL int calib_yylex(YYSTYPE *calib_lvalp, yyscan_t yyscanner)
--void calib_yyerror(char *s);
--int calib_yyparse(void *parse_arg);
- 
- #endif
- 
diff -Nru comedilib-0.10.1/debian/patches/04_new_bison.patch 
comedilib-0.10.1/debian/patches/04_new_bison.patch
--- comedilib-0.10.1/debian

Bug#728223: dime: FTBFS on kFreeBSD: libtool can't build shared libraries

[A. Maitland Bottoms]

 Aaron == Aaron M Ucko u...@debian.org writes:
Aaron Thanks for the prompt fix to #728212!  Linux and Hurd builds now
Aaron succeed, but kFreeBSD builds are still failing, as libtool (presumably
Aaron an old version) doesn't know how to build shared libraries there:

Prompt after letting the package bitrot for 8 years

I was hoping the new dh sequencer with --with autotools_dev would save the day.

This might be what dh_autoreconf is all about.

-Maitland


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

Bug#718990: zeroc-ice: FTBFS

[A. Maitland Bottoms]

Source: zeroc-ice
Version: 3.5.0-1
Severity: serious
Tags: patch

The Debian package auto-build systems are failing
on creating the python3-zeroc-ice package.

# moving files (python3 policy)
mv debian/python3-zeroc-ice/usr/lib/python3.*/dist-packages/*.so* 
debian/python3-zeroc-ice/usr/lib/python3/dist-packages
mv: cannot stat 
'debian/python3-zeroc-ice/usr/lib/python3.*/dist-packages/*.so*': No such file 
or directory

You should have moved out of debian/tmp instead of debian/python3-zeroc-ice.
This simple fix allowed me to build on a current
Debian unstable system.

-Maitland

enc:
--- orig/zeroc-ice-3.5.0/debian/rules-py.mk 2013-07-30 15:57:44.0 
-0400
+++ fixed/zeroc-ice-3.5.0/debian/rules-py.mk2013-08-07 10:38:11.0 
-0400
@@ -40,5 +40,5 @@ override_dh_python3:
dh_python3
# moving files (python3 policy)
-   mv debian/python3-zeroc-ice/usr/lib/python3.*/dist-packages/*.so* 
debian/python3-zeroc-ice/usr/lib/python3/dist-packages
+   mv debian/tmp/usr/lib/python3.*/dist-packages/*.so* 
debian/python3-zeroc-ice/usr/lib/python3/dist-packages
 
 clean-py:

Bug#712999: linux-image-3.9-1-amd64: Unable to find LVM volume

[A. Maitland Bottoms]

I think I was just bit by this bug.

Getting from wheezy-backports today,
initramfs-tools   0.112~bpo70+1
linux-image-3.9-0.bpo.1-amd64 3.9.6-1~bpo70+1

I found that adding rootdelay=1 to the grub boot kernel argument list
was enough to get linux-image-3.9-0.bpo.1-amd64 to boot.

My system is AMD64 Phenom II with 6.0 Gbps SATA and SSD,
I suppose too fast for the kernel lvm finding logic without
the rootdelay parameter set. (Then again, stock wheezy
linux-image-3.2.0-4-amd64 3.2.46-1 boots just fine
without that parameter sepecified.)

Hope that helps,
-Maitland


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

Bug#667079: uhd: FTBFS: error: 'rx_dsp_buff_size' was not declared in this scope

[A. Maitland Bottoms]

 Christoph Egger christ...@debian.org writes:
 /build/buildd-uhd_3.4.0-2-kfreebsd-amd64-jnOr7B/uhd-3.4.0/host/examples/network_relay.cpp:210:111:
  error: 'rx_dsp_buff_size' was not declared in this scope

Leading up to that is uhd-3.4.0/host/include/uhd/config.hpp
// Platform defines for conditional parts of headers:
// Taken from boost/config/select_platform_config.hpp,
// however, we define macros, not strings for platforms.
#if defined(linux) || defined(__linux) || defined(__linux__)
#define UHD_PLATFORM_LINUX
#elif defined(_WIN32) || defined(__WIN32__) || defined(WIN32)
#define UHD_PLATFORM_WIN32
#elif defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__)
#define UHD_PLATFORM_MACOS
#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
#define UHD_PLATFORM_BSD
#endif

and uhd-3.4.0/host/examples/network_relay.cpp
#if defined(UHD_PLATFORM_MACOS) || defined(UHD_PLATFORM_BSD)
//limit buffer resize on macos or it will error
const size_t rx_dsp_buff_size = size_t(1e6);
#elif defined(UHD_PLATFORM_LINUX) || defined(UHD_PLATFORM_WIN32)
//set to half-a-second of buffering at max rate
const size_t rx_dsp_buff_size = size_t(50e6);
#endif


From the error it looks like UHD_PLATFORM_BSD remained undefined.
Isn't __FreeBSD__ defined in g++ for Debian's kfreebsd architectures?

What do the debian-bsd folk recommend doing here?

-Maitland



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

Bug#582565: vtk: FTBFS with python 2.6 because of hard-coded site-packages directory

[A. Maitland Bottoms]

Upload will be soon, vtk 5.4.2-7 is building now.
I had to spend some time reorganizing my local git tree,
which kept me from uploading yesterday.

Once git-buildpackage finishes I'll git-push and
upload.

-Maitland



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

Bug#571519: vtk: FTBFS with Python 2.6 as default

[A. Maitland Bottoms]

Yes, there were a few hardcoded python2.5 paths.
Thanks for checking.

The package control file specifies
XS-Python-Version: current

And now that
http://git.debian.org/?p=collab-maint/vtk.git;a=commit;h=d809bf34bb587c7be44087d430f512adbaf0a553
has been applied, vtk 5.4.2-6 and onwards should build with Python 2.6 as 
default.

This bug is tagged pending while I actually check that Python 2.6
builds work before uploading.

-Maitland



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

Bug#560952: CVE-2009-3560 and CVE-2009-3720 denial-of-services

[A. Maitland Bottoms]

The Debian packages build with the following configuration:
VTK_USE_SYSTEM_EXPAT:BOOL=ON

so the VTK components will use the systemwide
/usr/lib/libexpat.so.1 from the fixed Debian
libexpat1 package.

So while the upstream source includes source for
libexpat, it is not used to create te Debian binaries.

-Maitland



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

Bug#544674: VTK #545335

[A. Maitland Bottoms]

It appears that fixing 544674 will fix the powerpc/ppc problem
in bug 545335. It might be worth making a cmake 2.6.4-3 upload
for this including the findjni2.cmake.patch.

-Maitland



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

Bug#529961: [Python-apps-team] Bug#534524: Bug#534524: mayavi2: at runtime, ImportError: No module named libvtkCommonPython

[A. Maitland Bottoms]

Varun Hiremath writes:
...
  A new version of python-vkt 5.2.1-6 was uploaded today which seems to
  fix #529961. But, for me there is no change in the behavior. I am
  still able to import vtk but not libvtkCommonPython. Does the new
  version work for you?
  
  Regards,
  Varun
  
  ===
  $$ ipython
  --(09:35:21 PM)--
  Python 2.5.4 (r254:67916, Feb 18 2009, 03:00:47)
  Type copyright, credits or license for more information.
  
  IPython 0.8.4 -- An enhanced Interactive Python.
  ? - Introduction and overview of IPython's features.
  %quickref - Quick reference.
  help  - Python's own help system.
  object?   - Details about 'object'. ?object also works, ?? prints
  more.
  
  In [1]: import vtk
  
  In [2]: from libvtkCommonPython import *

Shouldn't that be:

from vtk.libvtkCommonPython import *

That works for me.

-Maitland



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

Bug#529961: python-vtk breaks mayavi2

[A. Maitland Bottoms]

Drew Parsons writes:
  Hope it's not too hard to find out what's wrong, sorry I'm not sure how
  to help!

I am building vtk 5.2.1-6 right now and I am hopeful that it will
improve the python-vtk package situation.

-Maitland



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

Bug#408013: startup crash on amd64 - no suitable windowing system found, exiting.

[A. Maitland Bottoms]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: openoffice.org
Version: 2.0.4.dfsg.2-2
Severity: grave
Justification: renders package unusable

$ oowriter
no suitable windowing system found, exiting.

** (process:26780): WARNING **: Unknown error forking main binary / abnormal 
early exit ...


On Etch systems I have tried, openoffice 2.0.4.dfsg.2-2 applications give the 
above
complaint on amd64. On i386 and powerpc the applications start up and function 
normally.

Other X using applications work fine, so openoofice.org should have found a
suitable windowing system. In fact, the working i386 and powerpc systems were
displaying fine via ssh -X on my amd64 system.

Since there is no Floating point complaint, this seems different from #407040.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/

iD8DBQFFtTm/kwbJvNrxBUwRAiRVAKCFAik197OFGSi7mXP+KU65ITA3QwCfTV9s
uuzJ1zLhp0KrmXhOq2JaXL0=
=KLYY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#383888: vtk failed to build from sources

[A. Maitland Bottoms]

What version of cmake was pbuilder using?
(Maybe I need to bump up the versioned depends upon cmake.)

I'll try to duplicate this result...

-Maitland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#373406: Python policy transition

[A. Maitland Bottoms]

vtk 5.0.1-1 is making use of dh_python, and
it and mayavi_1.5-2 have been seen running
correctly with python2.4 as the default python.

There may be additional refinements to improve
python policy compliance, but I have uploaded
vtk_5.0.1-1 and mayavi_1.5-2 to support the
transition to python2.4 as default.

-Maitland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#383888: vtk failed to build from sources

[A. Maitland Bottoms]

OK,
I have just successfully built vtk 5.0.1
in a pbuilder environment.

Perhaps you were trying vtk 4.4.2 and filed
a duplicate of bug #379240? Your bug report
doesn't say, but since 5.0.1 is still new,
I am guessing that you saw the bug on version
4.4.2-10.

-Maitland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379240: FTBFS: Attempt to add link library vtkCommonPython which is not a library target

[A. Maitland Bottoms]

OK,
I am uploading vtk 5, maybe that will fare better.

Patches/NMU welcome this week, I'll get back to work on it myself
around 1 August.

-Maitland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#339276: vtk_4.4.2-9_i386.changes is NEW (was Bug#339276: patch for RC bugs attached)

[A. Maitland Bottoms]

Stephen Gran [EMAIL PROTECTED] writes:
  Attached is a patch for the 4 RC bugs against you package.  I am
  uploading now to a delayed queue.  If you want to override this NMU,
  please upload a fixed version yourself.

Thanks! But...
There is a -9 version in NEW that addresses these bugs,
http://ftp-master.debian.org/new.html

debian-devel-changes on Tue, 10 Jan 2006 19:47:13 -0800:
  
  libvtk4-dev_4.4.2-9_all.deb
to pool/main/v/vtk/libvtk4-dev_4.4.2-9_all.deb
  (new) libvtk4c2a_4.4.2-9_i386.deb optional libs
  
...
  
  Changes: vtk (4.4.2-9) unstable; urgency=low
   .
* renamed libvtk4c2 to libvtk4c2a(libstdc++ allocator change) (Closes: 
  #339276)
* New X dependencies - (Closes #346505)
* patch QVTKRenderWindowInteractor.py invocation of the QWidget 
  constructor (Closes: #333812)
  Announcing to debian-devel-changes@lists.debian.org
  Closing bugs: 333812 339276 
  
  
  Your package contains new components which requires manual editing of
  the override file.  It is ok otherwise, so please be patient.  New
  packages are usually added to the override file about once a week.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#302160: openoffice.org: crashes when trying to read a non-ascii character from afm file

[A. Maitland Bottoms]

Version: 1.1.3-7
Sarge system

Yes, I encountered this on a system that still had some fonts in a
/usr/X11R6/lib/X11/fonts/WordPerfect/
directory. (Not Debian's fault...)

Got rid of those and OpenOffice.org is happy to run again.

-Maitland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#294404: (no subject)

[A. Maitland Bottoms]

On Date: Tue, 29 Mar 2005 03:57:27 -0800 Steve Langasek [EMAIL PROTECTED] 
posted:
mdadm-294404.diff

Almost there, I think. However, it didn't fix my broken md+udev+2.6.8-2-686-smp
system. After installing mdadm_1.9.0-2.1_i386.deb built using the patch, the
system startup link still had

S25mdadm-raid - ../init.d/mdadm-raid

Doing by hand:
update-rc.d -f mdadm-raid start 4 S . start 50 0 6 .
 System startup links for /etc/init.d/mdadm-raid already exist.

So somehow the package should do a

update-rc.d -f mdadm-raid remove

before the 

update-rc.d mdadm-raid start 4 S . start 50 0 6 .

on upgrade to take care of this situation.

-Maitland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#293079: aolserver4-nsd does not run on Alpha

[A. Maitland Bottoms]

Package: aolserver4
Version: 4.0.10-1
Severity: serious

(Severity: grave on Alpha)
Seems not to like the size of int and long:

~# aolserver4-nsd -u www-data -t /etc/aolserver4/aolserver4.tcl
NsTclInitObjs: sizeof(int)  sizeof(long)

-Maitland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]