Bug#517801: Fwd: Re: any news?
Just got this message from Pete... Since he is the only one who reported this bug and we can't repoduce it, nor let Pete test the new version, I suggest we close this bug. Original Message Subject: Re: any news? Date: Wed, 2 Dec 2009 17:05:44 +0800 From: Peter Barrett To: Joop Stakenborg i am no longer using debian at all. cheers pete vk6fun On Wed, Dec 2, 2009 at 3:48 PM, Joop Stakenborg wrote: > Any news on this bug report? > > VK6FUN, how about the offer from Martijn for a new package build which you > can try? > > Regards, > Joop pa3aba at debian dot org >i am no longer using debian at all.cheerspete vk6funOn Wed, Dec 2, 2009 at 3:48 PM, Joop Stakenborg <p...@xs4all.nl> wrote: Any news on this bug report? VK6FUN, how about the offer from Martijn for a new package build which you can try? Regards, Joop pa3aba at debian dot org
Bug#517801: any news?
Any news on this bug report? VK6FUN, how about the offer from Martijn for a new package build which you can try? Regards, Joop pa3aba at debian dot org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515584: sparc installs app-defaults into wrong directory
Judging from the build log, sparc seems to be installing application defaults files into /usr/lib/X11/app-defaults, why is this? Regards, Joop signature.asc Description: Dit berichtdeel is digitaal ondertekend
Bug#515679: xlog: FTBFS: error: #error "Only can be included directly."
Op maandag 16-02-2009 om 22:33 uur [tijdzone +0100], schreef Kurt Roeckx: > Package: xlog > Version: 2.0-1 > Severity: serious > > Hi, > > Your package is failing to build with the following error: > In file included from /usr/include/gtk-2.0/gdk/gdkspawn.h:26, > from /usr/include/gtk-2.0/gdk/gdk.h:52, > from /usr/include/gtk-2.0/gtk/gtk.h:31, > from main.c:32: > /usr/include/glib-2.0/glib/gspawn.h:22:2: error: #error "Only can be > included directly." > make[3]: *** [main.o] Error 1 > I think this may be a dependency issue. We need to wait for a newer GTK+ to enter unstable. > > Kurt > > > Joop PG4I signature.asc Description: Dit berichtdeel is digitaal ondertekend
Bug#497835: gmanedit audit
2008/9/5 Nico Golde <[EMAIL PROTECTED]>: > > The overall code quality is pretty bad from my point of view and this > program should be heavily reworked. > Thanks, I have never had a serious look at the actual code. My job has been to port gmanedit to GTK+ version 2, to make sure this software would not get lost. I will start on a rework in a few weeks time. If you feel the package isn't good enough for Lenny then please remove it from testing. Regards, Joop pa3aba at debian dot org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496383: xastir - broken temp file patch (#496383)
Op zondag 31-08-2008 om 18:06 uur [tijdzone +0200], schreef Gerfried Fuchs: > * Joop Stakenborg <[EMAIL PROTECTED]> [2008-08-28 16:53:41 CEST]: > > Op donderdag 28-08-2008 om 16:06 uur [tijdzone +0200], schreef Tomas > > Hoger: > > > You probably wanted to use: > > > TMPFILE=`mktemp -t` > > > instead of > > > TMPFILE = 'mktemp -t' > > > in your patch for #496383, right? > > > > Ouch, will fix ASAP, thanks! > > You didn't, the required fix required to use backticks instead of > quotes ... > I am sorry, I am not a very good shell script writer. > I'm currently building an NMU to fix this problem (find attached the > interdiff for it). Furthermore, the TMPFILE never gets removed, is there > a particular reason to not do so? > No reason. I will contact upstream so the next version will fix this. > So long, > Rhonda Thanks, Joop signature.asc Description: Dit berichtdeel is digitaal ondertekend
Bug#496383: xastir - broken temp file patch (#496383)
Op donderdag 28-08-2008 om 16:06 uur [tijdzone +0200], schreef Tomas Hoger: > Hi Joop! > > You probably wanted to use: > > TMPFILE=`mktemp -t` > > instead of > > TMPFILE = 'mktemp -t' > > in your patch for #496383, right? > Ouch, will fix ASAP, thanks! > HTH > > -- > Tomas Hoger > > > Joop signature.asc Description: Dit berichtdeel is digitaal ondertekend
Bug#466484: about unresolved file conflict with extra-xdg-menus
Op donderdag 13-03-2008 om 10:24 uur [tijdzone +1100], schreef Hamish Moffatt: > No, upgrading from 1.0-3 still fails: > Ouch, of course... the bug appears when _upgrading_. Thanks for pointing that out. Regards, Joop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466484: about unresolved file conflict with extra-xdg-menus
Hello List, Drew and Hamish, This bug seems to have gone here. Can you guys please check so we might close it? Thanks, Joop PG4I -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466484: Fixed?
I have checked the installation again, the problems seems to be gone. Drew, can you please check this? Could this somehow be related to a package cache not being updated? Thanks, Joop PG4I -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462900: cwdaemon_0.9.4-3(ia64/unstable): FTBFS: missing build-dep?
> I will see if I can do a unixcw build on a ia64 box to find what is wrong. > libcw.pc is generated by using awk from config.h. Could it be a bug in mawk? I just checked a unixcw package build on merkel, which is ia64. libcw.pc is created correctly, so I have no clue why the unixcw ia64 package is corrupted. Maybe you should rebuild it? Anyway, the fault is not in cwdaemon, can you please re-assign it? Thanks, Joop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462900: cwdaemon_0.9.4-3(ia64/unstable): FTBFS: missing build-dep?
2008/1/28, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Package: cwdaemon
> Version: 0.9.4-3
> Severity: serious
>
> There was an error while trying to autobuild your package:
>
> > Automatic build of cwdaemon_0.9.4-3 on caballero by sbuild/ia64 98
> > Build started at 20080127-2123
>
> [...]
>
> > ** Using build dependencies supplied by package:
> > Build-Depends: autotools-dev, debhelper (>= 4.0.0), pkg-config, unixcw-dev
> > (>= 2.3-2)
>
> [...]
>
> > checking for pkg-config... /usr/bin/pkg-config
> > checking pkg-config is at least version 0.9.0... yes
> > checking for UNIXCW... configure: error: Package requirements (libcw) were
> > not met:
> >
> > Package 'libcw' has no Version: field
> >
Very strange...
cwdaemon_0.9.4-2 has been build on all architectures without problems
with unixcw-dev. There was no change in unixcw since the beginning of
July. So why does 0.9.4-3 suddenly fail on ia64? All of the other
builds seem to recognize UNIXCW correctly.
h... looking into the unixcw-dev ia64 package, it seems libcw.pc
is incorrect:
-
prefix=
exec_prefix=/usr
libdir=
includedir=/usr/include
Name: libcw
Description: CW (Morse code) library.
---
on my i386 box it looks like this:
---
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include
Name: libcw
Description: CW (Morse code) library.
Version: 2.3
Requires:
Libs: -L${libdir} -lcw
Cflags: -I${includedir}
--
I will see if I can do a unixcw build on a ia64 box to find what is wrong.
libcw.pc is generated by using awk from config.h. Could it be a bug in mawk?
> > Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > installed software in a non-standard prefix.
> >
> > Alternatively, you may set the environment variables UNIXCW_CFLAGS
> > and UNIXCW_LIBS to avoid the need to call pkg-config.
> > See the pkg-config man page for more details.
> >
> > make: *** [config.status] Error 1
> > dpkg-buildpackage: failure: debian/rules build gave error exit status 2
>
> A full build log can be found at:
> http://buildd.debian.org/build.php?arch=ia64&pkg=cwdaemon&ver=0.9.4-3
>
>
>
>
Joop pa3aba at debian dot .org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460111: python-libhamlib2: Python-dependent version in /usr/share
2008/1/20, Josselin Mouette <[EMAIL PROTECTED]>: > > Here is a simple version that rebuilds everything for all python > versions. > Thanks, much appreciated! I will hopefully upload a new version later tonight (compiling while I am typing this). > BTW, there seems to be a lot of other issues with the package; having a > simple look at the list of lintian errors is scary enough. Not talking > about the incorrect emptiness of the binary-indep target, or the > unnecessary complexity of installing everything by hand. > The complete package is a bit to complex for one person to maintain. In the near future I will transfer ownership to the Debian-Hams team, which might help. The Lintian errors aren't that bad I think and yes, installation should be simplified! > Cheers, > -- > .''`. > : :' : We are debian.org. Lower your prices, surrender your code. > `. `' We will add your hardware and software distinctiveness to > `-our own. Resistance is futile. > > Thanks, joop pa3aba at debian dot org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460111: python-libhamlib2: Python-dependent version in /usr/share
2008/1/10, Josselin Mouette <[EMAIL PROTECTED]>: > * The python module is built in /usr/lib instead > of /usr/lib/python2.X/site-packages; this is probably an > upstream issue but you can work around it without patching. I guess I can simply move the module to the appropriate directory. > * The Debian build process only builds the package for one python > version; this way the module built for python2.4 will not work > with python2.5. You must loop over the supported python versions > to build the module for each of them, and install it in each of > the corresponding /usr/lib/python2.X/site-packages directories. > This means I will need to build all of the hamlib related packages for the different python versions in Debian (I need to start the build process all over again for every python version). There is no way in the hamlib source to only build the python module. This isn't very elegant. > There are examples of how to do that in the python-support documentation > and on the wiki. If you need help, please don't hesitate to ask for a > patch. > I have looked over the docs and wiki a couple of times. It is hard to understand for a python outsider. There are so many issues, it's all very confusing. So, yes a patch would be very much appreciated to have this resolved! > > Cheers, > -- Thanks, Joop pa3aba at debian dot org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454972: closed by Joop Stakenborg <[EMAIL PROTECTED]> (Bug#454972: fixed in xnec2c 1.0b3-2)
2007/12/8, Kurt Roeckx <[EMAIL PROTECTED]>: > reopen 454972 > notfixed 454972 1.0b3-2 > thanks > > > From: Joop Stakenborg <[EMAIL PROTECTED]> > > Date: Sat, 08 Dec 2007 16:47:06 + > > > >* Set exe bit for configure and some other files. > > Closes: #454972, #454968. > > I still get the same error. Note that you can't have mode changes in a > diff file. You need to do those in your rules file, and I didn't seem > them in the buildd log. > Thanks, should have thought of that. Will get to it tomorrow. > > Kurt > > > > Joop -- Linux for your hamradio desktop ___ http://www.qsl.net/pg4i/linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447315: bug is not fixed in version 0.0.6-15
> notfixed 447315 0.0.6-15 > > The bug is not fixed in version 0.0.6-15 it still clashes during > installation with the package "listen" with the error message: > > trying to overwrite `/usr/share/man/man1/listen.1.gz', which is also in > package listen > Forgot to remove the manual page bummer Will take care of that. > Thanks > > Thanks, Joop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444092:
Upstream has been contacted about this bugreport. Stay tuned -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444092: xnec2c does not show UI, but three processes running
> Bad news. I installed the gtk-theme-switch package as you suggested, > ran switch2 and tried several theme and font combinations, none of > which enabled xnec2c to run. I still receive the same failures as > outlined in the bug report. > That's bad I will contact the upstram author, maybe he has a clue what it can be. > It appears that my KDE gtk override is still in effect as starting Pan > shows no change in theme. And, yes, I want my Qt style applied to my > GTK+ applications. :-) > I guess that is what you want. It isn't what I expected :-( Anyway, if other GTK+ applications work fine then it is probably not a font or GUI issue... > > You can undo this by removing $HOME/.gtkrc-2.0 > > Thanks, Joop. > > 73, de Nate >> > Regards, Joop -- Linux for your hamradio desktop ___ http://www.qsl.net/pg4i/linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444517: Proposed NMU.
2007/10/18, Kumar Appaiah <[EMAIL PROTECTED]>: > Hi! > > I propose to do an NMU for this bug. I have attached the patch. A > package is available for this here: Hello kumar, I will upload a new version this weekend. I am also the upstream maintainer for happydigger. Regards, Joop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444092: xnec2c does not show UI, but three processes running
> > Here you are, Joop. I haven't updated this laptop for about a week (I'm > on the road in Salt Lake City, UT doing a certification class for my > company). I'll update it when I get back home. > Thanks, that is quick. I am just guessing. Looks like you are running KDE and somehow the font/GUI for xnec2c does not get loaded. Can you try installing the gtk-theme-switch packages, Then run 'switch2', click on the large '+' icon and select a theme and font and click apply. Next, see if xnec2c will run. You can undo this by removing $HOME/.gtkrc-2.0 Thanks, Joop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444092: xnec2c does not show UI, but three processes running
2007/9/26, Nate Bargmann <[EMAIL PROTECTED]>: > > After installing the xnec2c pacakge today, it does not display any UI on > screen. When starting in a term only the following message is printed: > > $ xnec2c > > xnec2c: child process exited > Hi Nate, sorry for the late reply. Been on holiday. xnec2c is working fine here, no clue what is going on. The xnec2c main windows should appear instantly. Maybe a trace helps... $ strace -o trace.txt xnec2c Please send me trace.txt in a private email. Thanks, Joop pa3aba at debian dot org -- Linux for your hamradio desktop ___ http://www.qsl.net/pg4i/linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406991: python-libhamlib2 claims support for python2.3 and 2.5, but only provides the extension for 2.4.
2007/1/15, Matthias Klose <[EMAIL PROTECTED]>:
Package: python-libhamlib2
Version: 1.2.5-7.1
Severity: serious
python-libhamlib2 claims support for python2.3 and 2.5, but only
provides the extension for 2.4. Plus the package seems to be broken in
general:
Hello Matthias.
What makes you say support for 2.3 and 2.5 is present? Isn't python2.4 the
default in Debian? Should I rename the package to python2.4-libhamlib2?
$ python
Python 2.4.4 (#2, Jan 13 2007, 17:50:26)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Hamlib
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named Hamlib
>>>
Here is how I do it:
[EMAIL PROTECTED]:~$ python
Python 2.4.4 (#2, Jan 13 2007, 17:50:26)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
import sys
sys.path.append ('/usr/lib/python-support/site-packages')
import Hamlib
Regards,
Joop, pa3aba at debian dot org (hamlib maintainer)
Bug#400190: amd64 build failure for unixcw - missing -fPIC in testcase...
2006/12/4, Andreas Henriksson <[EMAIL PROTECTED]>: I hope this might help you fix the problem... When I run the attached test.sh in my amd64 unstable pbuilder environment I get the following output: # ./test.sh ++ cat ++ gcc -c conftest.c ++ gcc -shared -o conftest.so conftest.o /usr/bin/ld: conftest.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC conftest.o: could not read symbols: Bad value collect2: ld returned 1 exit status ++ rm -f conftest.c conftest.o ++ test -f conftest.so HTH. -- Regards, Andreas Henriksson Thanks Andreas, much appreciated! Regards, Joop pa3aba at debian dot org
Bug#400190: unixcw: FTBFS on amd64: cp: cannot stat `debian/tmp//usr/lib/libcw.so.0.0': No such file or directory
I have just tried to build unixcw-2.3 on merkel.debian.org (another amd64
machine).
While the build log reports:
-
make[3]: Entering directory `/build/buildd/unixcw-2.3/src/cwlib'
if [ "no" = "yes" ]; then \
x86_64-linux-gnu-gcc -shared -Wl,-soname,libcw.so.0
\
-o libcw.so.0.0.0 cwlib.o; \
else\
if [ "no" = "yes" ]; then \
/usr/bin/ld -G -Wl,-soname,libcw.so.0
\
-o libcw.so.0.0.0 cwlib.o; \
fi \
fi
-
The manual compilation on merkel reports:
-
if [ "yes" = "yes" ]; then \
gcc -shared -Wl,-soname,libcw.so.0 \
-o libcw.so.0.0.0 cwlib.o; \
else\
if [ "yes" = "yes" ]; then \
/usr/bin/ld -G -Wl,-soname,libcw.so.0 \
-o libcw.so.0.0.0 cwlib.o; \
fi \
fi
-
and libcw.so.0.0.0 seems to be created correctly.
I have tried to run the little test program included in configure.ac (which
fails on the build daemon) by hand, it does the following:
cat >conftest.c <<-EOF
int so_test() { return 0; }
EOF
$CC -c conftest.c
$CC -shared -o conftest.so conftest.o
rm -f conftest.c conftest.o
if test -f conftest.so ; then
nm conftest.so | grep -q so_test
if test $? -eq 0 ; then
CC_LINKS_SO="yes"
fi
fi
This test reports success in merkel, so CC_LINKS_SO is set to "yes".
Any idea why this fails on the build daemon?
Regards,
Joop pa3aba at debian dot org
Bug#400190: unixcw: FTBFS on amd64: cp: cannot stat `debian/tmp//usr/lib/libcw.so.0.0': No such file or directory
2006/11/25, Steve Langasek <[EMAIL PROTECTED]>: This is also crap, and the test fails silently because you're not allowed to link objects into a .so on amd64 unless they're built with -fPIC, which is enforced by the toolchain. Guessing how to build shared objects on different platforms is a total waste of time. Upstream should switch to libtool and be done with it. Thanks Steve for the hint! I will inform upstream and see if we can come up with a solution... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ Regards, Joop pa3aba at debian dot org
Bug#400190: unixcw: FTBFS on amd64: cp: cannot stat `debian/tmp//usr/lib/libcw.so.0.0': No such file or directory
2006/11/24, Lucas Nussbaum <[EMAIL PROTECTED]>: Package: unixcw Version: 2.2-15 Severity: serious Justification: FTBFS on amd64, already has amd64 binaries in etch Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on amd64. Relevant parts: ln -sf unixcw debian/tmp/usr/share/doc/unixcw-dev dh_install --sourcedir=debian/tmp cp: cannot stat `debian/tmp//usr/lib/libcw.so.0.0': No such file or directory dh_install: command returned error code 256 make: *** [install-arch] Error 1 Very weird. All architectures build fine, so why does amd64 fail? libcw.so.0.0.0 seems to be created correctly. The log doesn't make sense to me... -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | Joop -- Linux for your hamradio desktop ___ http://www.qsl.net/pg4i/linux
