Bug#813344: wx3.0-i18n and trustedqsl: error when trying to install together
Agreed: clearly trustedqsl's fault (they're in the upstream tarball for some reason!). I'll fix it post-haste. -Kamal
Bug#752514: libfftw3 SIGILL on armhf
I'm investigating an armhf FTBFS of my package 'minimodem'[0], which I now suspect might be caused by this libfftw3 bug in unstable: #767138 fftw3: runtime detection of NEON is perhaps broken https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767138 There, Edmund points out that #752514 ruby-fftw3: FTBFS on armhf [1] is possibly caused by that fftw3 bug. But Cédric notes that he was unable to reproduce the ruby failure on harris.debian.org. I am seeing exactly the same issues with minimodem: On the armhf buildd builders (only), minimodem compiles fine but then all its test cases fail. But when I try it on harris.d.o (or asachi.d.o), I cannot reproduce any problem. But I've just discovered that I *can* reproduce the minimodem crash on abel.debian.org, and it points to libfftw3: Linux abel 3.16-0.bpo.2-armmp-lpae #1 SMP Debian 3.16.3-2~bpo70+1 (2014-09-21) armv7l GNU/Linux (sid_armhf-dchroot) Program received signal SIGILL, Illegal instruction. 0xb6f47e9a in ?? () from /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3 For comparison, harris and asachi (where no problem occurs) are: Linux harris 3.2.0-4-mx5 #1 Debian 3.2.63-2+deb7u1 armv7l GNU/Linux (sid_armhf-dchroot) Linux asachi 3.16-2-arm64 #1 SMP Debian 3.16.3-2 (2014-09-20) armv8l GNU/Linux (sid_armhf-dchroot) Edmund et al., I would appreciate your expertise here... Does it also appear to you that my minimodem (0.20-1) failure[0] could be caused by the fftw3 NEON is perhaps broken bug? Does it make sense that abel.d.o would be affected by it, but harris and asachi would not? Cédric, you might want to re-try your ruby-fftw3 build test on abel.debian.org and consider re-opening #752514 [1]. Hector, could this situation result in a possible inconsistency among the armhf buildd's? (Or at least, among the porterbox armhf chroots)? All: Should the severity of the libfftw3 bug #767138 be elevated to serious? Thanks in advance for your help, -Kamal [0] #769974 minimodem: FTBFS on armhf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769974 To replicate the minimodem failure for debugging: (sid_armhf-dchroot)$ echo hello | src/minimodem --tx -f /tmp/foo.wav 1200 # this does not call libfftw3 (sid_armhf-dchroot)$ gdb --args src/minimodem --rx -f /tmp/foo.wav 1200 ... Program received signal SIGILL, Illegal instruction. 0xb6f47e9a in ?? () from /usr/lib/arm-linux-gnueabihf/libfftw3f.so.3 [1] #752514 ruby-fftw3: FTBFS on armhf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752514
Bug#707386: grig: diff for NMU version 0.8.0-1.1
On Tue, 2013-05-21 at 18:19 +0200, Sebastian Ramacher wrote: Control: tags -1 + patch pending Dear maintainer, I've prepared an NMU for grig (versioned as 0.8.0-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards Thanks, Sebastian! Your help is very much appreciated! -Kamal signature.asc Description: This is a digitally signed message part
Bug#679792: fldigi bundles Tango Icon Library pixmaps licensed CC-BY-SA-2.5
Package: fldigi Version: 3.21.45-1 Severity: serious Tags: upstream Justification: Policy 2.1 Fldigi (src/misc/pixmaps.cxx) bundles pixmaps converted from an old version of the Tango Icon Library which indicates its license as CC-BY-SA-2.5, a license which is not suitable for Debian main. Note that this has been fixed in fldigi 3.21.48 upstream (the old pixmaps are replaced by new ones from a more recent version Tango Icon Library that was released into the public domain). -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652618: cwdaemon: FTBFS, build-depends can no longer be fullfilled
owner ka...@whence.com
thanks
[ adding Kamil Ignacak, the new upstream author/maintainer of
unixcw/libcw ]
Hi Alexander-
Thank you very much for noticing the breakage. This does indeed result
from problems with the newly refurbished 'unixcw' source package that I
recently uploaded for Kamil ...
On Mon, 2011-12-19 at 14:26 +0100, Alexander Reichle-Schmehl wrote:
tags 652618 +patch
thanks
[ adding the unixcw maintainer to the loop ]
[ also adding Michael as Cc, as last NMUer of the package he might have
interest in it ]
Hi!
* Alexander Reichle-Schmehl toli...@debian.org [111219 11:09]:
I'm sorry, but I fear your package will FTBFS starting with the next
dinstall run. Background is that unixcw dropped to build the package
unixcw-dev on which cwdaemon build-depends. And well... I cruft-removed
said package by mistake just now.
I guess that the new build-dependency should be libcw3-dev, but I haven't
checked.
The good news is that I kind of fixed it. The bad news is, that I can't
test the resulting package. Also just replacing the build-depens on
unixcw-dev with libcw3-dev didn't solved the issue, I guess that means
that the Provides: unixcw-dev of libcw3-dev is not true.
You're correct. the renamed libcw3{-dev} packages don't properly
Provide unixcw{-dev}, but they should. We'll fix that.
I had to do some further changes (see attached debdiff). To my
understanding the calls cw_set_soundcard_sound and cw_set_console_sound
are no longer necessary, as libcw automatically picks the right one?
Lets ask the new upstream author/maintainer... Kamil, can you comment
on that? Did you eliminate those routines from the new libcw?
Well, at least with the attached changes it builds again. So far, so
good, however I couldn't actually check the resulting package.
That being said, here are a couple of questions:
1) Is this package actually being used? Orphaned since two years, no
reverde depends (only one suggests by xlog), pretty low popcon (but a
special package), no upstream development.
2) Is the patch correct? Anyone can test it?
And for the Debian Hamradio Maintainers:
3) Shouldn't libcw3-dev have a dependency on libasound2-dev? Apparently
that's needed for successfull linking.
4) Are libcw's pc files correct? As you can see, I also had to add also
to the CFLAGS and lib calls.
5) Wouldn't you like to adopt cwdaemon, if it's worth to be kept?
I do think cwdaemon is worth keeping, and I will adopt it.
Kamil and I will fix unixcw/libcw3 and then I will apply whatever
remaining bits of your patch to cwdaemon are still necessary.
Best Regards,
Alexander
Thanks again!
-Kamal
signature.asc
Description: This is a digitally signed message part
Bug#652176: cqrlog: FTBFS: unsatisfiable build-dependencies: lazarus-0.9.30, lcl-0.9.30
On Thu, 2011-12-15 at 12:14 +0100, Mònica Ramírez Arceda wrote: Source: cqrlog Version: 1.2.1-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20111210 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. I cannot reproduce this build failure of cqrlog-1.2.1-1. The following packages have unmet dependencies: sbuild-build-depends-cqrlog-dummy : Depends: lazarus-0.9.30 but it is not installable Depends: lcl-0.9.30 but it is not installable E: Broken packages cqrlog-1.2.1-1 builds fine in my amd64 sid pbuilder. Note that the package 'lazarus-0.9.30' has indeed been renamed 'lazarus-0.9.30.2' and likewise for 'lcl-0.9.30'. But cqrlog's build-deps are satisfiable because cqrlog's Build-Depends includes: lazarus-0.9.30 | lazarus (= 0.9.29), lcl-0.9.30 | lcl (= 0.9.30) which get satisfied by these packages currently in sid: lazarus (0.9.30.2-1) lcl (0.9.30.2-1) I'll mark this bug 'done'. Please re-open and advise if my analysis is incorrect. -Kamal signature.asc Description: This is a digitally signed message part
Bug#559814: hamlib: stable-security fix CVE-2009-3736
Dear security team- I'm the DM maintainer for the package 'hamlib' (I am also currently working through the of becoming a DD). Regarding this bug (a mass-filed CVE against libtool): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559814 CVE-2009-3736 local privilege escalation I fixed this problem for hamlib in unstable (and upstream) some time ago. I have now constructed a fix package for hamlib in stable, for which I ask permission to upload to stable-security. The fix package has been reviewed by Gunnar Wolf, who has kindly agreed to upload it pending approval. The affected package in stable (lenny) is hamlib (1.2.7.1-1) My fix package bears the following changelog entry, which explains the changes. Note also that I updated the Maintainer/Uploaders/DM-Upload-Allowed fields to reflect the current maintainer status for this package. hamlib (1.2.7.1-1+lenny1) stable-security; urgency=high * Fix CVE-2009-3736 local privilege escalation (Closes: #559814): - Use system libltdl not old internal copy - Build-depend on libltdl3-dev - configure, Makefile.am: skip internal libltdl build * New maintainer: Kamal Mostafa ka...@whence.com (Closes: #556098). I have built and tested this fix on a fresh lenny system. For your review, here is the debdiff (minus the re-generated files configure and Makefile.in): http://www.whence.com/debian/proposed/hamlib+lenny1/hamlib+lenny1.patch My fix packages are available here: http://www.whence.com/debian/proposed/hamlib+lenny1 Thanks, -Kamal signature.asc Description: This is a digitally signed message part
Bug#566564: gnuradio: patch adds binary package dep on 'adduser'
Package: gnuradio
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu karmic ubuntu-patch
Attached patch adds binary package dep for libusrp0, libusrp2-0: adduser
This should resolve bug #566564 and bug #566565.
diff -u gnuradio-3.2.2.dfsg/debian/control gnuradio-3.2.2.dfsg/debian/control
--- gnuradio-3.2.2.dfsg/debian/control
+++ gnuradio-3.2.2.dfsg/debian/control
@@ -110,7 +110,7 @@
Package: libusrp0
Section: comm
Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, adduser
Replaces: libusrp0c2a, usrp-firmware
Conflicts: usrp-firmware
Suggests: usrp-doc
@@ -146,7 +146,7 @@
Package: libusrp2-0
Section: comm
Architecture: any
-Depends: libgruel0 (= ${binary:Version}), libgromnithread0 (= ${binary:Version}), ${shlibs:Depends}
+Depends: libgruel0 (= ${binary:Version}), libgromnithread0 (= ${binary:Version}), ${shlibs:Depends}, adduser
Description: Client side library for the USRP2 hardware
The Universal Software Radio Peripheral 2 (USRP2) is a GbE-connected,
low-cost and open board. It features two high-speed analog-to-digital
Bug#517801: please close unreproducible bug
Following up on Joop's message (02 Dec 2009)... Please close this bug, which is holding up 'soundmodem' from entering testing. The reported problem cannot be reproduced by the submitter nor by other testers (including myself). Thanks, -Kamal Mostafa KA6MAL -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559814: ITA: hamlib / new version for upload
After discussion with Steve Conklin (who filed an ITA for 'hamlib' a few months ago) we have determined that I will volunteer to adopt and maintain 'hamlib' instead of him. For reference, I am a ham radio operator (KA6MAL), I do use hamlib regularly, and I have developed applications which use the library. I have packaged the new upstream release (hamlib 1.2.10) which I propose for review and upload by a kindly DD: http://www.whence.com/debian/proposed/hamlib_1.2.10-1.dsc This package includes my fix for bug 559814 (CVE-2009-3736 local libltdl privilege escalation), and minor Python 2.6 changes from Ubuntu. I wasn't sure what to do with the debian/control Uploaders: field. As a placeholder, I set it to the debian-h...@lists.debian.org list address -- I expect that it will be changed by the actual uploader: Uploaders: Debian Hamradio Maintainers debian-h...@lists.debian.org This is my first experience with maintenance of a package at Debian, so I am not at all sure that I'm following the proper procedures here. Any guidance will be much appreciated. Thanks, -Kamal Mostafa ka...@whence.com signature.asc Description: This is a digitally signed message part
Bug#569626: nauty_2.4-1
Thanks David. I confirm that your pending nauty_2.4-1.dsc does build fine in the current Ubuntu 9.10 and the upcoming Ubuntu Lucid. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266161429.2929.3.ca...@fourier
Bug#569626: [PATCH] define macro getline(f) that expands to gtools_getline(f).
On Sat, 2010-02-13 at 05:37 -0400, David Bremner wrote: your patch [...] Did you send it upstream yet? No I didn't. Please do so on my behalf once you're satisfied with the solution. FYI, we're also holding off applying my patch to Ubuntu, given your swift response to this report. -Kamal -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569626: [PATCH] define macro getline(f) that expands to gtools_getline(f).
On Fri, 2010-02-12 at 23:35 -0400, David Bremner wrote: +#define getline(F) gtools_getline(F) Hi David- Redefining getline() there in gtools.h will preclude source files who include gtools.h from using the standard getline() routine, won't it? In my opinion, changing all the references in the nauty source is a better solution. -Kamal -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560644:
Simply removing the x_map line from the libclxclient3.symbols.* files fixes the build on Ubuntu Lucid -- the attached patch applies that change. === modified file 'debian/libclxclient3.symbols.amd64' --- debian/libclxclient3.symbols.amd64 2009-03-14 00:55:50 + +++ debian/libclxclient3.symbols.amd64 2010-01-17 15:36:32 + @@ -296,7 +296,6 @@ _znk8x_window12x_set_attribemp20xsetwindowattribu...@base 3.6.1-1~ _znk8x_window17x_set_bit_gravit...@base 3.6.1-1~ _znk8x_window17x_set_win_gravit...@base 3.6.1-1~ - _znk8x_window5x_ma...@base 3.6.1-1~ _znk8x_window6x_move...@base 3.6.1-1~ _znk8x_window8x_resize...@base 3.6.1-1~ _zti10x_callb...@base 3.6.1-1~ === modified file 'debian/libclxclient3.symbols.i386' --- debian/libclxclient3.symbols.i386 2009-03-14 00:55:50 + +++ debian/libclxclient3.symbols.i386 2010-01-17 15:36:34 + @@ -296,7 +296,6 @@ _znk8x_window12x_set_attribemp20xsetwindowattribu...@base 3.6.1-1~ _znk8x_window17x_set_bit_gravit...@base 3.6.1-1~ _znk8x_window17x_set_win_gravit...@base 3.6.1-1~ - _znk8x_window5x_ma...@base 3.6.1-1~ _znk8x_window6x_move...@base 3.6.1-1~ _znk8x_window8x_resize...@base 3.6.1-1~ _zti10x_callb...@base 3.6.1-1~
Bug#560544: debian/patches/02-fix-ftbfs-and-hrdiagram.dpatch
My previous patch (02-fix_set_item_calls.dpatch) for this problem fixed
the FTBFS but included a subtle regression (thanks James Westby for
noticing).
This new patch (02-fix-ftbfs-and-hrdiagram-opts.dpatch) REPLACES the
previous patch.
It fixes the problem, and has been more carefully tested -- it fixes the
regression and a subsequent race condition bug, both necessary to
implement the intended functionality.
The subtle regression:
The checks in set_{label,diameter}_item e.g.
if (globals::chart_rules.StarLabels == l) return;
need to be pushed down a few lines -- past the program_hr stuff.
The race condition bug:
The set_{label,diameter}_item() accessor routines were checking
globals::hr_program_viewer to determine whether the HR Diagram window had
been started or not -- but that global doesn't get set until the configure
event (maybe a race condition even, for other call stacks). The set routines
need to check globals::hr_program_window instead, and the hr_quit() routine
needs to stomp that global when the window goes down.
02-fix-ftbfs-and-hrdiagram-opts.dpatch
Description: application/shellscript
Bug#560544: debian/patches/02-fix_set_item_calls.dpatch
#! /bin/sh /usr/share/dpatch/dpatch-run
## 02-fix_set_item_calls.dpatch by Kamal Mostafa ka...@whence.com
##
## DP: Fix FTBFS: call set_*_item() accessors functions, not set_item() template
##
## License: This patch is licensed under terms of GPL2, or (at your option)
## any later version.
@DPATCH@
=== modified file 'src/gui/hrdiagram.cc'
--- a/src/gui/hrdiagram.cc 2008-05-17 11:52:11 +
+++ b/src/gui/hrdiagram.cc 2010-01-07 02:53:57 +
@@ -254,8 +254,7 @@
hr_options_label_widgets[i] = item;
if ((GTK_CHECK_MENU_ITEM (options_label_widgets[i]))-active)
- set_item(globals::chart_rules.StarLabels,
- globals::chart_rules.StarLabels, item, false);
+ set_label_item(globals::chart_rules.StarLabels, false);
}
for (unsigned int i = 0; i OPTIONS_DIAMETER_MENU_SIZE; i++) {
@@ -265,8 +264,7 @@
hr_options_diameter_widgets[i] = item;
if ((GTK_CHECK_MENU_ITEM (options_diameter_widgets[i]))-active)
- set_item(globals::chart_rules.StarDiameters,
- globals::chart_rules.StarDiameters, item, false);
+ set_diameter_item(globals::chart_rules.StarDiameters, false);
}
if (menubar) {
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560459:
Attached debian/patches/50-remove-invalid-const.dpatch fixes the FTBFS: scan.ll:791 problem. 50-remove-invalid-const.dpatch Description: application/shellscript
