Bug#751448: netexpect: FTBFS with wireshark 1.12.0~rc1-2 from experimental
On 08/01/2014 05:24 PM, Bálint Réczey wrote: 2014-08-01 8:34 GMT+02:00 Bálint Réczey bal...@balintreczey.hu: 2014-08-01 4:07 GMT+02:00 Eloy Paris pe...@chapus.net: On Thu, Jul 31, 2014 at 07:21:18PM -0400, Eloy Paris wrote: [...] So 1.12.0 is now out. It's a bit late but I just uploaded to experimental a new version of netexpect that builds against the Wireshark packages in experimental. Please let me know when you upload the final 1.12 packages to unstable and I'll follow suit with the corresponding netexpect packages to unstable. Looks like I screwed up when I built and my packages ended up unstable instead of experimental. If you are uploading your 1.12 packages soon then this should not be a problem. Otherwise I'd have to re-upload the old packages after playing some games with the version number. Gggr. No problem, I'll upload wireshark today or on the weekend. Done. :-) Thanks Bálint. It looks like I have some issues, though, because the autobuilders are having problems building netexpect 0.22-1 against the new Wireshark 1.12 packages. It's strange because I was able to build i386 packages, which are what I uploaded into unstable. I'll look into it this weekend. Cheers, Eloy.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751448: netexpect: FTBFS with wireshark 1.12.0~rc1-2 from experimental
Hi Bálint, On Sat, Aug 02, 2014 at 08:27:27PM +0200, Bálint Réczey wrote: 2014-08-02 18:43 GMT+02:00 Eloy Paris pe...@chapus.net: It looks like I have some issues, though, because the autobuilders are having problems building netexpect 0.22-1 against the new Wireshark 1.12 packages. It's strange because I was able to build i386 packages, which are what I uploaded into unstable. I'll look into it this weekend. According to the build logs 0.22-1 failed with wiresark 1.10.8-1, thus a binNMU may be enough. Ah, I missed that; thanks for pointing it out. I think this is a bug in my packaging -- I should build-depend on the = 1.12.0 packages. Right now the build-depends are for = 1.10.0. It's all architectures that are failing so I think I'd have a hard time finding a way to build to be able to do binNMUs. The situation should hopefully right itself after I uploaded new packages with the right build-depend versioning. I'll try that although the situation should also fix by itself after the new 1.12.0 packages are installed for all architectures and the autobuilders try again. But better to use the right build-depends anyway. Cheers, Eloy.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741738: Ubuntu equivalent bug
Ubuntu bug #1159361 tracks the same issue: https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1159361 The steps in comment #8 fixed the issue for me: -- 1) Keep the default zone apache.conf without the ScriptAlias. 2) Stop both zoneminder and apache2 sudo service apache2 stop sudo service zoneminder stop 2) Remove any stale sockets from /tmp/zm (default location): sudo rm -vf /tmp/zm/*.* 3) sudo a2enmod cgi 4) Start zoneminder sudo service zoneminder start 5) Start apache2 sudo service apache2 start I found out that the order was important for step 4 and 5, otherwise it doesn't work. -- Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741351: Workaround and upstream bug
/usr/share/doc/spamassassin/README.Debian.gz contains this: Some users have reported difficulty running spamd with an IPv6 listening address. As a work around, please ensure you have libio-socket-inet6-perl installed. However, I had libio-socket-inet6-perl installed and still was unable to start spamd. After a quick search I found what seems to be the upstream bug: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6953 A comment in the bug says the following about workarounds: So workarounds are: - specify 0.0.0.0 or :: explicitly with a --listen (-i) spamd option - or, install module IO::Socket::IP version 0.09 or later - or, deinstall IO::Socket::INET6 I installed libio-socket-ip-perl and that allowed spamd to start. README.Debian should probably be updated to reflect the correct workaround. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751448: netexpect: FTBFS with wireshark 1.12.0~rc1-2 from experimental
Hi Bálint, I'm looking into this. Unfortunately, libwireshark is still not documented and open to external programs and the only way to figure out what changes between releases is to study the libwireshark-based programs shipped with the Wireshark source (tshark, for example), so it takes some time. My goal right now is to make netexpect build even if it doesn't run because of API changes. That at least will allow me to upload to unstable to prevent Wireshark packages from not migrating into testing. In any case, I've found two include files that are not shipped with the latest experimental -dev packages. Could you ship them in the next upload? The files are: nstime.h - /usr/include/wireshark/wsutil/ (libwsutil-dev) filesystem.h - /usr/include/wireshark/epan/ (libwireshark-dev) Thanks for the heads up regarding the upcoming Wireshark 1.12 packages. Cheers, Eloy Paris.- On Fri, Jun 13, 2014 at 12:40:39AM +0200, Bálint Réczey wrote: Package: netexpect Version: 0.21-2 Severity: important Hi Eloy, Wireshark will be updated to the next major upstream release (1.12.0) in unstable in a few weeks. Please make sure that netexpect builds with the new release. For helping the transition wireshark 1.12.0~rc1-2 has been uploaded to experimental. The severity of this bug will be bumped to serious when 1.12.0 enters unstable. Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751975: rancid: New upstream release 3.1
Package: rancid Version: 2.3.8-6 Severity: wishlist Tags: patch Hi Roland, The latest RANCID version available for Debian, 2.3.8-6 which is patched as 2.3.8.p4, was generating a lot of false positives (emails with diffs for non-configuration changes, i.e. temperatures, fan speeds, etc.) for new IOS XE and NX-OS releases. These false positives are gone with the filtering performed in the latest RANCID 3.1 release. I created local packages for 3.1 and things are working very well. Please consider packaging 3.1 to address the false positives on recent Cisco software releases and hardware. I am attaching my patches in case they help you to package the new release. I refreshed patches that are still applicable, removed from the series the patches that are no longer applicable, and added a couple of patches (one hack to be able to get the package to build, and the useful usercmd patch to be able to, for example, monitor Cisco ASAs with multiple contexts). My packaging is a quick hack so make sure you compare my files to the files in the official package. Note that the new RANCID is moving a lot of things to Perl modules but their use and location seems non-standard so my package might not be Lintian-free or conform to Debian policy; you'd have to check. Feel free to let me know if you have any questions. Cheers, Eloy Paris.- rancid_3.1-1ubuntu0.debian.tar.gz Description: Binary data
Bug#725072: netexpect: FTBFS after upgrading tcl-dev to 8.6
Hi Sergei, Thanks for the patch. I've just uploaded a new version of my package with your patch. Cheers, Eloy Paris.- netexpect.org On 10/01/2013 02:28 AM, Sergei Golovan wrote: Package: netexpect Version: 0.21-1 Severity: normal Tags: patch Dear Maintainer, We plan to upgrade the default Tcl/Tk version to 8.6 before jessie relese, but this leads to FTBFS of netexpect (see [1] for a build log). The problem is that it build-depends on tcl-dev, but passes --with-tcl and --with-tcl-includes options suitable for tcl8.5-dev. The attached patch fixes this inconsistency. [1] http://sgolovan.nes.ru/debian-tcltk/build-failures/netexpect_0.21-1.dsc.log.gz -- System Information: Debian Release: 7.1 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714535: netexpect: FTBFS with wireshark 1.10 (patch)
Hi Adam,
I uploaded to unstable new netexpect packages, and they just got
accepted. Things now build and work with the new Wireshark 1.10
libraries. Hopefully the new packages will propagate to Ubuntu soon.
Cheers,
Eloy Paris.-
netexpect.org
On 07/05/2013 03:14 PM, Adam Conrad wrote:
Package: netexpect
Version: 0.20-3
Followup-For: Bug #714535
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch
In Ubuntu, I've applied the following naive patch to port to the
wireshark 1.10 API. It looks like the _set_unset calls can probably
just go away, as they're setting members that no longer exist.
As for the frame_data_{reset,destroy} mangling, I made a best-effort
guess as to which to use in which situation, but input from someone
more familiar with the source would probably not be a bad plan.
* fix-libwireshark110-build.patch: Track wireshark 1.10 API (closes: #714535)
Thanks for considering the patch.
... Adam
-- System Information:
Debian Release: wheezy/sid
APT prefers saucy-updates
APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10.0-2-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714535: netexpect: FTBFS with wireshark 1.10 (patch)
On 07/05/2013 03:14 PM, Adam Conrad wrote:
Package: netexpect
Version: 0.20-3
Followup-For: Bug #714535
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu saucy ubuntu-patch
In Ubuntu, I've applied the following naive patch to port to the
wireshark 1.10 API. It looks like the _set_unset calls can probably
just go away, as they're setting members that no longer exist.
As for the frame_data_{reset,destroy} mangling, I made a best-effort
guess as to which to use in which situation, but input from someone
more familiar with the source would probably not be a bad plan.
* fix-libwireshark110-build.patch: Track wireshark 1.10 API (closes: #714535)
Thanks for considering the patch.
Thanks for the effort, Adam; it's really appreciated. And thanks Scott
for filing the FTBS bug.
Network Expect is tightly coupled with libwireshark, so any changes to
libwireshark internals will create problems for Network Expect. That's
what happened here during the Wireshark 1.8 to 1.10 transition.
Unfortunately, libwireshark is tightly integrated into Wireshark and
Tshark, and the API is not documented so each major Wireshark release I
struggle a bit with the changes to Network Expect that are needed to be
able to use the updated libwireshark API in the new Wireshark release.
I'm looking closely at the problem and should be able to upload new,
fixed packages soon (hopefully by the end of this week). I was able to
build after making a few minor changes but I need to test that things
work as they should before uploading. I am also not positive about the
frame_data_cleanup() to frame_data_reset()/frame_data_destroy() changes
so I need to look into that as well.
Cheers,
Eloy Paris.-
netexpect.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679041: transition: wireshark
Hi all, On 06/28/2012 04:43 AM, Bálint Réczey wrote: [...] 2012/6/27 Adam D. Barratt a...@adam-barratt.org.uk: Can we schedule binNMUs for netexpect, or does it require any source changes? Eloy will upload the new netexpect package soon. I uploaded to unstable new netexpect packages built against the new Wireshark 1.8.0 packages yesterday as soon as I saw that Wireshark 1.8.0 had been accepted into unstable. Note that 1.8.0~rc1-1 has been uploaded to the NEW queue weeks ago... [1] In that case, I'm not entirely sure why the transition bug wasn't raised weeks ago... nor what the logic is behind not having uploaded the release version already, given that the upstream schedule claims it was released a week ago. In the past we managed the transition ourselves by quickly updating netexpect after wireshark. Since netexpect does not have too many users yet and netexpect is the only package depending on wireshark it seemed to be a better solution over involving the release team. Should we always open a transition bug? Last time, for the Wireshark 1.4 to 1.6 transition, we were not close to a freeze, but Bálint and I coordinated the transition just like we did this time. The end result was the same -- all packages and their dependencies hitting unstable on the same day. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620714: netexpect: FTBFS everywhere: undefined reference to symbol 'get_credential_info'
Hi KiBi, On 04/03/2011 12:14 PM, Cyril Brulebois wrote: Source: netexpect Version: 0.18-1 Severity: serious Justification: FTBFS Hi, your package FTBFS everywhere, presumably due to toolchain changes: | gcc -DHAVE_CONFIG_H -I. -I. -I.. -Iinclude -I../src/compat/libdnet -I/usr/include -I/usr/include/tcl8.5 -W -Wall -D_U_=__attribute__((unused)) -DNEW_PACKET_LIST -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/wireshark -c md5c.c | /bin/bash ../libtool --tag=CC --mode=link gcc -W -Wall -D_U_=__attribute__((unused)) -DNEW_PACKET_LIST -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/wireshark -o nexp nexp.o util.o nexp_commands.o nexp_log.o cmd_parser.o cmd_scanner.o expect_network.o send_network.o spawn_network.o nexp_pcap.o payload.o wire.o xmalloc.o xstrdup.o tcl_pbuild.o nexp_iface.o tcl_barray.o tcl_packet.o tcl_timeval.o tcl_usr.o tcl_ws-ftypes.o nexp_ghost.o nexp_tgn.o send_expect.o send_receive.o nexp_pbuild.o nexp_tclvars.o tcl_numspec.o nexp_speakers.o util-tcl.o md5c.o pbuild/libpbuild.la numbers/libnumbers.a usr/libusr.a packets/libpackets.a dumbhex/libdumbhex.a missing/libmissing.a -L/usr/lib -ldumbnet -L/usr/lib/wireshark -lwireshark -lwiretap -L/usr/lib -ltcl8.5 -lgmodule-2.0 -lpcap -lm -lglib-2.0 | libtool: link: gcc -W -Wall -D_U_=__attribute__((unused)) -DNEW_PACKET_LIST -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/wireshark -o nexp nexp.o util.o nexp_commands.o nexp_log.o cmd_parser.o cmd_scanner.o expect_network.o send_network.o spawn_network.o nexp_pcap.o payload.o wire.o xmalloc.o xstrdup.o tcl_pbuild.o nexp_iface.o tcl_barray.o tcl_packet.o tcl_timeval.o tcl_usr.o tcl_ws-ftypes.o nexp_ghost.o nexp_tgn.o send_expect.o send_receive.o nexp_pbuild.o nexp_tclvars.o tcl_numspec.o nexp_speakers.o util-tcl.o md5c.o pbuild/.libs/libpbuild.a numbers/libnumbers.a usr/libusr.a packets/libpackets.a dumbhex/libdumbhex.a missing/libmissing.a -L/usr/lib /usr/lib/libdumbnet.so -L/usr/lib/wireshark -lwireshark -lwiretap -ltcl8.5 /usr/lib/libgmodule-2.0.so -lpcap -lm /usr/lib/libglib-2.0.so | /usr/bin/ld: packets/libpackets.a(packets.o): undefined reference to symbol 'get_credential_info' | /usr/bin/ld: note: 'get_credential_info' is defined in DSO //usr/lib64/libwsutil.so.0 so try adding it to the linker command line | //usr/lib64/libwsutil.so.0: could not read symbols: Invalid operation | collect2: ld returned 1 exit status | make[4]: *** [nexp] Error 1 Full build logs: https://buildd.debian.org/status/package.php?p=netexpect I am not sure what is going on. I was just able to build successfully for i386 on an up-to-date unstable chroot. I wonder what this means: //usr/lib64/libwsutil.so.0: could not read symbols: Invalid operation I'll look for a machine with an architecture where it is failing and investigate further. If you have any ideas please let me know. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620714: netexpect: FTBFS everywhere: undefined reference to symbol 'get_credential_info'
On 04/07/2011 11:17 AM, Eloy Paris wrote: [...] | /usr/bin/ld: packets/libpackets.a(packets.o): undefined reference to symbol 'get_credential_info' | /usr/bin/ld: note: 'get_credential_info' is defined in DSO //usr/lib64/libwsutil.so.0 so try adding it to the linker command line | //usr/lib64/libwsutil.so.0: could not read symbols: Invalid operation | collect2: ld returned 1 exit status | make[4]: *** [nexp] Error 1 Full build logs: https://buildd.debian.org/status/package.php?p=netexpect I am not sure what is going on. I was just able to build successfully for i386 on an up-to-date unstable chroot. I wonder what this means: //usr/lib64/libwsutil.so.0: could not read symbols: Invalid operation I'll look for a machine with an architecture where it is failing and investigate further. If you have any ideas please let me know. The problem was easy to fix -- upstream needs to link with -lwsutil. Uploaded packages with this fix and https://buildd.debian.org/status/package.php?p=netexpectsuite=sid reports successful builds in architectures that previously had build problems. Thanks for the report! Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587056: ITP: netexpect -- Network Expect, a framework for manipulating network packets
Package: wnpp Severity: wishlist Network Expect is a framework that allows to easily build tools that can interact with network traffic. Following a script, traffic can be injected into the network, and decisions can be taken, and acted upon, based on received network traffic. An interpreted language (Tcl) provides branching and high-level control structures to direct the interaction with the network. Network Expect was heavily influenced and inspired on the Expect program written by Don Libes, which allows to talk to interactive programs in a scripted fashion. The type of things that Network Expect can do are usually very low level network operations, which usually require writing a custom application in a language like C. Some of the things that Network Expect can do include: * Generate arbitrary network traffic and inject it into a network at layer 2 or layer 3. * A wide range of protocols is supported, including 802.1q, ARP, Cisco VTP and DTP, GRE, IPv4, IPv6, ICMP, UDP, TCP (including options), etc. This Network Expect functionality is very similar to the functionality provided by several packet crafting and forging open source tools like Nemesis, Packit, hping, Scapy, and others. * Listen for network traffic and take decisions based on the type of traffic received. * Open a sniffer trace in PCAP format and replay it after changing some values in the original packet capture. * Emulate network protocols to see how they interact with other speakers of that protocol. For example, emulating a TCP server to investigate approaches to randomization of TCP Initial Sequence Numbers (ISN) can be easily done in Network Expect. -- License: GPLv2 Upstream: http://www.netexpect.org Other comments: Network Expect uses libwireshark from the Wireshark project for packet dissection tasks. I'm working with the wireshark maintainer on the netexpect/wireshark integration since until now there are no other packages (to my knowledge) that use libwireshark from the Wireshark project for packet dissection tasks (package kismet uses libwiretap also from the Wireshark project for read packet capture files, though). Disclaimer: I am the Network Expect upstream maintainer and have a biased interest in seeing my project in Debian. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527848: Your patch for multiple IP support for ddclient
Hi Ingo,
Per http://permalink.gmane.org/gmane.network.dns.ddclient.user/17, it
seems like you are the author of the multiple IP support for ddclient,
so I am writing to you to ask you about a specific line of code in your
patch that apparently is causing problems for me.
My setup used to work before ddclient 3.8.0, with your multiple IP
support patch, was released. Now ddclient won't update the DNS entry
because it thinks that the new IP address (specified via CLI options) is
the same as the cached IP address. Here are some additional details:
I am calling ddclient like this:
ddclient -debug -verbose -daemon=0 -syslog -use=ip -ip=192.168.1.1
When I run this command I get in the output:
SUCCESS: myhost.dyndns.org: skipped: IP address was already set to a.b.c.d
where a.b.c.d is *different* from 192.168.1.1, and is actually what I
have in the cache file for myhost.dyndns.org.
The line from your patch that I can't explain is this one (from
update_nics() ):
+ local $opt{$use} = $config{$h}{$use} if $config{$h}{$use};
For the way I am invoking ddclient, this will change $opt{'ip'} from
192.168.1.1 to a.b.c.d (because $config{'myhost.dyndns.org'}{'ip'} is
a.b.c.d).
The consequence is that from this point on, ddclient will believe that
the new IP address is a.b.c.d instead of what I specified via the
command line (192.168.1.1).
I know it's been a while since you wrote this code, but do you know why
you wrote the above line of code? I personally can't see a reason for
overwriting $opt{$use} with whatever is in the %config hash.
This issue is affected other users, and so far nobody has been able to
figure out why things don't work. Here's the Debian bug report for this
issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527848
And it looks like this guy also ran into the same issue:
http://sourceforge.net/projects/ddclient/forums/forum/399428/topic/3158864
I also tried using -use if and -if my network interface but that
didn't work either. In that case something is overwriting -use if with
the internal equivalent of -use ip, but I haven't investigated this
issue any further.
Any ideas?
Cheers,
Eloy Paris.-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539681: No more crashes with 1.6.1.0~dfsg-1.0.0jones1
Hi Faidon, On 10/28/2009 10:06 PM, Faidon Liambotis wrote: Eloy, hi, Eloy Paris wrote: Just downgraded and tested 1.6.1.0~dfsg-1.0.0jones1 -- I no longer see the crashes that I was experiencing with 1.6.2beta3. Thanks for the much detailed bug report, this is highly appreciated. I'm terribly sorry for not responding sooner. I uploaded 1:1.6.2.0~rc3-1 the other day to unstable. It includes a *lot* of fixes since beta3 and it should be generally stable. Is it too much to ask to try this version and report back if the bug is still present (along with the usual backtrace)? If that's the case I'll make sure it gets reported upstream and fixed properly. I have been running 1:1.6.2.0~rc3-1 for almost a week now and have not experienced a single crash. I think it is safe to say that this bug has been fixed. Cheers, Eloy.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539681: No more crashes with 1.6.1.0~dfsg-1.0.0jones1
Hi Faidon, On 10/28/2009 10:06 PM, Faidon Liambotis wrote: Eloy, hi, Eloy Paris wrote: Just downgraded and tested 1.6.1.0~dfsg-1.0.0jones1 -- I no longer see the crashes that I was experiencing with 1.6.2beta3. Thanks for the much detailed bug report, this is highly appreciated. I'm terribly sorry for not responding sooner. Not a problem; we all are busy. I uploaded 1:1.6.2.0~rc3-1 the other day to unstable. It includes a *lot* of fixes since beta3 and it should be generally stable. Yes, I noticed that you guys had packaged 1.6.2rc3... Is it too much to ask to try this version and report back if the bug is still present (along with the usual backtrace)? If that's the case I'll make sure it gets reported upstream and fixed properly. I was planning to wait until 1.6.2rc3 transitions to testing just to have a little bit of assurance that it won't be as bad as 1.6.2rc1 was for me but sure, I can help with the testing. Worst case scenario is that this crashing bug is not fixed there and I just go back to the 1.6.1.0~dfsg-1.0.0jones1 that I am currently running. I'll upgrade within the next couple of days and report back. Cheers, Eloy.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552025: wireshark-dev: Can't build external application against libwireshark
Package: wireshark-dev
Version: 1.2.2-2
Severity: normal
Tags: patch
Network Expect (http://www.netexpect.org) is an application that uses
libwireshark (provided by wireshark-common) for packet dissection tasks.
To be able to do this, the application uses the libwireshark API and
therefore needs C header files and development libraries shipped with
the wireshark-dev package.
While it was possible to build netexpect against the previous
1.0.x wireshark-dev packages, in Wireshark 1.2.x there was a minor
reorganization and now the following changes are needed to be able to
build successfully:
--- wireshark-1.2.2.orig/debian/wireshark-dev.files 2009-10-22
15:26:13.0 -0400
+++ wireshark-1.2.2/debian/wireshark-dev.files 2009-10-18 02:30:34.91923
-0400
@@ -5,6 +5,8 @@
/usr/lib/wireshark/libwireshark.la
/usr/lib/wireshark/libwiretap.so
/usr/lib/wireshark/libwiretap.la
+/usr/lib/wireshark/libwsutil.so
+/usr/lib/wireshark/libwsutil.la
/usr/lib/python2.4/*
/usr/include/wireshark/*
--- wireshark-1.2.2.orig/debian/wireshark-dev.header-files 2009-10-22
15:26:13.0 -0400
+++ wireshark-1.2.2/debian/wireshark-dev.header-files 2009-10-18
02:29:10.196620797 -0400
@@ -7,3 +7,4 @@
epan/dissectors/*.h
epan/ftypes/*.h
wiretap/*.h
+wsutil/*.h
If you could make these changes in the next upload that'd be great.
Thanks!
Eloy Paris.-
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.31.4 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages wireshark-dev depends on:
ii autoconf 2.64-4 automatic configure script builder
ii automake1.9 1.9.6+nogfdl-3 A tool for generating GNU Standard
ii autotools-dev 20090611.1 Update infrastructure for config.{
ii cdbs 0.4.61+nmu2common build system for Debian pac
ii debhelper 7.4.3 helper programs for debian/rules
ii libglib2.0-dev2.22.2-2 Development files for the GLib lib
ii libpcap0.8-dev1.0.0-4development library and header fil
ii libtool 2.2.6a-4 Generic library support script
ii omniidl4 4.1.2-1+b1 omniORB idl to C++ and Python comp
ii python2.5.4-2An interactive high-level object-o
ii python-support1.0.4 automated rebuilding support for P
ii snacc 1.3bbn-10 ASN.1 to C or C++ or IDL compiler
wireshark-dev recommends no packages.
wireshark-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#539681: More information
A member of the pkg-voip-maintainers team has provided me a link to an archive of 1.6.1.0 packages that I believe are not affected by this bug (thanks Jonas!). I'll be downgrading from 1.6.2beta3 (currently in unstable) to these packages soon and will report back if the problem still persists with stable 1.6.1.0. The links to the 1.6.1.0 packages are: -- Pick one (and only one!) of the below depending on your system: deb http://debian.jones.dk/ lenny asterisk deb http://debian.jones.dk/ sid asterisk Packages are available there for i386 and amd64. -- In the meantime, I obtained coredumps for the crashes and decoded them. Since I've been collecting coredumps I've obtained these coredumps: core.altamira-2009-08-10T22:42:48-0400 core.altamira-2009-08-14T15:00:35-0400 core.altamira-2009-08-14T15:02:24-0400 core.altamira-2009-08-14T15:49:26-0400 core.altamira-2009-08-14T16:14:15-0400 core.altamira-2009-08-14T16:51:22-0400 core.altamira-2009-08-14T20:39:29-0400 core.altamira-2009-08-14T21:32:36-0400 core.altamira-2009-08-14T21:34:14-0400 core.altamira-2009-08-15T20:20:05-0400 core.altamira-2009-08-16T20:56:16-0400 core.altamira-2009-08-17T22:14:26-0400 core.altamira-2009-08-19T19:06:10-0400 core.altamira-2009-08-21T12:03:51-0400 core.altamira-2009-08-21T17:36:15-0400 core.altamira-2009-08-21T20:03:38-0400 core.altamira-2009-08-22T20:27:47-0400 core.altamira-2009-08-25T13:54:13-0400 core.altamira-2009-08-25T21:47:32-0400 core.altamira-2009-08-25T21:48:54-0400 core.altamira-2009-08-27T12:30:40-0400 core.altamira-2009-08-27T13:25:18-0400 core.altamira-2009-08-28T07:45:27-0400 All these crashes are happening in the same place: Core was generated by `/usr/sbin/asterisk -f -p -g -U asterisk -vvvg -c'. Program terminated with signal 11, Segmentation fault. #0 0xb6948093 in reqprep (req=0xb526688c, p=0xb778b748, sipmethod=5, seqno=102, newbranch=1) at chan_sip.c:8752 8752chan_sip.c: No such file or directory. in chan_sip.c (gdb) where #0 0xb6948093 in reqprep (req=0xb526688c, p=0xb778b748, sipmethod=5, seqno=102, newbranch=1) at chan_sip.c:8752 #1 0xb694989a in transmit_reinvite_with_sdp (p=0xb778b748, t38version=0, oldsdp=0) at chan_sip.c:9791 #2 0xb694a471 in sip_set_rtp_peer (chan=0xb778efe8, rtp=0x0, vrtp=0x0, trtp=0x0, codecs=0, nat_active=0) at chan_sip.c:24322 #3 0x080fb704 in bridge_native_loop (c0=0x8a043c0, c1=0xb778efe8, flags=0, fo=0xb5266e98, rc=0xb5266e94, timeoutms=-1) at rtp.c:4056 #4 ast_rtp_bridge (c0=0x8a043c0, c1=0xb778efe8, flags=0, fo=0xb5266e98, rc=0xb5266e94, timeoutms=-1) at rtp.c:4533 #5 0x0809572b in ast_channel_bridge (c0=0xb778efe8, c1=0x8a043c0, config=0xb5267d1c, fo=0xb5266e98, rc=0xb5266e94) at channel.c:4998 #6 0x080bc006 in ast_bridge_call (chan=0xb778efe8, peer=0x8a043c0, config=0xb5267d1c) at features.c:2558 #7 0xb705007c in dial_exec_full (chan=0xb778efe8, data=0xb5269f18, peerflags=0xb5267e90, continue_exec=0x0) at app_dial.c:2184 #8 0xb7052225 in dial_exec (chan=0xb778efe8, data=0xb5269f18) at app_dial.c:2258 #9 0x080f2676 in pbx_exec (c=0xb778efe8, app=0x8a029d0, data=0xb5269f18) at pbx.c:1349 #10 0x080f349b in pbx_extension_helper (c=0xb778efe8, con=0x0, context=0xb778f258 default, exten=0xb778f2a8 s, priority=7, label=0x0, callerid=0xb7703ed8 9193929118, action=E_SPAWN, found=0xb526c348, combined_find_spawn=1) at pbx.c:3691 #11 0x080f4f79 in __ast_pbx_run (c=0xb778efe8, args=0x0) at pbx.c:4234 #12 0x080f61d0 in pbx_thread (data=0xb778efe8) at pbx.c:4521 #13 0x0812c267 in dummy_start (data=0xb77054b8) at utils.c:968 #14 0xb7b084b5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #15 0xb7d3aa5e in clone () from /lib/i686/cmov/libc.so.6 (gdb) A quick Google search for reqprep transmit_reinvite_with_sdp asterisk didn't return anything so I don't know if this is a problem that upstream is aware of, and possibly fixed in beta4. I have been running safe_asterisk so at least the asterisk process restarts after a crash. Running asterisk doesn't not compensate for the dropped calls when the asterisk process crashes, though, but helps a little. Anyway, I am downgrading in the hopes that I won't see the problem with 1.6.1.0. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539681: No more crashes with 1.6.1.0~dfsg-1.0.0jones1
Just downgraded and tested 1.6.1.0~dfsg-1.0.0jones1 -- I no longer see the crashes that I was experiencing with 1.6.2beta3. I was able to reliably reproduce this crash by: - Calling my number from the outside - Logging into the voice mail system - Selecting 3 (advanced options) and 4 (transfer call) - Dialing an outside number In other words, coming in via SIP and then going out via the same SIP channel. Following the above procedure with 1.6.1.0~dfsg-1.0.0jones1 no longer yields a crash. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539681: Possibly running into this bug as well
I seem to be running into this bug as well. I also have 1:1.6.2.0~dfsg~beta3-1 and my Asterisk has become unstable since I installed it because of these chan_sip.so crashes. The crash happens very often. I haven't been able to obtain a coredump but I see in dmesg's output the following: asterisk[26084]: segfault at c ip b690b093 sp b5252b00 error 4 in chan_sip.so[b68d8000+7b000] Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537389: binutils 2.19.51.20090714-1 produces non-bootable kernel
Package: binutils Version: 2.19.51.20090714-1 Severity: grave Justification: renders package unusable Hi Matthias, I have been fighting with this for a few days now, but I think I finally found the culprit... I have a couple of diskless machines and I build custom kernels for them. A couple of days ago I updated my kernel build machine to the latest packages in unstable. The update brought in new gcc and binutils packages. After I used those to build a new kernel for one of the diskless machines the machine would not boot anymore -- after fetching the kernel and the initrd image, the machine would spontaneously reboot right after displaying Uncompressing kernel... done, or would just hang there. It took me a while to figure out the change that introduced the problem but after downgrading one package at a time I finally tracked the problem down to binutils_2.19.51.20090714-1: building my kernel with binutils_2.19.51.20090714-1 results in the problem described above and building my kernel with binutils_2.19.1-1 (currently in testing) results in a bootable kernel. I thought I'd report this right away to prevent this binutils from entering testing. There were no error messages or anything from the kernel; just the spontaneous reboot or hang. No configuration kernel configuration changes either; the only difference in a working test case and a non-working test case was building with different versions of binutils. There's nothing special about the PC that had the problem booting the kernel. It's an old machine that has never had problems with Linux. I'll be out of pocket for a couple of days, in case you need more information and try to reach me. Cheers, Eloy Paris.- -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.30.1 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages binutils depends on: ii libc6 2.9-20GNU C Library: Shared libraries ii zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime binutils recommends no packages. Versions of packages binutils suggests: pn binutils-doc 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#510961: Unofficial nvidia packages at hivernal.org work fine
I have a machine with an old Nvidia video card that requires the nvidia-kernel-legacy-96xx-source package. To be able to move to a recent kernel and to the latest X packages on Debian sid I had to install the unofficial packages tat http://hivernal.org/resources/debian/. Everything works great but I'd love to see official packages. Thanks for the unofficial packages. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489773: freeradius listening on wrong port
Indeed; this is a serious bug. It was originally thought to be a GCC bug but it's been confirmed it's a FreeRADIUS bug. Fixed in 2.0.5, as juha says. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413140: Issue still exists in 0.9.10
Hello, I don't know about the padsp/lastfm problem, but the first error (pulseaudio aborting due to a failed assertion at pulse/xmalloc.c:62) still exists in pulseaudio 0.9.10. Filed ticket 282 with upstream for this: http://pulseaudio.org/ticket/282 Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473798: dvdbackup: segfault when mirroring DVD
Package: dvdbackup Version: 0.2-1 Severity: important dvdbackup segfaults while trying to mirror a DVD. No useful backtrace that I can see, even with dvdbackup-dbg installed. Initial directory (down to VIDEO_TS) gets created before crash. Command run is dvdbackup -M. vobcopy -m is able to copy the same DVD. Previous 0.1.x version used to work just fine. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23.14 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dvdbackup depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libdvdread3 0.9.7-8library for reading DVDs dvdbackup recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473798: dvdbackup: segfault when mirroring DVD
Hello, On Tue, Apr 01, 2008 at 09:42:12PM +0200, Benjamin Drung wrote: What is the output if you use dvdbackup -Mv and dvdbackup -I? -- $ dvdbackup -Mv File sizes for Title set 0 VIDEO_TS.XXX IFO = 30720, MENU_VOB = 382976 At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 1 i.e.VTS_01_X.XXX IFO: 18432, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 2 i.e.VTS_02_X.XXX IFO: 18432, MENU: 937984 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 3 i.e.VTS_03_X.XXX IFO: 16384, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 4 i.e.VTS_04_X.XXX IFO: 18432, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 5 i.e.VTS_05_X.XXX IFO: 18432, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 6 i.e.VTS_06_X.XXX IFO: 18432, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 7 i.e.VTS_07_X.XXX IFO: 18432, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 8 i.e.VTS_08_X.XXX IFO: 18432, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 9 i.e.VTS_09_X.XXX IFO: 20480, MENU: 382976 Bottom of loop At top of loop After opening files After Menu VOB check After Menu Title VOB check File sizes for Title set 10 i.e.VTS_10_X.XXX IFO: 133120, MENU: 237848576 VOB 1 is 7 Bottom of loop At top of loop Segmentation fault $ -- $ dvdbackup -I Segmentation fault $ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473798: dvdbackup: segfault when mirroring DVD
On Tue, Apr 01, 2008 at 10:01:32PM +0100, Stephen Gran wrote: This one time, at band camp, Eloy Paris said: dvdbackup segfaults while trying to mirror a DVD. No useful backtrace that I can see, even with dvdbackup-dbg installed. Initial directory (down to VIDEO_TS) gets created before crash. Command run is dvdbackup -M. vobcopy -m is able to copy the same DVD. Previous 0.1.x version used to work just fine. Can you please send what stack trace you do have? Even a corrupt stack is sometimes useful, if only to show that we're smashing the stack somewhere. Sure. Seems pretty useless, though: -- $ gdb dvdbackup GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu... (gdb) set args -M (gdb) run Starting program: /usr/bin/dvdbackup -M Program received signal SIGSEGV, Segmentation fault. 0x12881000 in ?? () (gdb) where #0 0x12881000 in ?? () (gdb) -- By the way, I mentioned that vobcopy is able to copy this DVD - that is partially correct: it is able to read the DVD until the point that it hits the ARccOS copy protection. Then the kernel gets stuck reading corrupted sectors. However, this happens well into the reading process. With dvdbackup it does not seem to go past an early read of the DVD. Let me know if you want to see anything else. Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473798: dvdbackup: segfault when mirroring DVD
Hi guys, On Tue, Apr 01, 2008 at 11:20:42PM +0100, Stephen Gran wrote: This one time, at band camp, Stephen Gran said: That looks like it's probably an overflow there. I looked at my build log again, and it looks like we didn't pass the necessary large file flags at build time for some reason - building from my svn tree does, but building from the tarball doesn't. I'll take a look and see what I can come up with. Never mind, I think I found it. I'm going to reupload now - can you pull from incoming.debian.org and let me know if it fixes the problem? Yes, that did it. Thanks for looking into it. Any idea why the stack trace was completely useless; was the memory corruption (if there was one) so devastating that it completely killed the stack trace? Thanks! Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473798: dvdbackup: segfault when mirroring DVD
Hello, On Tue, Apr 01, 2008 at 11:56:23PM +0200, Benjamin Drung wrote: The segmentation fault seams to be in DVDGetFileSet, but I cannot see, where the problem is. We need a useful stack trace. I work with Eclipse + CDT with Autotools plugin. So I do not know, how to get a useful stack trace with other tools. Well, if gdb can't give us a stack trace the situation is dire and I don't think there's any tool that can give us a good backtrace ;-) Am Dienstag, den 01.04.2008, 17:23 -0400 schrieb Eloy Paris: By the way, I mentioned that vobcopy is able to copy this DVD - that is partially correct: it is able to read the DVD until the point that it hits the ARccOS copy protection. Then the kernel gets stuck reading corrupted sectors. However, this happens well into the reading process. With dvdbackup it does not seem to go past an early read of the DVD. dvdbackup crashes too early and it should not end with an segmentation fault. Agreed. Which version of dvdbackup did you use before? I was using whatever was in unstable before 0.2 was uploaded. It seems like it was 0.1.1-12, according to the changelog. What is the output of this version if you use dvdbackup -I -v 2 -i /dev/dvd? Stephen already nailed the problem. Let me know if you are still interested in the output from this command (I'd have to downgrade to 0.2-1, though.) Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466729: asterisk: terminate called ...
Hi Ron, On Mon, Mar 17, 2008 at 03:47:41PM +1030, Ron wrote: It looks like you are having a slightly different problem to the original report, but with the same channel driver and its autodetection. A, okay; that makes sense. Before I provide this information you've requested please allow me to share what I've found. If after going through this you still think the information you requested is needed I'll be happy to provide it. I think I have enough clues from this now to guess what has happened... Could you please run /usr/sbin/vpbscan and attach its output. That should confirm my suspicions, and perhaps help with crafting a more complete fix. Here's what I get after running vpbscan: $ sudo /usr/sbin/vpbscan CARD1:OPENPCI:irq=21 sub= bus-dev:04:02 BOARDS:1 I have attached the output from lspci -vvv on the machine with the X100P clone, in case you need that. Now, I have no idea where /etc/vpb came comes from, and I have even less idea how cards was set to 1 in /etc/vpb/vtcore.conf. There are two files in /etc/vpb, vtcore.conf and vpb.conf. Both had a timestamp of 2007-12-07. I certainly didn't mess with these files because I don't have a VPB card. These would have been created by the postinst when libvpb was installed. I suspect it's mistakenly adopted your X100P clone. Hhhmmm, you're right. Somehow I missed yesterday the libvpb postinst script. Sadly a number of telephony cards are in circulation that all use the same PCI interface chip and don't override its PCI id. vpbscan doesn't appear to be accounting for that properly when deciding what cards are present in the system. I just moved it out of the way and asterisk started fine. If you leave the /etc/vpb dir, but remove its contents, then nothing will mess with it again in future. If you remove it entirely though, then a future update of libvpb will probably re-create it again ... You're right; I see in libvpb's postinst script: case $1 in configure) if [ ! -e /etc/vpb ]; then VpbConfigurator || true fi ;; They aren't conffiles because they are generated from the (supposed) hardware detected on the system. In this case it supposed wrong. But we should be able to fix it so you won't have to mess with it in future now that we have an idea about what's still going wrong. Okay, cool. No apologies needed, thanks for the excellent followup triage ! Hey, my pleasure! P.S. If the exit() was happening from within libvpb I think it'd be much better for libvpb to return an error code to the caller. This confused me too, I'd have expected it to trap on an exception and just not load the module... but I see that indeed there is still some code in libvpb that dates back to the days when assert() and exit() were the cool things to do when C code ran amok in 'unrecoverable' ways. This one is much easier to fix than the vpbscan problem. And with this fixed, the mistake of vpbscan will be caught and corrected automatically. Which is what we thought we'd done with the last patch... ;) You win the corner case prize ! Haha. Well, fortunately I was able to find the workaround mentioned in #466729. I use Broadvoice as my VoIP provider with a bring your own device plan, so Asterisk definitely needs to be up or we don't have phone service at home. The machine runs unstable and I don't upgrade it very often, but sometimes I have to do it to avoid falling too far behind. If something doesn't work after an upgrade and I can't fix it quickly then that means downgrading (don't think I've had to ever do that, though.) Your fixed .debs will be on the wire shortly ... Cool. Let me know if you need further information from my system. Glad to be of assistance. Cheers, Eloy.- 00:00.0 Host bridge: Intel Corporation 82925X/XE Memory Controller Hub (rev 04) Subsystem: Dell Unknown device 0176 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 00:01.0 PCI bridge: Intel Corporation 82925X/XE PCI Express Root Port (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: f000-0fff Memory behind bridge: dd00-dfef Prefetchable memory behind bridge: c000-cfff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- Reset- FastB2B- PriDiscTmr-
Bug#466729: asterisk: terminate called ...
Hi Ron, On Mon, Mar 17, 2008 at 05:30:36AM +1030, Ron wrote: We're going to need a bit more information about what is 'unique' about your system, and/or what you are really seeing when this fails if we are to figure out what is going on. Nobody else seems to be able to reproduce this with the current code, and from everything you've told us so far, neither should you. Even without the latest patch... Sorry, I wasn't aware that nobody else had seen this problem; that's why I didn't investigate further, and especially because the workaround noload = chan_vpb.so made things work for me. Could you please forward the output of asterisk -vvv for us to take a look at what you are seeing when it crashes. Also what arch are you running on? Before I provide this information you've requested please allow me to share what I've found. If after going through this you still think the information you requested is needed I'll be happy to provide it. So, after reading your email I looked closer at what is happening. First of all, what I found is that I was not seeing a crash - asterisk was exiting with exit code 1 (my guess would be from libvpb) and the last line in the output of asterisk -vvv was: Couldnt open VTCore device node (/dev/vt0): No such file or directory I then ran asterisk under strace and saw towards the end: open(/etc/vpb/vtcore.conf, O_RDONLY|O_LARGEFILE) = 20 I opened this file and found: -- [general] name = vtcore cards = 1 [card0] type = OpenPCI #country = 1 #fxs_impedance = 4 #fxo_impedance = 2 #logging = 1 #hwplaygain = #hwrecordgain = #playgain = #recordgain = #dtmfms = #cutthrough = #chan = 0 #chan = 1 #chan = 2 #chan = 3 #chan = 4 #chan = 5 #chan = 6 #chan = 7 -- Changing cards = 1 to cards = 0 allowed me to run asterisk without the noload = chan_vpb.so workaround, so I can now confirm that everything works fine now. Now, I have no idea where /etc/vpb came comes from, and I have even less idea how cards was set to 1 in /etc/vpb/vtcore.conf. There are two files in /etc/vpb, vtcore.conf and vpb.conf. Both had a timestamp of 2007-12-07. I certainly didn't mess with these files because I don't have a VPB card. Running dpkg -S /etc/vpb returns dpkg: /etc/vpb not found; no package in my system provides /etc/vpb, and no installation script creates it, nor the files in it. I don't recall installing any of the packages provided by the source package vpb-driver. The only one is libvpb0 which is pulled in by asterisk as a dependency. This system has a Digium Wildcard X100P clone controlled by the Zaptel driver. Any chance some package incorrectly identified this card as a VPB card? Anyway, no package seems to be responsible for /etc/vpb on my system, but libvpb.so seems to be accessing it: # strings /usr/lib/libvpb.so.0.0.0 | grep etc/vpb /etc/vpb/vpb.conf I just moved it out of the way and asterisk started fine. My guess is that it is a leftover from an old package, although I'd love to know which, and more importantly, how cards came to be 1, which is what caused this problem. Thanks for the willigness to help me, and for being involved in maintenance of these important VoIP packages. My apologies for the noise. Cheers, Eloy Paris.- P.S. If the exit() was happening from within libvpb I think it'd be much better for libvpb to return an error code to the caller. Do you know if there are any exit() calls in libvpb? Haven't checked the source code myself, and I feel lazy to do it, but it was confusing to see asterisk exiting like that instead of crashing. I think a crash would have provided more information than a clean exit ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466729: Does not seem to be fixed
Hi Faidon, On Wed, Mar 12, 2008 at 11:43:55AM +0200, Faidon Liambotis wrote: Eloy Paris wrote: I ran into this bug as well and 1:1.4.18~dfsg-1 does not seem to fix the problem, contrary to what this changelog entry says: * Backport upstream's patch for chan_vpb to avoid crashes when no VoiceTronix cards are present. (Closes: #466729) The only way to start asterisk was to apply the workaround that Faidon Liambotis [EMAIL PROTECTED] mentioned: Meanwhile, you can add an explicit noload = chan_vpb.so to your modules.conf, as a temporary workaround. Do you have any VoiceTronix cards in your system? No, I don't have any. What is the value of the cards option in your vpb.conf? [general] ; ; Total number of Voicetronix cards in this machine ; cards=0 Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466729: Does not seem to be fixed
Hello, I ran into this bug as well and 1:1.4.18~dfsg-1 does not seem to fix the problem, contrary to what this changelog entry says: * Backport upstream's patch for chan_vpb to avoid crashes when no VoiceTronix cards are present. (Closes: #466729) The only way to start asterisk was to apply the workaround that Faidon Liambotis [EMAIL PROTECTED] mentioned: Meanwhile, you can add an explicit noload = chan_vpb.so to your modules.conf, as a temporary workaround. Cheers, Eloy Paris.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377011: dhcp3-server: include option to avoid starting the server on install
[Adding Steve Langasek to his discussion since I know he can provide valuable technical advise here.] Hi Toni, Andrew, On Mon, Jan 14, 2008 at 12:41:21AM +0100, Toni Mueller wrote: On Mon, 14.01.2008 at 06:56:40 +1000, Andrew Pollock [EMAIL PROTECTED] wrote: Well I think that goes against the general behaviour of Debian packages that are servers. The general logic seems to be that if you want a server package installed, you want it running. I think you'll find that most servers are started in the postinst. I beg to disagree. Many daemons already have such things in their default scripts. A quick sample on one of my computers show these packages to have something like a start switch in their default script: 4ss, amule, apache2, avahi-daemon, bittorrent, bluetooth, cfengine2, cryptdisks, dbus, distcc, exim4, fetchmail, firehol, libzvbi0, lighttpd, mdadm, nfs-common, oidentd, partimaged, pound, rrdcollect, rsync, setkey, smartmontools, snmpd, uml-utilities. This may be not a complete survey, but it shows that having such a facility is far from being uncommon. I think the correct way to achieve what you're asking for is via a policy script for invoke-rc.d -v, please? I believe the current accepted way to prevent services/daemons/servers from starting at boot time is to manipulate the /etc/rcX.d links. I've seen some packages remove /etc/default/package support recently. I do agree that people may not want to run a server even if they have the server package installed. However, having the init script source /etc/default/package is not the correct way to go. What I personally do to prevent servers from starting at boot time is something along the lines of: # cd /etc/rc2.d # move S20samba K20samba # cd /etc/rc3.d # move S20samba K20samba etc. After doing this any future invocations of invoke-rc.d will not mess with my preferences. The invoke-rc.d policy that Andrew mentioned probably accomplishes the same in a more intelligent way but I have never played with it. You should be able to figure it out by reading invoke-rc.d's man page. My recommendation is that we close this bug since adding logic to the init script to not start based on configuration in /etc/default/package is not the way to go based on what I am seeing. Do we have agreement? Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444338: [Pkg-samba-maint] Bug#444338: Bug#444338: README.Debian.gz has outdated sections
On Tue, Oct 02, 2007 at 10:29:26PM +0200, Christian Perrier wrote: Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Package: samba Version: 3.0.26a-1 Samba's README.Debian.gz has various sections which seem outdated. I suggest they're removed: Thanks again for pointing us to this old piece of documentation..:-) I'd be even more drastic, if noone objects. The entire 1. Notes section is really old and dates back from the Samba 2.2-3.0 transition. I suggest we drop it. Ditto for 2. Upgrading from Samba 2.2 Section 3 can be kept but must be adapted to the current packages list The mention that slbwrapper does not exist anymore can be removed Section 4 about NT domains can be removed. As written in this bug report, the PDC code is certainly no longer experimental..:-) Section 5 can be kept We also need to add mention of recent maintainers: Noèl, Peter and /me Objections to all this ? Not at all; go for it! Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432750: More details
My NFS mounts in /etc/fstab are not getting automatically mounted at boot time either so it looks like this bug is indeed still around. The problem is that, while portmap gets started, statd is not running, so I get: Mon Jul 23 11:46:01 2007: mount.nfs: rpc.statd is not running but is required for remote locking Mon Jul 23 11:46:01 2007:Either use -o nolocks to keep locks local, or start statd. To me it seems like the problem is that asynchronous NFS mounts are being handled by an ifupdown script after the interface is up and there seems to be something missing. The key players are: - rcS.d/S40networking (brings interfaces up) - rcS.d/S43portmap - rcS.d/S44nfs-common - rcS.d/S45mountnfs.sh Now, when an interface is brought up (via S40networking), the script /etc/network/if-up.d/mountnfs is run. This script will start portmap if /etc/fstab has NFS mounts that need to be mounted and if portmap is not running. The script will also run /etc/init.d/nfs-common start if there are NFSv4 mounts in /etc/fstab. However, it seems to me like we also need to start nfs-common (which will bring up statd) in the case of any NFS mounts in /etc/fstab, not just NFSv4. Changing /etc/network/if-up.d/mountnfs to unconditionally call /etc/init.d/nfs-common start fixes the problem. The other, perhaps simpler, solution is to avoid doing asynchronous NFS mounts by adding: ASYNCMOUNTNFS=no to /etc/default/rcS This way, S40networking will not call /etc/network/if-up.d/mountnfs when the interface is brought up, and instead rcS.d/S45mountnfs.sh will do it, but by this time, all the necessary daemons are up and running. This is actually the way I prefer since the boot process is easier to follow because ifupdown does not call behind the scenes a script that does the NFS mounts. I do think there's a bug in /etc/network/if-up.d/mountnfs because nfs-common is not getting started before attempting to mount the NFS shares. I think that's the root cause of this problem. Setting ASYNCMOUNTNFS to no is just a workaround. Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432727: offlineimap: local variable 'af' referenced before assignment
Package: offlineimap Version: 5.99.0 Severity: important Tags: patch offlineimap 5.99.0 fails to start with the following traceback: $ offlineimap Thread 'Account sync turbo' terminated with exception: Traceback (most recent call last): File /var/lib/python-support/python2.4/offlineimap/threadutil.py, line 153, in run Thread.run(self) File threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File /var/lib/python-support/python2.4/offlineimap/accounts.py, line 118, in syncrunner self.sync() File /var/lib/python-support/python2.4/offlineimap/accounts.py, line 133, in sync remoterepos.syncfoldersto(localrepos) File /var/lib/python-support/python2.4/offlineimap/repository/Base.py, line 130, in syncfoldersto srcfolders = src.getfolders() File /var/lib/python-support/python2.4/offlineimap/repository/IMAP.py, line 170, in getfolders imapobj = self.imapserver.acquireconnection() File /var/lib/python-support/python2.4/offlineimap/imapserver.py, line 183, in acquireconnection imapobj = UsefulIMAP4(self.hostname, self.port) File imaplib.py, line 160, in __init__ self.open(host, port) File /var/lib/python-support/python2.4/offlineimap/imapserver.py, line 52, in open imaplibutil.new_open(self, host, port) File /var/lib/python-support/python2.4/offlineimap/imaplibutil.py, line 116, in new_open self.sock = socket.socket(af, socktype, proto) UnboundLocalError: local variable 'af' referenced before assignment Trivial one-liner: --- imaplibutil.py~ 2007-07-04 09:01:00.0 -0400 +++ imaplibutil.py 2007-07-11 11:49:57.0 -0400 @@ -113,7 +113,6 @@ self.port = port res = socket.getaddrinfo(host, port, socket.AF_UNSPEC, socket.SOCK_STREAM) -self.sock = socket.socket(af, socktype, proto) # Try each address returned by getaddrinfo in turn until we # manage to connect to one. Cheers, Eloy.- -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (700, 'unstable'), (600, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages offlineimap depends on: ii python2.4.4-6An interactive high-level object-o ii python-support0.6.4 automated rebuilding support for p offlineimap recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312391: #312391: FTBFS on hurd-i386: Not ported yet [patch]
Hi Michael, On Fri, Jun 15, 2007 at 03:39:52PM +0200, Michael Banck wrote: I'm probably going to NMU dhcp to add hurd-i386 support over debconf, unless the maintainers decide to upload a patch themselves. Thanks for the heads up and please go for it. Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425333: [Pkg-samba-maint] Bug#425333: Assumes /tmp is mounted exec
On Sun, May 20, 2007 at 09:16:29PM -0700, Elliott Mitchell wrote: From: Steve Langasek [EMAIL PROTECTED] On Sun, May 20, 2007 at 04:41:19PM -0700, Elliott Mitchell wrote: Package: samba-common Version: 3.0.24-6etch1 Subject tells the story. Please post the error message you're getting. Samba does not exec anything directly out of /tmp to my knowledge, so chances are you're hitting a problem with something like debconf. Emphasis on install in the original message. Attempts to install the samba-common package while /tmp is mounted noexec fail. Given that remounting /tmp with exec allows the package to be successfully installed is pretty solid evidence that during installation some script is being directly executed out of /tmp. Steve is not saying that you're imagining things. What he's saying is that it is possible that the script that is being directly executed out of /tmp is being executed by some subsystem that Samba depends on, in which case it wouldn't be a bug in the Samba package. Are you getting an error message that you can share with us? Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#147557: xserver-xfree86: [nv] NVidia's binary driver corrupts the hardware cursor on GeForce2 MX DDR rev 178
Hi Brice, On Tue, May 08, 2007 at 09:39:29PM +0200, Brice Goglin wrote: About 5 years ago, you reported (or replied to) a bug in the Debian BTS regarding the hardware cursor being corrupted when running the nv driver after having run the nvidia binary driver. Did any of you guys reproduce this problem recently? With Xorg/Etch? If not, I will close this bug in the next weeks. I think it's a good idea to close it. It's so old that it's likely fixed, and if not, a new bug with fresh information can be re-opened. Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408981: [Pkg-samba-maint] Bug#408981: samba: smbd 3.0.23a and later does parse multiple backends in passdb backend
On Mon, Mar 12, 2007 at 02:57:43AM -0700, Steve Langasek wrote: [...] Ok, let's give this a try, and see if the release team will put up with us... Attached is an updated .pot for consideration. I'm in the process of testing before committing this change, but here is the proposed template: Template: samba-common/unsupported-passdb Type: error _Description: Chaining passdb backends is not supported Beginning with version 3.0.23, samba no longer supports chaining multiple backends in the passdb backend parameter. It appears that your smb.conf file contains a passdb backend parameter consisting of a list of backends. The new version of samba will not work until you correct this. Does this look reasonable to you? Looks very reasonable to me. Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368251: [Pkg-samba-maint] Bug#368251: winbind NSS, omitted groups
On Wed, Feb 28, 2007 at 11:57:22PM -0800, Steve Langasek wrote: On Thu, Mar 01, 2007 at 08:47:13AM +0100, Christian Perrier wrote: Do we understand why these are no longer the built-in defaults upstream? If I were to guess I think maybe for performance reasons at large sites. Seems to me that this is what I heard once in Jerry Carter's mouth, yes. That sounds like a good reason to me, and doesn't seem like something we should override in the Debian package? Perhaps add the options commented out and with a warning that large sites may get a performance hit? Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410308: [Pkg-samba-maint] Bug#410308: samba: Samba listing system files under backup share
On Wed, Feb 14, 2007 at 07:32:45AM +0100, Christian Perrier wrote: Interesting spot. FWIW, we do provide a fedault [homes] share so that will probably happen with the defautl setup of the package. What about adding backup to invalid users in smb.conf fix this problem? For backup, yes, but I think this doesn't scale well. The problem could happen for any other system user with a valid home directory. This is why I committed a change adding valid users = %S to the [homes] share. Makes sense. Cool fix. Thanks! Cheers, Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327828: Workaround possible?
Hi Mike, You wrote: Okay, I finally got what you meant... and can see the problem... strangely, the file needed for the icon to correctly show up is not provided by a make install anymore... It might be related to all the branding stuff they are putting. I'll check what goes on exactly. Is it possible to workaround this problem by manually putting this missing file (taken from a previous release) in the correct location, or it's not possible because this mising file is built into the Firefox executable? Thanks! Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327828: No icon here either
Hi guys, Firefox 1.5beta1 does not display a program icon here either. I use Gnome 2.10 and the window manager is Metacity (from unstable.) The icon would be displayed in the Gnome panel's Window List applet, but right now it just shows a generic application icon. I agree with Tom Parker that this very confusing since one can't quickly locate the web browser among all the icons in the window list :-( Thanks for packaging 1.5beta1 so quickly, though. Really appreciated. Cheers! Eloy.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
