Bug#509566: Puppet: setting timeout to 0 causes puppet to try requesting a certificate infinitely often
found 509566 0.24.5-3 found 509566 0.24.6-1 thanks Hi, Setting waitforcert to 5 helps a bit, but it is still a problem IMO. Actually, I think the bug lies in the code, and not in the configuration. The manpage mentions You can turn off waiting for certificates by specifying a time of 0. and I think that your original intention was that, which seems quite reasonable. The code, however, suggests[1] that 0 means try without waiting at all. If you go down the way of having a timeout in the first place instead of fixing the code, then I think that the upstream-provided, default-if-omitted of 120 seconds is much more sane. And I can't see a reason for diverging from that in Debian. Thanks, Faidon 1: /usr/lib/ruby/1.8/puppet/executables/client/certhandler.rb:52 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505310: bristuff/app-meetme-avoid-overflows screws up conferences
Bjoern Boschman wrote: I'll attach what I think is relevant. If that's not enough don't hesitate to ask for more input. Thanks a lot! I tried with audiobuffer=10 and still couldn't reproduce it. Could you tell us a bit more about the test scenario? You mentioned a problem when a second participant enters. What technologies are the two channels? SIP? Zap? TBH, I'm inclined to just remove that particular patch because the existence of a rare problem outweights the questionable benefits that it has... Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505310: bristuff/app-meetme-avoid-overflows screws up conferences
Björn Boschman wrote: While trying to setup a conference call using app_meetme it terminates the conference user when a second caller enters with the following errormessage: [Nov 11 16:56:26] WARNING[22074]: app_meetme.c:1624 conf_run: Unable to set buffering information: Invalid argument When I disable bristuff/app-meetme-avoid-overflows before compile it's working fine. Well, I'm not sure if that patch is needed anymore and I'd be more than happy to disable it. Before I do that, however, I'd like to reproduce your bug, which I wasn't able to. Could you send us the relevant portion of extensions.conf and meetme.conf? Thanks, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510476: ITP: LinuxCallRouter - an ISDN based PBX for Linux
Joerg Dorchain wrote: Package: lcr LinuxCallRouter - an ISDN based PBX for Linux Version: 1.3 (20081124) Upstream Author: Andreas Eversberg jo...@eversberg.eu URL: http://isdn.eversberg.eu/download/lcr-1.3/ Licence: GPL Description: Formerly known as PBX4Linux, Linux-Call-Router is not only a router, it is a real ISDN PBX which interconnects ISDN telephones and ISDN lines. It is possible to connect telephones to a Linux box. It is a pure software solution except for the ISDN cards and telephones. The great benefit is the NT-mode that allows to connect telephones to an ISDN card. Special cards are needed and a little bit of different cabeling. It supports lots of features, that only expensive PBXs have. It include a channel driver that can link LCR to Asterisk PBX. Now that the underlying misdn driver has made it into the mainstream kernel and asterisk has a debian package for some time, this package fills the gap of combining both into a very scalable PBX. You're welcome to join pkg-voip-maintainers and coordinate with us about this :) Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507883: release critical
Simon, hi, Simon McVittie wrote: When do you expect to be able to upload your patch for Asterisk segfaults on startup? (If a full upload is tricky from where you are, feel free to send your patch to this bug and we could take it from there?) The bugfix is already commited to the team's SVN since the day I marked the bug as pending. It's just that an issue came up[1] with one of asterisk's dependencies (libvpb) and I delayed the upload until it got resolved. It did 2 days ago, so I'll be uploading soon. Thanks, Faidon 1: 4954209b.7000...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510408: ITP: biew -- console hex viewer/editor with disassembler
Michel Loos wrote: Package: wnpp Severity: wishlist Owner: Michel Loos l...@mloos.eti.br * Package name: biew Version : 5.7.1 Upstream Author : Nick Kurshev nickol...@users.sourceforge.net * URL : http://sourceforge.net/projects/biew/ * License : GPL Programming Lang: C Description : console hex viewer/editor with disassembler biew was already part of the archive in the past and it was, in fact, released with etch. See #460636 for the bug that requested its removal. That isn't to say that you shouldn't package it; I just think that you should be aware of it. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507883: release critical
tags 507883 = confirmed pending
thanks
Quentin Smith wrote:
I'm unable to reproduce this bug with an extensions.ael containing:
context blah {
lars = NoOp(Test);
123456 = goto foo|1;
};
Asterisk reliably starts with no errors. This is on a lenny 2.6.26-1-amd64
machine (a VM running inside Xen with a single processor)
I, OTOH, was (thankfully!) able to reproduce this.
It's not happening all the time, it occurs once every three or four
executions.
I've prepared a fix, tested it and will upload RSN.
Thanks,
Faidon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507189: asterisk: Depends on libc-client2007b which is not in unstable
Adeodato Simó wrote: So, as for what to do, please do stop for squeeze bumping the SONAME (and changing the package name) on every new upstream version, and only do it whenever the ABI changes. It would be realy nice if you could do this. (There is also no reason to rename the -dev package, though since you provide a virtual package, it's not so grave.) FWIW, depending on the virtual package libc-client-dev is not an option for asterisk since: a) libc-client-dev was a real package in etch, b) the version in etch is not sufficient for asterisk to build (too old) c) dpkg doesn't support versioned b-d on virtual packages d) apt prefers real packages over virtual ones and hence asterisk will FTBFS on systems that have etch in their sources.list. All of these would be solved if the -dev package would be renamed to libc-client-dev again, as it was in etch. The API doesn't change over versions, AFAIK. See #458877 for more. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506764: siproxd: Problem with DNS resolution when in chroot jail
Frédéric BOITEUX wrote: Err, you're probably missing a proper /etc/hosts... Yes, the chroot jail, as built and used by the package, does no contain anything about a siproxd's data file... But no indication nowhere about what to do then... And for a /etc/hosts solution, you have to know by advance all domains used by siproxd clients, it isn't an easy solution... By proper, I meant an /etc/hosts that contains an entry 127.0.0.01 localhost.localdomain localhost I have no knowledge about the bug itself but from what I saw, that seems to be the problem. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506764: siproxd: Problem with DNS resolution when in chroot jail
Frédéric Boiteux wrote: I've backported the latest siproxd (from experimental) on a Debian Etch. It didn't work at first, and activating debug traces, I've found that when using this proxy in a chroot jail (default configuration), the DNS resolution isn't working : siproxd[10444]: utils.c:193 gethostbyname(ekiga.net) failed: h_errno=1 [Unknown host] I've found a similar report on the web : http://osdir.com/ml/network.siproxd/2005-10/msg4.html and I've implemented the trivial solution suggested, as the resolution of 'localhost' don't seem sufficient (see attached patch), and it works fine now. Err, you're probably missing a proper /etc/hosts... Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506453: asterisk init script status action
Dustin Kirkland wrote: This trivial patch uses the lsb-base standard way of gathering and reporting status in the init script. Thanks, I wasn't aware of this! This patch comes from Ubuntu, which is carrying the diff. I'd like to avoid having a fork of the package in Ubuntu. Could you forward us any patches that you have locally and inform us of any future changes you'd like to see beforehand to avoid having Ubuntu-specific changes? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505310: bristuff/app-meetme-avoid-overflows screws up conferences
Björn Boschman wrote: Package: asterisk While trying to setup a conference call using app_meetme it terminates the conference user when a second caller enters with the following errormessage: [Nov 11 16:56:26] WARNING[22074]: app_meetme.c:1624 conf_run: Unable to set buffering information: Invalid argument When I disable bristuff/app-meetme-avoid-overflows before compile it's working fine. Please use reportbug to report bugs, it includes valuable information for us. The most significant of it being the version number of the package on which you encountered the bug. Could you tell us which it is? Thanks in advance, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494445: oops when loading nf_conntrack_ipv6
Vitaliy, hi, On Tue, Aug 12, 2008 at 02:55:56PM +0400, Vitaliy Gusev wrote: On 11 August 2008 19:39:35 maximilian attems wrote: hello, could you please take a look at: * oops on load of nf_conntrack_ipv6 http://bugs.debian.org/494445 IPv6 conntrack doesn't work yet. It will be finished in this week. I'm experiencing the oops on our latest kernel (2.6.26-7, seems to include openvz stuff up to 24cebf40). Do you have a fix for this? I'm only asking because you said you were fixing this back then. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484360: Bug#501207: destar: Fails to run with python2.5
John Wright wrote: Yes, lenny will have both python2.4 and python2.5. One workaround, at least for the compiler.ast.From problem, would be to run destar with #!/usr/bin/python2.4 instead of #!/usr/bin/python. But I think it better to fix the bug rather than try to work around it, if possible. Definitely, my concern was for the backwards compatibility. Are your fixes backwards compatible? It'd suck to fix this only to have a bug report the day after fails to run with python2.4 :) I made sure the fix for #501207 was backwards-compatible. As for the SyntaxError problem, I'm surprised it ever worked at all. Function definitions with optional arguments before required positional arguments aren't legal in 2.4 either (I'm not sure when/if they ever were). Maybe quixote used to generate different actual Python code than it does now in this case? Anyway, I'm pretty certain the patch for the SyntaxError will work with python2.4, but I'll check tomorrow. Great, thanks a lot! Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494445: oops when loading nf_conntrack_ipv6
Vitaliy Gusev wrote: The linux-image-2.6.26-1-openvz doesn't have this fix. Latest 2.6.26-ovz has fix. For 2.6.27-ovz fix patches was sent To Pavel for review. Could you pinpoint the patch for 2.6.26 exactly, e.g. by a commit or by attaching it? If it's simple enough, perhaps the Debian kernel maintainers could add it to Debian's tree. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501207: destar: Fails to run with python2.5
John, hi, John Wright wrote: The above problem is actually the same as bug 501207. However, with that patch applied, I get the following problem starting destar: snip The attached patch fixes the SyntaxError. Thanks a lot for these patches! I have absolutely no clue about python and I don't think anyone in the team does -- which effectively means that we need all the help we can get. So, bear with me if this is a silly question: I was under the impression that lenny will be shipped with both python 2.4 and 2.5 and that these should be co-installable. Are your fixes backwards compatible? It'd suck to fix this only to have a bug report the day after fails to run with python2.4 :) Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493055: BRIStuff patches introduce deadlock
Hi, Faidon Liambotis wrote: Kevin Shanahan wrote: Well it looked promising, but no - the lockup still appears to be reproducable. The patch I used to test is attached. Let me know if I made any mistake in backporting it (it should apply cleanly as the last patch in the debian/patches/series file). Yes, you made a mistake in backporting it :) The right backported patch is this: http://svn.debian.org/viewsvn/pkg-voip/asterisk/trunk/debian/patches/zap-fix-deadlock?rev=6221view=auto The problem is where thw lock is getting held; I'm not sure if we should hold the lock there as well but it's definitely not what the original patch did. Did you have any luck with this? I'll make an upload tomorrow or the day after that, so I'd appreciate it you could answer me until then. We can always make an upload later, but it'd be nice to know if the bug will exist in lenny (hopefully not!) Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500645: Acknowledgement (linux-image-2.6.26-1-openvz-686: OpenVZ checkpointing does not work)
forwarded 500645 http://bugzilla.openvz.org/show_bug.cgi?id=1034 thanks Hi, Upstream contacted me; apparently the bug was (automatically?) forwarded to their bugzilla as #1034. They think that the bug was fixed in commit d588f384. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500645: linux-image-2.6.26-1-openvz-686: OpenVZ checkpointing does not work
Package: linux-image-2.6.26-1-openvz-686 Version: 2.6.26-6 Severity: normal 2.6.26-6 supposedly added OpenVZ checkpointing support -- and indeed the kernel option was enabled and /proc/cpt exists. I was unable, however, to perform an online migration or even a checkpoint/restore cycle on both 686 and amd64 kernels on different machines: hn:~# vzctl chkpnt 201 Setting up checkpoint... suspend... dump... kill... VE is unmounted Checkpointing completed succesfully hn:~# vzctl restore 201 Restoring VE ... Starting VE ... VE is mounted undump... Adding IP address(es): removed Setting CPU units: 1000 Configure meminfo: 49152 Error: undump failed: Address already in use Restoring failed: Error: open_listening_socket: bind: -98 Error: rst_sockets: open_listening_socket: -98 Error: rst_sockets: -98 VE start failed Stopping VE ... VE was stopped VE is unmounted hn:~# dmesg |tail -5 [ 1013.441803] CT: 201: started [ 1014.711018] CPT ERR: cdeae800,201 :open_listening_socket: bind: -98 [ 1014.712378] CPT ERR: cdeae800,201 :rst_sockets: open_listening_socket: -98 [ 1014.713732] CPT ERR: cdeae800,201 :rst_sockets: -98 [ 1014.725277] CT: 201: stopped The problem seems to be with bind(), obviously. I tried checkpointing a container that had all network services shutdown and it worked. I also tried veth instead of venet with no luck. I've searched the Internet and upstream's bugzilla with no relevant results. I can provide you with access on a kvm guest that has this problem in case you want to debug it further. Note that I reproduced this on real machines as well, so this has nothing to do with kvm. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493055: BRIStuff patches introduce deadlock
Kevin, hi, Kevin Shanahan wrote: Well it looked promising, but no - the lockup still appears to be reproducable. The patch I used to test is attached. Let me know if I made any mistake in backporting it (it should apply cleanly as the last patch in the debian/patches/series file). Yes, you made a mistake in backporting it :) The right backported patch is this: http://svn.debian.org/viewsvn/pkg-voip/asterisk/trunk/debian/patches/zap-fix-deadlock?rev=6221view=auto The problem is where thw lock is getting held; I'm not sure if we should hold the lock there as well but it's definitely not what the original patch did. Thanks a lot, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493055: BRIStuff patches introduce deadlock
Kevin, hi, Kevin Shanahan wrote: I had some problems with my Asterisk installation having the PRI channels lock up completely when certain types of calls were received. Eventually this was traced back to a deadlock caused by the bristuff patches being applied. Various information, logs and a stack trace of the lockup here: http://bugs.digium.com/view.php?id=13192 I'm choosing severity grave because this effectively will allow someone calling in with particlar caller ID options/flags to lock up your PRI span on demand (i.e. DoS). You seem to have a good overview of this particular bug. Do you think that the patch that Tzafrir mentioned[1] would fix it? If not, do you have a proposal for a fix? Thanks, Faidon 1: http://repo.or.cz/w/asterisk-bristuff.git?a=commit;h=6e44531a8a112e36588b5dbced309b0521d6b64e -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491672: [RFC] How should rsyslog handle .0 logfiles from sysklogd
Michael Biebl wrote: 2.) Try to log rotate the .0 files for the default Debian log files in postinst. I feel a bit uneasy about this approach, for several reasons: - It adds fairly reasonable complexity to the maintainer scripts, if you want to consider all corner cases. E.g. if you switch from syslog-ng to rsyslog, it is very likely that you have old .0 files lying around (from a sysklogd-syslog-ng switch), so syslog.1 would be older than syslog.2 which would be very confusing. Well, you could rely on ctime for this, even though this would make postinst even more complex; any other reasons? 3.) Delete the .0 files in postinst. Is this covered by the policy? I think that deleting logfiles without warning is totally unacceptable. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438815: Segfault when dlclose()ing libopenh323
severity 438815 important thanks [release team: the bug is about a segfault of users of libopenh323 that happens when they dlclose() the library; see #48 for more.] Since upstream is quite unresponsive generally and in this case they haven't even looked at the bug, it has been workarounded by the only package affected by this, asterisk. Even though a) I believe this is a serious issue, b) it affects other packages, c) the workaround is ugly, it is my opinion as the bug reporter and maintainer of both packages that this isn't a release blocker and doesn't deserve to be marked as grave anymore. I'm Ccing the release team for their opinion since Marc was grumpy about the relationship of severity and workarounds recently. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498399: asterisk: random segfaults
Lionel Elie Mamane wrote: On Tue, Sep 09, 2008 at 09:04:43PM +0200, Lionel Elie Mamane wrote: Asterisk seemingly randomly dies (...) Today, I caught it dying while stracing it. Another crash and this time I had a console open: I'm afraid straces and console won't help much. Have a look at /etc/default/asterisk and try to get a corefile. After that, it should be easy to provide a backtrace with gdb (ping me if you're wondering how). _That_ would really help :-) Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477505: libcommoncpp2: diff for NMU version 1.6.1-1.1
Martin Zobel-Helas wrote: find attached the diff for my libcommoncpp2 1.6.1-1.1 NMU, which i will upload to delay-7. Already tried it and it failed to build from source due to some patch conflicts; didn't spend much time on it though. Feel free to upload this as a 0-day NMU, no need to delay it further. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494928: ITP: sflphone -- SIP and IAX2 compatible VoIP phone
Francois Marier wrote: SFLphone is a SIP/IAX2 compatible softphone for Linux. The SFLphone project's goal is to create a robust enterprise-class desktop phone. While it can serve home users very well, it is designed with a hundred-calls-a-day receptionist in mind. It features a flexible client/server architecture where the GTK client talks to the daemon through DBus and is capable of handling multiple VoIP connections at once. You're welcome to join the VoIP team[1] to maintain SFLphone and/or the other packages that the team maintains. You can contact us either via mail or IRC (#debian-voip on OFTC). Thanks, Faidon 1: http://alioth.debian.org/projects/pkg-voip/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489136: rtpproxy: installation fails
Marcus, hi, Marcus Better wrote: Starting rtpproxy: rtpproxy: running this program as superuser in a remote control mode is strongly not recommended, as it poses serious security threat to your system. Use -u option to run as an unprivileged user or -F is you want to run as a superuser anyway. invoke-rc.d: initscript rtpproxy, action start failed. svn already contains the changes to run as user rtpproxy, however before we can upload this requires a little change: make the control socket group- writable by rtpproxy, perhaps using the setgid attribute on the /var/run/rtpproxy directory, or playing with umask (?). I'm pretty busy so cannot work on it at the moment. Wasn't that fixed in r5916? If so, shouldn't the current version be uploaded to Debian? Remember, this is an RC bug! Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492623: [Pkg-fonts-devel] Bug#492623: ttf-liberation: Trademark prevents modifications
Ian Jackson wrote: Quoting the license: ... If you modify the files, you must - Rename the fonts to remove any reference to Liberation - Not install the fonts as liberation - Rename the binary package and the source package - Change the description to remove all references to Liberation and Red Hat. And much more importantly, a similar clause (albeit only for the reserved font name) is present in the Open Font License, under which most of the free fonts are and which is accepted in Debian main. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399970: Asterisk and chan_misdn
Victor Seva wrote: PD: Simon, can you take a look over those changes and comment them? Maybe a working 1.1.8 version on experimental will be nice. Considering that a) a version of mISDN was merged to upstream Linux, b) we are on a freeze expecting a new release, I'd say that the best strategy right now seems to be to... just wait. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492620: please build asterisk with libcap2-dev instead of libcap-dev
Torsten Werner wrote: I recommend building with libcap2-dev because libcap1 is no longer maintained upstream. The patch is rather trivial. Are the two libraries 100% API compatible? Why there two version in the archive? Why is there a libcap2-dev package and an update to libcap with v2 wasn't sufficient? Any known issues we should be aware of, especially considering that we are under a freeze and intrusive changes are not allowed into lenny? In any case, it seems to me that you should had coordinated better with the other maintainer and the release team to get rid of libcap1 for lenny (bug-filing etc.) -- hope you'll do so for lenny+1. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429734: Please merge the wpasupplicant and hostapd source packages
Daniel Gimpelevich wrote: Please merge the wpasupplicant and hostapd source packages. They are built from the same sources anyway, and using the hostapd source from the wpasupplicant package should also fix Debian bug #429734 for 2.6.26 or later kernels. I have merged them in my Ubuntu Personal Package Archive, so you may retrieve the merged source package via: No they're not, where did you see that? AFAIK, upstream still provides different tarballs with different version numbers (although they usually are synced). I know that Jouni's intention is to merge them at /some/ point but I don't think this has been done yet. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493055: BRIStuff patches introduce deadlock
severity 493055 important thanks Kevin Shanahan wrote: I had some problems with my Asterisk installation having the PRI channels lock up completely when certain types of calls were received. Eventually this was traced back to a deadlock caused by the bristuff patches being applied. Various information, logs and a stack trace of the lockup here: http://bugs.digium.com/view.php?id=13192 I'm choosing severity grave because this effectively will allow someone calling in with particlar caller ID options/flags to lock up your PRI span on demand (i.e. DoS). Well, this is definitely a very nasty bug but from a release prespective I'd like to point out two things: a) You are one of the _very_ few people to experience this deadlock; I've experienced it once or twice in one of my (many!) installations all this time and noone else has reported it so far. Perhaps it has something to do with what the network sends to Asterisk, I'm not so sure myself. b) Asterisk is a very complicated program with dozens of threads and locks between them. I don't think we (as in, Debian) can solve this and I highly doubt that upstream will, at least in time for lenny. In summary, while I acknowledge that this breaks your setup -and believe me, I'd like to have this fixed as much as you do- I don't think it's a release critical bug and that it should prevent Asterisk from being shipped with our next stable release. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492867: libpri - new upstream version
Kevin Shanahan wrote: New version 1.4.6 has been released upstream. Currently trying to debug some nasty ISDN PRI issues with Asterisk, so it would be useful to have this package at the latest version to ensure we have the latest fixes. We are aware of it. Unfortunately, a) we are on a freeze, b) it adds BRI support which may break (or at least change stuff) with the bristuff patch. This will have to wait for post-lenny. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492329: asterisk: Move chan_vpb.so dependencies to 'Suggests'
Tim Retout wrote: Not everyone uses VoiceTronix hardware; I have been told that the vpb channel is still unstable, and would prefer not to install libvpb. The attached patch sets some dh_shlibdeps options, to move the dependencies of this one channel into 'Suggests'. Splitting it out into a separate package seemed like overkill (c.f. #459244). It would be possible to bring it back into 'Depends' or 'Recommends' when the module is stable. The same method could be used to move more non-core asterisk dependencies into 'Recommends'. These would still be installed by default, but could be removed by the administrator. There is no way we're going to do that; I believe it is the wrong way and my gut tells me that it may also be a policy violation, but I haven't checked. Splitting chan_vpb to a different package is something we can discuss though. We've done this before for chan_h323, it's only fair to consider it for chan_vpb. Besides the obvious bloat of having libvpb installed, do you have any other issues with it? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482997: asterisk: Extremely choppy sound and high CPU usage
Ketil Vestby wrote: Thursday 26 June 2008, Moritz Muehlenhoff wrote: .. What's the status? Shall we push the fix in the upcoming r4 release? The status: The patch did not do its job, instead it did open up for a rather huge set of instability problems in addition to the original problem. I have really been unsure about where to repost these problems, so my report did only focus on the original problem. It's became apparent that this would need a *lot* of build/test cycles and _proper_ testing before we even consider pushing it to either r4 or security-master. I must say that having such both a performance regression _and_ a vulnerability in stable doesn't make me very happy; unfortunately, there isn't much I can do at this point; I'm severely lacking free time at this point of the year (semester exam period) and noone else from the team seems interested to push this forward. I expect to gradually resume my Debian activities starting from 8/7. I'll attempt to properly fix this unless someone else steps up until then. Thanks and sorry, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485071: Please provide support for including EPS with XeLaTeX
Norbert Preining wrote: On So, 08 Jun 2008, Faidon Liambotis wrote: +%% 2007/10/25 [JK] Version v0.93 added EPS support from dvipdfmx.def +%% (for use with xdvipdfmx, default driver in xetex 0.997) Yes, but texlive ships 0.996-patch2. Are you/we sure that this works? Did you try it? Yes, it's working fine for me for quite some time. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468797: dynamips: dpkg-buildpackage -b fails on amd64
Erik, hi, Any reason why this fix is not present (i.e. uncommented) in Debian? This is an RC-bug, preventing dynamips from being included in testing. I intend to do an NMU if you don't act on this bug soon. Thanks, Faidon PS. If you ACK this NMU, would you ACK a move from non-free to contrib which seems more appropriate? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485071: Please provide support for including EPS with XeLaTeX
Package: texlive-latex-base
Version: 2007-14
Severity: normal
Tags: fixed-upstream patch
Hi,
Currently it is not possible to include EPS graphics with
\includegraphics. Upstream has a very simple fix in their SVN[1] that
modifies xetex.def to fix that.
The patch is:
--- trunk/Master/texmf-dist/tex/xelatex/graphics/xetex.def 2006/09/15
15:31:59 2132
+++ trunk/Master/texmf-dist/tex/xelatex/graphics/xetex.def 2007/11/26
17:13:01 5603
@@ -13,6 +13,9 @@
%%%
%% Version History
%%
+%% 2007/10/25 [JK] Version v0.93 added EPS support from dvipdfmx.def
+%% (for use with xdvipdfmx, default driver in xetex 0.997)
+%%
%% 2006/08/10 [JK] Version v0.92 correct type-check in [EMAIL
PROTECTED]@QTm;
%% remove [EMAIL PROTECTED]@ext, apply \lowercase instead;
%% make \XeTeXquote have catcode 12 rather than 11;
@@ -417,8 +420,32 @@
% ... though this default rule will try QuickTime anyway ...
[EMAIL PROTECTED]@[EMAIL PROTECTED]
-% ... and add it's extension here
[EMAIL PROTECTED],.png,.jpg,.bmp,.pict,.tif,.psd,.mac,.sga,.tga,.gif}
+% ... and add its extension here
[EMAIL PROTECTED],.eps,.ps,%
+.png,.jpg,.bmp,.pict,.tif,.psd,.mac,.sga,.tga,.gif}
+
+% xdvipdfmx is now the default driver, and can support EPS images,
+% so we borrow code for this from dvipdfmx.def (and add the extensions above)
[EMAIL PROTECTED]
+ \message{#1}%
+ \bgroup
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]@[EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]@ii
+ [EMAIL PROTECTED]@[EMAIL PROTECTED]
+ [EMAIL PROTECTED]@ii
+\special{PSfile=#1\space
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]@tempa\else [EMAIL PROTECTED]
+ [EMAIL PROTECTED]@tempa\else [EMAIL PROTECTED]
+ [EMAIL PROTECTED] clip\fi}%
+ \egroup}
[EMAIL PROTECTED]@[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]
%
% Rotation Scaling
Please backport this patch to the version in Debian; it seems quite
safe, it has existed in upstream's SVN since October 2007 and surely is a
nice feature to have.
Thanks,
Faidon
1:
https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/tex/xelatex/graphics/xetex.def?r1=2132r2=5603
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484796: asterisk-oh322: CVE-2008-2543 denial of service
reassign 484796 asterisk-ooh323c close 484796 1.4.7-1 thanks Nico Golde wrote: Package: asterisk-oh323 Severity: grave Tags: security CVE-2008-2543[0]: | The ooh323 channel driver in Asterisk Addons 1.2.x before 1.2.9 and | Asterisk-Addons 1.4.x before 1.4.7 creates a remotely accessible TCP | port that is intended solely for localhost communication, and | interprets some TCP application-data fields as addresses of memory to | free, which allows remote attackers to cause a denial of service | (daemon crash) via crafted TCP packets. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. This is not for chan_oh323, it's for chan_ooh323(c). A fixed version was uploaded yesterday. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479612: spandsp ABI SONAME
reassign 479612 spandsp 0.0.4pre18-1 retitle 479612 spandsp 0.0.4pre18-1 broke ABI severity 479612 grave thanks Steve, do we have any news regarding the ABI issues of spandsp I mentioned on my previous mail? The ABI issue will block spandsp from releasing with our stable release, scheduled for September 2008. If I don't get a reply from you I'll be forced to either accept that or bump the ABI on a Debian-specific way. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482997: asterisk: Extremely choppy sound and high CPU usage
tags 482997 + confirmed thanks Torgeir Skjøtskift wrote: When making calls involving IAX2 channels, sound is extremely choppy and CPU usage spikes. Messages on the CLI indicate problems while channels are active: WARNING[12301]: File chan_iax2.c, Line 4436 (socket_read): Received mini frame before first full voice frame IAX2 registry entries become unregistered IAX2 peers become UNREACHABLE This problem seems to be caused by the 2etch4 update, since it works fine in 2etch3 (see http://www.debian.org/security/2008/dsa-1563). To replicate: Set asterisk console debug and verbose to 100 SIP phones on machine A via IAX2 trunk to machine B via IAX2 trunk back to meetme room on machine A Creating 5-10 simultaneous calls should reveal the problem. This is indeed a regression from the versions before the security fix. upstream has fixed this with a commit[1] with the following description: Merge changes from team/russell/iax2_find_callno_1.2 These changes address a critical performance issue introduced in the latest release. The fix for the latest security issue included a change that made Asterisk randomly choose call numbers to make them more difficult to guess by attackers. However, due to some inefficient (this is by far, an understatement) code, when Asterisk chose high call numbers, chan_iax2 became unusable after just a small number of calls. On a small embedded platform, it would not be able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't run more than about 16 IAX2 channels. Ouch. These changes address some performance issues of the find_callno() function that have bothered me for a very long time. On every incoming media frame, it iterated through every possible call number trying to find a matching active call. This involved a mutex lock and unlock for each call number checked. So, if the random call number chosen was 2, then every media frame would cause 2 locks and unlocks. Previously, this problem was not as obvious since Asterisk always chose the lowest call number it could. A second container for IAX2 pvt structs has been added. It is an astobj2 hash table. When we know the remote side's call number, the pvt goes into the hash table with a hash value of the remote side's call number. Then, lookups for incoming media frames are a very fast hash lookup instead of an absolutely insane array traversal. In a quick test, I was able to get more than 3600% more IAX2 channels on my machine with these changes. There is another regression[2] thas has been similarly fixed in 1.2.28.1. It is, unfortunately, a huge commit, since it backports various stuff (astobj2) from 1.4. But I don't see another option to be honest and neither did upstream -- and 1.2 is in their deep-freeze state, similar to our own (security fixes and grave bugs only). security team, what do you think? Should I prepare a new version with these changes and upload it to security-proposed-updates? Regards, Faidon 1: http://svn.digium.com/view/asterisk?view=revrevision=115296 2: http://svn.digium.com/view/asterisk?view=revrevision=115564 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482997: asterisk: Extremely choppy sound and high CPU usage
Florian Weimer wrote: * Faidon Liambotis: security team, what do you think? Should I prepare a new version with these changes and upload it to security-proposed-updates? Do you mean stable-proposed-updates? That's up to the stable release managers. I don't like uploading such a change as a security update if we can avoid it. If you can guarantee sufficient testing, we could release a DSA errata, but this looks more like stuff for a point release. That's what I wrote initially, hence the typo :) I'm not so sure myself, we (upstream actually) broke an important functionally badly; 16 calls on a core2 duo 2.33GHz is a *very* *very* low number. It's a regression from a fix made in a security release, perhaps it should be fixed with a DSA? I'm not sure I could gurantee sufficient testing; I could test a channel or two, but not sure about running a high number of calls. Perhaps one of our reporters could do that? I don't know, I'll leave it up to you. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466729: asterisk: terminate called ...
reassign 466729 libvpb0 4.2.25-1 close 466729 4.2.26-1 thanks Eloy, Everything should work fine (with or without cards=0) for quite some time now. If not, please reopen this bug. Sorry for taking so long to actually document this on the BTS. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480839: consider not starting asterisk on upgrade when no /etc/rc*/S*asterisk symlinks exists
reassign 480839 debhelper thanks Timo Juhani Lindfors wrote: The postrm script #!/bin/sh set -e # Automatically added by dh_installinit if [ -x /etc/init.d/asterisk ]; then update-rc.d asterisk defaults 21 /dev/null if [ -x `which invoke-rc.d 2/dev/null` ]; then invoke-rc.d asterisk start || exit $? else /etc/init.d/asterisk start || exit $? fi fi # End automatically added section seems to start asterisk on upgrade even if there are no S symlinks in /etc/rc*: As evident by the comments, this snippet is added automatically by dh_installinit, a component of debhelper. I'm not sure if your rationale is valid but if it is, this affects a whole lot of other packages. I'm reassigning this to debhelper so that its maintainer can decide if it warrants a fix or not. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
[removing [EMAIL PROTECTED] from Cc] Florian Weimer wrote: severity 449148 wishlist tag 449148 -security thanks * Faidon Liambotis: You pointed out earlier in the bug log that is is a critical (sic) bug but there wasn't a fix prepared for etch. No, it's not. The prefix containing the old route server address is still assigned to Bill Manning, so there is no immediate cause for alarm. Even the fake servers returned the correct address for the L root, so the priming at the start would have removed the old L root address. Even without the security tag, this is certainly not wishlist since the old address for L is currently not responding to queries. I'm leaving it to the maintainer, however, to avoid a bts war :) We can't fix broken Internet routing. The same thing could happen to essentially all root servers. Changing addresses compiled/configured into BIND does not prevent this. We can't, no, but we can make sure our users are using the current root-servers; a routing attack on those would be taken more seriously, I guess. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449148: bind9: db.root needs update: L.ROOT-SERVERS.NET has changed IP address to 199.7.83.42
severity 449148 grave tags 449148 + security thanks Hi, You pointed out earlier in the bug log that is is a critical (sic) bug but there wasn't a fix prepared for etch. I wasn't aware of this change until I discovered[1] (via slashdot) a blog post explaining that the old IP address was still in use by a non-authoritative body, possibly recording queries and therefore gathering sensitive information. The old IP address has actually stopped responding to queries and therefore this isn't a very great deal, security-wise, right now. It is, however, a serious (imho) bug since 1 of the 13 root NS on etch systems isn't responding to queries. Also, nothing (AFAIK) is stopping the new owner to start responding to queries again, perhaps for malicious purposes such as recording data -- or worse, responding with fake answers! Please fix this bug for etch; I'd vote to do it via a security upload (and a DSA) but I guess an update through a stable point release would also be an option. Thanks, Faidon 1: http://www.renesys.com/blog/2008/05/identity_theft_hits_the_root_n_1.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479612: spandsp ABI SONAME
It has come to our (the Debian VoIP team) attention[1] that spandsp 0.0.4pre18 broke the ABI while keeping the same SONAME libspandsp.so.0.0.2. Every application compiled using a previous version crashes right now. It's also possible that spandsp 0.0.5pre2 also breaks the ABI (vs 0.0.4pre18) but I haven't checked, yet. I've tried evaluating the ABI-changing changes but gave up after a while :) It didn't seem anything too extreme that can't be fixed. However, it seems like it was your intention to break the ABI. If that's the case, why didn't you bump the SONAME? In fact, I don't understand why your SONAME is stuck at 0.0.2 while you obviously have released many versions since then. We could (and probably will) bump it ourselves but that has the risk of clashing with you if you change your mind at a later point. So we'd be force to name our version e.g. libspandsp.so.0.0.2deb1, which is suboptimal as you may imagine. So, in summary, Would you change your SONAME to libspandsp.so.0.0.5? Or even libspandsp.so.5 :) Also, can you be extra-careful in the future to not do ABI-incompatible changes? Thanks, Faidon 1: http://bugs.debian.org/479612 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479612: after upgrade to spandsp 0.0.4pre18 asterisk-app-fax crashes asterisk
James Bottomley wrote: Apparently the dependency of asterisk-spandsp-plugins and spandsp-dev is pretty tight. It looks like there was a binary incompatible change introduced by the upgrade from 0.0.4pre16 to 0.0.4pre18 I verified that asterisk crashes every time a fax is received after the upgrade Recompiling asterisk-spandsp-plugins_0.0.20070624-1 and reinstalling makes the crash go away. It looks like theres a compiled version in unstable that will go through to testing in 10 days and fix the problem The net of this bug report is that either these packages need to be tied together, or the so version of spandsp needs increasing for every change (because in the pre stage the ABI is obviously not stable) It's been a while since I used app-fax -- therefore, help maintaining it is welcome. Are you certain that the crash is because of a spandsp ABI change and not because of an asterisk ABI change? We've had one of those as well :( Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475601: openh323-titan_1.19.1~dfsg-4(sparc/unstable): FTBFS: segfaults during build on on sparc
tags 475601 + help thanks I've been trying to debug this with no success. It seems like a toolchain issue, since no code changes have been made since the previous revision, which worked fine on all architectures. Building with gcc/g++ 4.2, however, didn't have an effect. It's very likely that this a pwlib-titan bug (again, its previous version worked) but I'm not reassigning it just yet. Jurij Smakov offered to help and began debugging it (CCed). He mentioned about finding something (specifically, a NULL pointer dereference of *GetAPIVersion()) but didn't have time to investigate it further yet. This bug is blocking updates of other packages too (gnugk for sure, possibly others). There is also a slight chance that is related to #478502, a gnugk ftbfs on s390 for similar reasons. help is much welcome; build-deps are still installed on sperger (afaik). Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478361: FIX: asterisk: bashism in debian/rules
tags 478361 + pending
thanks
Leonardo Rodrigues de Mello wrote:
here is one patch that solve this bashism bug:
--- debian/rules.orig 2008-04-29 10:07:33.0 -0300
+++ debian/rules2008-04-29 10:07:56.0 -0300
@@ -152,7 +152,8 @@
dh_install -s --sourcedir=debian/tmp
- $(RM) -f $(CURDIR)/debian/asterisk/usr/sbin/{stereorize,streamplayer}
+ $(RM) -f $(CURDIR)/debian/asterisk/usr/sbin/stereorize
+ $(RM) -f $(CURDIR)/debian/asterisk/usr/sbin/streamplayer}
touch $@
install-indep: build-indep
Thanks, we have such a fix on our SVN for some days now.
[and btw, you forgot a closing brace :)]
Regards,
Faidon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475116: ITP: asterisk-espeak -- eSpeak text-to-speech module for Asterisk
Andrew Pollock wrote: * Package name: asterisk-espeak Version : 0.4 Upstream Author : Francois Aucamp [EMAIL PROTECTED] * URL : https://sourceforge.net/projects/asterisk-espeak * License : GPL Programming Lang: C Description : eSpeak text-to-speech module for Asterisk This package provides the eSpeak dialplan application, which allows you to use the eSpeak TTS Engine with Asterisk. Would you like to join the Debian VoIP team[1] and maintain this as part of the team? Regards, Faidon 1: http://pkg-voip.alioth.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439993: ITP: libapache2-mod-pubcookie -- apache2 module supporting Pubcookie
Hi, What are you plans about this ITP? It's been open for some time now. I've done some preliminary work on packaging upstream and will probably finish it really soon, since I need to deploy it for a work-related project. If you have prepared something, contact me to arrange comaintainance and/or sponsorship. If you haven't, I'll handle the whole thing, if you agree. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439993: ITP: libapache2-mod-pubcookie -- apache2 module supporting Pubcookie
Peter Woodman wrote: Yeah, I submitted that quite some time ago and then the idea got buried. I've just recently completed repackaging of this and just deployed it to some machines last friday.. I've switched to using git-buildpackage, and can stick it online by day's end, but seeing that you're a debian developer, you'll probably have a much easier time getting it included.. Being a DD will make it easier for me to upload the package. *Which* package will that be is a completely different story. I'd be happy either base my work on top of yours, or (even better) review your work and upload it, letting you handle the maintainership of the package. So, by all means, please stick it online :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462410: asterisk: astrerisk fails after update on codec conversion and crashes)
Since this is apparently a possible target for tonight's BSP, please don't NMU this just yet. It's rather complicated, involves lots of packages, is being handled and can't be easily solved in a night. FWIW, chan-capi should be working now; the bug is open, however, since other asterisk plugins are probably broken as well. If you really really want to have a look at this, please discuss this with me, either by mailing the bug or by IRC (irc.d.o, #debian-voip, paravoid). Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459712: build-conflicts with its own runtime
[the following is a more useful description of the bug than the irc log] pwlib and pwlib-titan build-conflict with their runtime parts besides the -dev parts. I think this is being done because a sample program is built and run when the package builds as a mean to catch runtime errors/screwups early. I'm not sure, however, if the conflict is really needed. The current situation is bad because people trying to do build tests on their desktops have to uninstall ekiga among others. Kilian, you've added both the conflicts and the sample build/run. Have you investigated if the conflicts is needed? In the case that it is, how would you feel about making the sample build/run conditional on the presence of libpt in the build system? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459712: build-conflicts with its own runtime
Kilian Krause wrote: In the case that it is, how would you feel about making the sample build/run conditional on the presence of libpt in the build system? Well, it was very much needed as a precaution in the past - especially on the non-trivial architectures. Doing a conditional test without enforcing it to FTBFS the package would just reintroduce that harm with a very low bar to jump over. If you think it is seriously needed we should add the DEB_BUILD_OPTIONS switch and conditionalize it in there - or plain not run it at all. I wasn't specific enough about the conditional: What I meant was, skipping the tests altogether if /usr/lib/libpt.so.1.10.1 is found. That way, it'll do the runtime test on clean chroots but skip it in development environments, which is much better than having a DEB_BUILD_OPTIONS. Any objections to that? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473456: asterisk: chan_sip starts RTP stream before receiving ACK
Marcus Better wrote: I'd like to forward this one upstream, but first it should probably be verified on some more recent build. Does anyone have Debian packages for 1.6 (or svn trunk) in the pipeline? I don't and I think neither does Tzafrir. However, if the bug stands, it should be fixed in 1.4 as well, IMHO (Digium guys may have a different opinion, unfortunately). Please forward this, thanks! Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460475: Asterisk crashes
close 438702 close 456383 close 460475 thanks Hi, I haven't received a reply in my recent ping and it is extremely likely that those bugs were something on your end. Therefore, I'm closing them. If you decide to reopen one of them (or all of them) at some point please make sure that it's not something related to your environment. Using packages provided by third-party (preferrably by Debian) would be extremely helpful. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433779: Fixed on 1.4.17
Hasse, hi, Nestor A. Diaz wrote: At least on 1.4.17 the problem is fixed. Could you confirm this? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472379: asterisk-chan-capi 1.0.2 error dialing or receiving calls
forcemerge 462410 472379 thanks I get the following error when I get an incoming call on my ISDN line using asterisk-chan-capi (1.0.2): [Mar 23 22:47:50] NOTICE[3302]: channel.c:2529 __ast_read: Dropping incompatible voice frame on CAPI/ISDN1#02/948197215-0 of format alaw since our native format has changed to unknown along with other similar errors and the call fails. Similar problem when creating an outbound call on the same ISDN line. Asterisk crashes and restarts. I compiled chan-capi 1.0.2 from source and all is OK when I use it instead of the debian package version. Yes, we are aware of the issue, which is that Asterisk broke the ABI at some point. It will be fixed soon, I hope. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452620: pm-utils: wrong cpu governor values written to /var/run/pm-suspend
I can confirm the bug (#452260) and the (trivial but well documented) fix as well. Thanks Vasili! Tim, you haven't made an upload of pm-utils since Jul 2007; the BTS is full of unanswered bug reports, some of them with trivial patches attached. You seem, however, to be active, according to the MIA database. It seems that you are no longer interested in this package. May be you could orphan it so that someone else could handle it? I'm not volunteering, but I'd like to see this in a proper state. Also, something worth noting is that Ubuntu is using pm-utils by default. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434053: twinkle: freezes after call termination
Marc, hi, Marc Haber wrote: I get an incoming call. THe call is established, but I cannot hear the caller and the caller cannot hear me. This _might_ be caused by my broken home router which does not NAT correctly (the ISP claims that VoIP is not supported on what they call Internet Access, and I cannot exchange the router for something else). However, when that call terminates, twinkle freezes. The Clock on the right side of the Line 1 panel simply stops, the detail display still says Call established, and twinkle does not react to anything. I only can click on the Close Window button and tell kwin to terminate the app. We got a report from a user that was facing a very similar problem -if not the same- that the bug is fixed in the current version of twinkle. According to that user, Jim Thomas, the fix may be related to a KDE upgrade -- perhaps it was not a twinkle bug in the first place. I'm not pretending to maintain twinkle (I don't) but none of the other members of the VoIP team have said anything about experiencing this bug, so I'd love your feedback on this! Marcus, you raised the severity to RC and marked the bug as found on 1:1.2-1 but didn't explain why. Are you experiencing this bug or are you marking it based on previous reports? Mikael, you did all the changes in the last upload. Mark Purcell who was maintaining this package inside the VoIP team is MIA for some time due to personal reasons and I haven't even used twinkle, ever! Can you handle this please? If not, can someone else from the team step up and maintain twinkle? This is a quite popular package, we shouldn't pretend to maintain it if we really are not. If noone steps up in a week or so, I'll file an RFH or even O bug. [forgive my rants, but I just read that twinkle will be removed from testing in the next britney run] Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471225: Missing manpages that are shipped by upstream
Package: slapd Version: 2.4.7-6.1 Severity: minor The package is missing several manpages that are shipped by upstream and can be found in the source. At least slapo-constraint, slapo-dds, slapo-dyngroup, slapo-dynlist and slapo-memberof are missing, possibly others. Please include them in a future version. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466729: Does not seem to be fixed
found 466729 1:1.4.18~dfsg-1 thanks 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? What is the value of the cards option in your vpb.conf? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469397: ITP: xbmc -- XBox Media Center Linux Port
Matthew Johnson wrote: Description: XBox Media Center Linux Port A media center originally written for the XBox and then ported to linux. I intend to upload this to experimental to start with. The linux port of it is just that. It's also designed for installation to a single directory, not installation on a unix system. I'll need to hack round that first. The version number is a CVS snapshot. I need to improve the long description before uploading. First of all, you surely must mean SVN and you should use a version number like 0.0~svn20080302, i.e. MMDD or else I'd expect an epoch pretty soon :) I've had a look at this and even made it to successfully work on my machine. I reported some issues back to upstream (e.g. incompatibility with libmms 0.4) and told them that I was interested on bringing this to Debian. I also mentioned the FHS issue which is an obvious blocker for Debian inclusion. I've had only negative comments; they apparently don't care about inclusion in Debian or Ubuntu (which is their platform of preference) and they just want to be able to release a liveCD that works. The FHS proposal was thought to be too much trouble for little gain and potentially harming the MacOSX port which is also under development. I had a look at the code and it's a mess, because of the XDK/Windows heritage, e.g. there are conversions between Windows paths (H:\) and Linux ones (/opt/xbmc). ...and that's why I never filed an ITP and still don't regret that choice. All in all, good luck with that ;-) You should expect some heavy upstream patching and a potentially unfriendly upstream. But I'd really like to see this packaged. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464203: asterisk-app-fax: fails to load with Asterisk 1.4.17
tags 464203 + unreproducible thanks Shane Wegner wrote: The rxfax and txfax plugins didn't load for on install from the archive. A quick rebuild against latest spandsp-dev and asterisk-dev fixed it for me. Not sure if others can confirm. Could you clarify what you mean by not loading? I'm getting == Registered application 'RxFAX' app_rxfax.so = (Trivial FAX Receive Application) == Registered application 'TxFAX' app_txfax.so = (Trivial FAX Transmit Application) On asterisk 1.4.17~dfsg-2+b1, arch: amd64. As I said before, it also works on i386. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460475: Asterisk v1.4.17 Crashed on Debian GNU/Linux Etch
GNUbie wrote: Hello Faidon, On Thu, Feb 21, 2008 at 4:32 AM, Faidon Liambotis [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Any news about your setup? Is it stable? Was it the build-environment of yours? Can we close *all* of your segfault bugs? They're quite a few :-) Sorry for the very late response. I almost forgot this because I was so busy here. I was able to reproduce to crash my Asterisk v1.4.17~dfsg-2 setup on my Debian GNU/Linux server and it happened last February 5, 2008. Was that with the version Victor provided you? Last time we checked you were having some problems with self-compiled problems that were magically solved when Victor provided you with his packages. We have three open segfault bugs from you on our BTS which are unrelated with each other. Noone else has experienced any of those, AFAIK. It really sounds like a problem in your end -- either a miscompilation or RAM problems. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466391: Vodafone Mobile Connect Card for Debian
Pablo, hi, I found a piece of software that you apparently authored and Debianized, Vodafone Mobile Connect Card Driver for Linux. I am a Debian Developer and I am interested in having this in Debian. That will mean that it will eventually get propagated to Ubuntu, which I've seen that you use and care about. I'll soon feed you with packaging patches :) Concerning the branding though, two issues worry me: a) By calling this Vodafone Mobile Connect, users may get misleaded that this only works with the Vodafone network, something that is apparently not true. b) More importantly, Vodafone is a registered trademark; possibly Vodafone Mobile Connect too. Do we have permission from Vodafone to use this trademark for the package uploaded to the Debian distribution which may have changes compared to the version published by you? We've been bitten by this in the past (with the notable example of Mozilla products) and I'm trying to be careful. I've been thinking renaming this to a more common name but I'm afraid that will be a disrespect to your work and Vodafone Group's intentions. I'd be happy to cooperate with you privately or in public. Please note when replying that I'm Ccing Debian bug #466391 [1], which is a Request for Package (RFP) bug by a Debian user. Thanks, Faidon 1: http://bugs.debian.org/466391 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460475: Asterisk v1.4.17 Crashed on Debian GNU/Linux Etch
Hi, GNUbie wrote: On Jan 26, 2008 12:44 AM, Victor Seva [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Then ... is this bug report solved? can you close it with a small explanation? I can't say it's really solved. I have to monitor my current setup for the next few days or weeks. I'll update you all. Any news about your setup? Is it stable? Was it the build-environment of yours? Can we close *all* of your segfault bugs? They're quite a few :-) Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466729: asterisk: terminate called after throwing an instance of 'Wobbly'
Hi, Vincas Ciziunas wrote: Asterisk does not start up. Please find attached, the output of asterisk -vvv -g (minus the Core Dumped message at the bottom) and the core file from the crash. Thanks for the detailed bug report. This is an issue with libvpb -- probably with the way asterisk uses it (and that's why I'm not reassigning it). Do you have a VPB card and/or a modified vpb.conf? We'll definitely fix it, even though we haven't been able to reproduce it. Will try though. Meanwhile, you can add an explicit noload = chan_vpb.so to your modules.conf, as a temporary workaround. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466283: hostapd: Slightly wrong LSB header in init.d script
Petter Reinholdtsen wrote: Package: hostapd Version: 1:0.5.4-1 Severity: important Tags: patch User: [EMAIL PROTECTED] Usertags: incorrect-dependency When testing dependency based boot sequencing, I discovered a bug in the init.d script for hostapd. It need a mounted /usr/ and this require a dependency on $remote_fs. Fixing these issues is a release goal for lenny, so it is good if it is fixed quickly. Thanks a lot, will fix. Unfortunately, it is easy to do mistakes like this since there is (was?) no way to test it. May be something automated would help...? Not sure if it's possible though, with all the combinations that could happen. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465468: Bug#465453: asterisk: illegal free(env_var) after putenv(env_var)
severity 465452 minor severity 465453 minor severity 465455 minor severity 465460 minor tags + 465452 upstream tags + 465453 upstream tags + 465455 upstream tags + 465458 upstream tags + 465460 upstream tags + 465468 upstream tags + 465478 upstream thanks Hi, I'm not sure what you expect from this flood of bug reports. These are all against the version of asterisk present in the stable suite of Debian which means that no minor fixes are accepted -- only security fixes and severe bugs, such as data corruption. Moreover, these are all are upstream issues and I'm not sure what we can do about them. Forwarding them to Digium is not an option for many reasons: a) upstream needs a license disclaimer on all patches b) these are against asterisk 1.2 which is frozen for only security fixes. I'd suggest to: - Verify which of these apply to asterisk 1.4 (present in unstable/testing). - Report back which of them apply so we can close the rest. - Open up a bug report against bugs.digium.com suggesting your fixes to upstream (be careful not to report any bristuff issues!) - Then report back the URLs of the bugs on Digium's BTS. I may be requiring too much from you but your bugs are *code* bugs and you should approach upsteam with those. I am keeping the bugs open for the moment even though I'm not too sure about it. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464203: asterisk-app-fax: fails to load with Asterisk 1.4.17
Shane Wegner wrote: The rxfax and txfax plugins didn't load for on install from the archive. A quick rebuild against latest spandsp-dev and asterisk-dev fixed it for me. Not sure if others can confirm. Seems fine on i386. Perhaps somewhere along the way the ABI got broken and asterisk-app-fax got built with a broken one? Is there anyone else who could try on amd64? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463983: asterisk doesn't behave the same when in debug mode
root wrote: To get my asterisk to work I have to launch it through the command line: asterisk -vvvc Otherwise, through /etc/init.d/asterisk start It doesn't behave in the same way (most operations get a 603 Declined response). Probably because that way asterisk runs as root, while the init script calls asterisk -U asterisk (run as the asterisk user). You probably have some configuration files owned by root and with no permissions. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462410: asterisk: astrerisk fails after update on codec conversion and crashes)
Holger Wegner wrote: Hi, I build the asterisk-chan-capi package from new with: - apt-get update - apt-get build-dep asterisk-chan-capi - apt-get source --build asterisk-chan-capi and installed it. Now it works again for me. Unfortunately, this means that at some point we (or probably upstream) broke Asterisk's ABI. You said that your setup broke when you upgaded to 1.4.17. Which version did you have before? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460475: Asterisk v1.4.17 Crashed on Debian GNU/Linux Etch
Victor Seva wrote: On Jan 24, 2008 9:03 PM, Victor Seva [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'm using asterisk v1.4.17 on my Debian etch without problems. You can test my own backported packages [0]. [0] http://linuxmaniac.torreviejawireless.org/debian/asterisk/1.4.17~dfsg/ I will download it later. I don't experience any crash problem anymore. If that's the case, can we asume that your other bugs are solved too? As I suspected, it's probably something of your environment. Perhaps the compiler is miscompiling things or something like that. Victor, thanks! Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462270: asterisk: agi-bin directory is intended for local scripts, and should be under /var
First of all, let's all agree that this is not a clear cut case. We definitely have a bug here, aside from this discussion, and this is that we don't ship the agi-bin directory even though we referenced this. Sadly, Andew Pollock didn't report this as a bug when he found it. Tim Retout wrote: With web servers such as Apache, it is generally possible for the administrator to configure other cgi-bin directories at different locations. Administrators do not have to put their custom CGI scripts in /usr/lib/cgi-bin. Asterisk can have only one agi-bin directory, so I do not think this is comparable. (Hardcoding the full path in extensions.conf is not really the same.) This is the whole point of this discussion. We're trying to find a single path that will fulfill different needs (shipping AGIs from packages AND provide a way to install site-local AGIs). It is an upstream bug that has hit us many times before -- we had to do a symlink workaround recently for the location of the sounds. This also has the benefit of retaining some compatibility with upstream's location. Upstream is incompatible with FHS. A symlink there might cause confusion. I have to agree with Tzafrir here on both points: a) upstream is known for not caring less about the FHS b) afaict, we are going to need symlinks for each and every package or provide scripts that do that. Not really a solution. I am mostly thinking about administrators writing custom AGI scripts, and wanting to have them included in the agi-bin directory. They could have different scripts on each host. If they put their custom scripts into /usr/share/asterisk/agi-bin, then the scripts may be overwritten by system upgrades; there is no guarantee that a Debian package might not accidentally choose the same name as one of the local scripts. See footnote [27] of FHS 2.3: http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1450 Agreed so far. Requiring administrators to add their own host-specific scripts under /usr also goes against the FHS (and therefore Debian Policy); the intention of the /usr hierarchy is that it is shareable, read-only data that is not host-specific - it could potentially be shared between different machines: http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Well, I don't exactly agree to the host-specific scripts. If we go down this road, then the whole /usr/local should go away (think of perl, python etc.) [Technically, site admins should perhaps be using somewhere under /srv for host-specific scripts, not /usr/local: http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM ...but it looks like it would be unwise for packages to install anything there themselves.] Not only we cannot put stuff in /srv (not even subdirectories, unlike /usr/local) but we cannot even make assumptions that something may reside there. I believe symlinks in /var/lib/asterisk/agi-bin can be considered state information of the system (i.e. the set of currently available AGI scripts on this host) and fits the FHS criteria: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION That is a stretch and totally incorrect, sorry. So, I hope this isn't just making things more complicated for nothing - it could be interpreted as a violation of a must directive in Debian Policy (section 9.1.1). That may be a legitimate bug but it's hardly a policy violation. I presume you agree, since you didn't file it as serious, even though you are aware of our procedures. All in all, I believe that we may have to support multiple directories (i.e. also supporting /usr/local) and the only way I can see for doing that is by modifying asterisk's source. I'll have a look and try to produce a not very crude hack to do that. I will also try to move this discussion with upstream -- may be we can agree on a proper solution. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462270: asterisk: agi-bin directory is intended for local scripts, and should be under /var
Tim Retout wrote: Well, I don't exactly agree to the host-specific scripts. If we go down this road, then the whole /usr/local should go away (think of perl, python etc.) There can be site-specific software that is not host-specific, so third-party Perl modules would still belong in /usr/local. Exactly; there can be site-specific AGIs that are not host-specific (been there, done that). If you think about it a bit, there's not much of a difference. But symlinks in /var/lib would not be unprecedented; I can think, for example, of the typo3-dummy package (for configuring a web app), which puts a whole hierarchy of files and symlinks in /var/lib/typo3-dummy. There must be more. HylaFAX does something like that. It's ugly as hell :-) tomcat has a bunch of symlinks and it's not that bad. I'd prefer it if it was our last option though. Yes, ideally we would add this support - but would it not involve changing the format of the config file, and creating even more incompatibilities with upstream? It might. Not sure yet. I'll try to discuss this with upstream. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462410: asterisk: astrerisk fails after update on codec conversion and crashes
reassign 462410 asterisk-chan-capi severity 462410 grave thanks Holger Wegner wrote: After updating to 1.4.17 the system is crashing everytime it receives or send a connection to the chan-capi. The Capi is connected to a Eicon Diva Server 4BRI. This was working before. A call transfer from SIP to SIP or IAX or voicemail does work. Transfer from Capi to IAX does lead to a crash too. In the chan capi alaw ist used, in sip alaw and ulaw. I wonder about the messages (see below) What do you mean by the system is crashing? Asterisk? Could you send us the core file? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459244: asterisk: split-up proposal
tag 459244 + wontfix thanks Matthew King wrote: To the best of my knowledge the (mods|site)-(available|enabled) system that Apache uses is something in Debian that has diverged from upstream. At least insofar as their configuration doesn't use it by default. The ability via the include directive is, of course, part of upstream. What's the point? Modules are enabled/disabled in modules.conf. Each module has a separate configuration file. How easier can it get? Apache is quite different FWIW. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456440: sipsak: debian/copyright does not contain a verbatim copy of its copyright and distribution license
I've verified this trivial bug and the proposed solution. I have prepared an NMU and will upload shortly, since sipsak is going to be removed from testing today. Yasuhiro, this package hasn't had an upload for a year and you appear to be MIA. I'd like to adopt this package within the Debian VoIP team. You are welcome to join us whenever you find the time. I have no grounds for hijack (yet) nor the desire to do so, so I'm going to wait for your reply and NMU until then :) Attached is the NMU for the 0.9.6-1.2 upload. Regards, Faidon diff -u sipsak-0.9.6/debian/changelog sipsak-0.9.6/debian/changelog --- sipsak-0.9.6/debian/changelog +++ sipsak-0.9.6/debian/changelog @@ -1,3 +1,14 @@ +sipsak (0.9.6-1.2) unstable; urgency=high + + * Non-maintainer upload by the Debian VoIP team. + * Urgency high because of an RC bugfix. + * Mention all the copyright holders and GPLv2 or later in +debian/copyright. (Closes: #456440) + * Fix debian/watch by using a v3 watchfile. (Closes: #450083) + * Don't ship an empty /usr/sbin. + + -- Faidon Liambotis [EMAIL PROTECTED] Tue, 22 Jan 2008 11:07:01 +0200 + sipsak (0.9.6-1.1) unstable; urgency=low * NMU diff -u sipsak-0.9.6/debian/dirs sipsak-0.9.6/debian/dirs --- sipsak-0.9.6/debian/dirs +++ sipsak-0.9.6/debian/dirs @@ -2 +1,0 @@ -usr/sbin diff -u sipsak-0.9.6/debian/copyright sipsak-0.9.6/debian/copyright --- sipsak-0.9.6/debian/copyright +++ sipsak-0.9.6/debian/copyright @@ -8,3 +8,19 @@ -Copyright: 2002-2003 Fhg Fokus +Copyright: + Copyright (C) 2002-2004 Fhg Fokus + Copyright (C) 2004-2005 Nils Ohlmeier -Licensed under GPL2. a copy of which may be found in /usr/share/common-licenses/GPL-2 + sipsak is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + sipsak is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License with + your Debian GNU/Linux system, in /usr/share/common-licenses/GPL, or with + the Debian GNU/Linux sipsak source package as the file COPYING. If not, + write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, + Boston, MA 02110-1301 USA diff -u sipsak-0.9.6/debian/watch sipsak-0.9.6/debian/watch --- sipsak-0.9.6/debian/watch +++ sipsak-0.9.6/debian/watch @@ -1,6 +1,5 @@ -# Example watch control file for uscan -# Rename this file to watch and then you can run the uscan command -# to check for upstream updates and more. -# Site Directory Pattern Version Script -version=2 -http://download.berlios.de/sipsak/sipsak-(.*)\.tar\.gz +version=3 + +opts=downloadurlmangle=s/prdownload/download/,uversionmangle=s/-.*$// \ +http://developer.berlios.de/project/showfiles.php?group_id=485 \ +http://prdownload.berlios.de/sipsak/sipsak-(.*)\.tar\.gz
Bug#460475: Asterisk v1.4.17 Crashed on Debian GNU/Linux Etch
reassign 460475 asterisk 1.4.17~dfsg-2 thanks [you should report bugs with Package: asterisk, not the .deb file] Hi, again, Each time we get a better bugreport :-) This time you managed to report us all the relevant information, thanks! TBH, I haven't really looked at your backtrace but it strikes me that you've had 3 *different* crashes while noone else experienced *any* of these. I'm starting to suspect problems specific to your setup. Perhaps faulty hardware? Maybe memory? Do you experience crashes in other parts of the system? Kernel panics? Also, you're mentioning that you're (re)compiling the packages yourself. Perhaps a bad compiler is miscompiling the code? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460029: ulogd: mails to Maintainer are bouncing
Lucas Nussbaum wrote: Mails sent to the maintainer of this package are bouncing with the following error message: [EMAIL PROTECTED] SMTP error from remote mailer after RCPT TO:[EMAIL PROTECTED]: host mail.debian.gr [87.230.20.158]: 550 5.1.1 [EMAIL PROTECTED]: Recipient address rejected: User unknown in local recipient table Hrm, I totally forgot to do that :( My bad, sorry. Thanks for the reminder, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399970: successfull use of asterisk + misdn
Victor Seva wrote: Thanks. What changes are needed in the Asterisk package to properly support misdn? Any way to integrate them in the main package? I'm only adding my libmisdnuser-dev and libmisdnuser0 to Build-Depends. This sounds interesting. Simon's opinion is that mISDN is immature for inclusion to Debian. Could you share your work of the packages please? Simon, care to join us? :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458877: asterisk: FTBFS: E: Couldn't find package libc-client2006j2-dev
reassign 458877 uw-imap retitle 458877 Please rename the -dev package to libc-client-dev thanks Steve Langasek wrote: You've fixed this bug by adding the following build-dependency: libc-client2007-dev | libc-client-dev Please build-depend only on libc-client-dev instead. The use of version numbers in this -dev package name is ill-informed crack, and your use of it here is just going to cause a build failure again the next time the package name changes. The libc-client-dev name, OTOH, is persistent and will always be usable. Unfortunately, we can't do that, since asterisk needs a version = 2006. libc-client-dev is present in etch (version 2002) and I can't specify a version number on a virtual package. If we change the dependency to libc-client-dev, the package will FTBFS on a system with etch sources present (the real package will be preferred over the virtual one). The only sane way to fix this is to stop having a different -dev package name at each version. libc-client-dev should be fine, as it was on = etch. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459244: Fw: Bug#459244: asterisk: split-up proposal
jamhed wrote: На Sat, 05 Jan 2008 11:10:05 +0100 Julien BLACHE [EMAIL PROTECTED] записано: That doesn't buy anything, you've just had a false good idea. May be idea is not so false but implementation ;) Think of a modules configuration script, like apache. It will allow to achieve the same thing. Come on, adding single lines to one configuration file asking to load (or noload, in case of autoloading) modules can't be _that_ hard, for anyone -- at least for anyone trying to configure Asterisk. It sure isn't harder than installing a dozen packages just to achieve basic PBX functionality. Again, I'm open to a split that would be done for dependency reasons, just like asterisk-h323 is splitted. Maybe odbc, maybe postgres, not sure yet. Splittting to 50 (or 40, or 30, or...) packages for maintainance reasons: over my dead body :-) Just trying to be clear here, there's no point of discussing this further. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459244: asterisk: split-up proposal
jamhed wrote: So I suggest you be more specific about what you want to move to subpackages. Why would you want app_voicemail.so in a separate package? What harm is it in this module lying around? One valid reason would be dependency on external libraries: odbc, pgsql, netsnmp, radius, sqlite. We have a separate asterisk-h323 . What I've got so far: snip So, it is way less than 164, only 48 so far. 48 packages is a bloat for no reason; think of all the overhead a package has both on users and on mirrors and think of all the maintainance burden. The general idea - every extra functionality goes to it own package, especially modules with it own config files, so I will be able to select via aptitude what exactly my asterisk is intended for. Just for example, I've never used mgcp, dundi, enum, jabber, snmp, smdi, odbc, sqlite, tds, chan_phone, chan_skinny, adsi, alarmreceiver, and definitly will never do. So what is the reason to keep loading unused modules into a production system ? Some of them spin out their own threads, some of them wants me to configure it. You can always disable autoload and load only the modules that you want to. You can leave them unconfigured or even remove the configuration files. With the current infrastructure you can even provide a configuration file package to not include these files *at all*. And I'd like to keep an asterisk installation lean and mean, with only functionality I've selected - so right now I'm forced to delete unused stuff, after each setup. /usr/lib/asterisk/modules is ~5M. It may not be lean and mean but it's not exactly the opposite either. One valid reason would be dependency on external libraries: odbc, pgsql, netsnmp, radius, sqlite. We have a separate asterisk-h323 . And yes, here is yet another reason to separate, at least all stuff depended on externals, like pgsql, mysql, etc. That is an actual reason. I've thought about it myself, splitting some modules to different packages to minimize the dependency chain. I'm leaving this open, because it's a valid request -for that last reason- that needs a little bit more though. Don't expect us to split asterisk to 48 packages though, there's no way this is going to happen ever. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446824: CVE-2007-5448 remote denial of service via crafted beacon frame
Luk Claes wrote: CVE-2007-5448[0]: | Madwifi 0.9.3.2 and earlier allows remote attackers to cause a denial | of service (panic) via a beacon frame with a large length value in the | extended supported rates (xrates) element, which triggers an assertion | error, related to net80211/ieee80211_scan_ap.c and | net80211/ieee80211_scan_sta.c. If you fix this vulnerability please also include the CVE id in your changelog entry. This is fixed in upstream svn on: http://madwifi.org/changeset/2736 For further information: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5448 Can you please upload a fixed package to stable? This is remotely exploitable over the air -- an attacker could send a specially crafted packet with his wireless device and crash all affected systems literally around him. Imagine exploiting this e.g. on a DebConf. IMHO (I'm not a maintainer) this should be fixed ASAP in stable-security and the DSA should include that manual action is required to actually fix this (rebuilding and reloading the kernel modules). Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458106: New upstream version 0.6.1
Marco Rodrigues wrote: Please update to the latest upstream version 0.6.1 http://siproxd.tuxworld.ch/ChangeLog Please, stop this! We are aware of the new siproxd releases. They still haven't switched to libosip3 however and libosip2 is no longer available in Debian (and it won't be). siproxd can't be built in Debian at the moment therefore there's no point on uploading a newer version. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458105: New upstream version 0.5.6
Marco Rodrigues wrote: Please update to the latest upstream version 0.5.6 http://developer.berlios.de/project/shownotes.php?group_id=1208release_id=13147 First of all, please stop this. We have watch files and a nice overview page[1] so that we can get informed of packages that need attention. Having more bugs to close won't help us with anything. That being said, this is a legitimate bug, since this release slipped through. We have IPtel in our watch file and their FTP[2] does not have the 0.5.6 release at all and they have a file called LATEST-IS-0.5.5. I'm leaving this open. Thanks, Faidon 1: http://pkg-voip.alioth.debian.org/cgi-bin/qareport.cgi 2: ftp://ftp.iptel.org/pub/radiusclient-ng/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447245: zaptel-source: OSLEC echo canceler renders zaptel channels unusable
Alessandro Polverini wrote: I can't, because it's a special linux running off a CD with bootcd, it has no reportbug and such. Please ask which kind of informations you need and I'll try to provide them. What's important is the kind of architecture the system is. I'd bet that your CPU is a amd64/x86_64 one and that you're running a 64-bit kernel on it. Is it? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447245: zaptel-source: OSLEC echo canceler renders zaptel channels unusable
Tzafrir Cohen wrote:
On Thu, Dec 27, 2007 at 03:40:32AM +0200, Tzafrir Cohen wrote:
Some progress: after much debugging, David Rowe noticed that at least
one source of problems is the following code from oslec/oslec_wrap.c:
static __inline__ uint64_t cycles(void) {
uint64_t x;
__asm__ volatile (rdtsc\n\t : =A (x));
return x;
}
This seems to cause harm on amd64. Is this a problem with AMD? with x86_64?
Could you please try the attaced patch?
As you are aware, I was experiencing the bug myself on my x86_64 (Intel
Core 2) system. The patch definitely fixes my problem :)
Are there any side-effects with this patch or is it safe to apply it as-is?
Alessandro, reportbug said that your system is an i686/k7; did you file
the report from the system that you were experiencing the problem?
Regards,
Faidon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456383: Asterisk-1.4.15 Crashed on Debian GNU/Linux Etch i386
reassign asterisk 1.4.15~dfsg-1 thanks GNUbie wrote: I re-built the asterisk v1.4.15 source package and other dependencies from the Debian Unstable repository and installed them afterwards on my snip You can download the core dump file at http://files-upload.com/files/679314/core.asterisk.1197633817.4905.tar.bz2 Since you are rebuilding packages, this core file is useless to me. Could you fire up a gdb and produce 'bt', 'bt full' and 'thread apply bt full' and send these as attachments here? Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457063: asterisk: CVE-2007-6430 remote unauthenticated sessions
Nico Golde wrote: CVE-2007-6430[0]: | Due to the way database-based registrations (realtime) | are processed, IP addresses are not checked when the | username is correct and there is no password. An | attacker may impersonate any user using host-based | authentication without a secret, simply by guessing the | username of that user. This is limited in scope to | administrators who have set up the registration database | (realtime) for authentication and are using only | host-based authentication, not passwords. However, both | the SIP and IAX protocols are affected. This is affecting unstable and stable. oldstable is not affected. I'll upload 1.4.16 (.1 due soon probably, since .16 has a major bug) to unstable probably tomorrow or the day after that. For stable, I don't think that the vulnerability is serious enough to warrant a DSA. Maybe s-p-u is a better candidate? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452595: Asterisk SNMP OID's not available.
reassign 452595 snmpd 5.4.1~dfsg-4 retitle 452595 agentXPerms configuration directive is ignored thanks Jon Webster wrote: pbx# snmpget localhost -v2c -c asterisk 1.3.6.1.4.1.22736.1.5.1.0 ASTERISK-MIB::astNumChannels.0 = No Such Object available on this agent at this OID I tried to follow the documentation and verified that indeed it does not work. It appears that asterisk is unable to connect to the AgentX socket of snmpd. This appears to be a permission problem, since asterisk drops its privileges. The agentXPerms configuration directive of snmpd.conf (as suggested by Asterisk's documentation and snmpd's man page) is supposed to call chmod/chown to alter the permissions of /var/agentx and /var/agentx/master. This is not however the case, presumably due to a bug of snmpd. To workaround this bug, try to change the permissions of /var/agentx and /var/agentx/master. For example chown -R asterisk.asterisk /var/agentx This is far from ideal, since you'll have to execute this every time snmpd is (re)started. I'm reassigning the bug so that the Net-SNMP maintainers can have a look. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454342: asterisk: tos-libcap patch is broken
tags 454342 + pending thanks Hi, Shane Wegner wrote: Was getting the following error in my Asterisk log: [Dec 4 09:49:18] WARNING[5787] rtp.c: Unable to set TOS to 184 Some poking around the tree and it looks like though the tos-libcap patch is getting applied, that patch depends on #define HAVE_CAP 1 somewhere in the build process. I dropped it in at the top of main/asterisk.c where the actual capability code sits and it fixed my problem. Probably best to do it using autoheader in autoconf.h.in though. This is known and has been fixed for some time in our repository. The fix will be included in the next upload. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#153564: libpt's PlayFile does not work properly under powerpc
[skipping the non-productive discussion] Santiago Vila wrote: On the bug itself, it'd be nice if you provided more info, since you have the technical skills for that (being a DD etc.) The test in my previous message were done on etch systems, which means ohphone version 1:1.4.5+20060204-2 and libpt-1.10.0 version 1.10.2-2. The powerpc machine is a Mac Mini. I don't plan to upgrade to lenny right now, sorry, but I suggest that you send a mail message to debian-powerpc if you need to reach people having a powerpc machine running Debian. You could always install unstable on a chroot... Anyway, from what I understand, you're not too keen on actually fixing the bug. Simon, could you have a look? You still have access to that powerpc you had, right? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454133: pwlib: CVE-2007-4897 remote denial of service
Nico Golde wrote: Package: pwlib Version: 1.10.2-1 Severity: grave Tags: security Have you checked if this affects stable and oldstable? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454155: asterisk: SQL Injection issue in res_config_pgsql/cdr_pgsql (AST-2007-025/AST-2007-026)
tags 454155 + pending thanks Teodor wrote: The asterisk team has fixed two security updates: AST-2007-025 - SQL Injection issue in res_config_pgsql AST-2007-026 - SQL Injection issue in cdr_pgsql These issues were fixed in the latest release (1.4.15). Please upgrade the package to this version. We are aware of the issues and we already pushed updates to oldstable (sarge) and stable (etch), c.f. DSA 1417-1. 1.4.15 is already packaged but it's not still updated since we have a pending issue: Digium decided to break the ABI with *all* external modules. Wonder why they call it a stable release :-) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#153564: libpt's PlayFile does not work properly under powerpc
Santiago Vila wrote: This was reported 6 years ago (!) and the submitter was asked for more information 3 years ago and never replied. I guess we can safely close this. Sorry, but bugs do not fix themselves magically, they are either fixed or not. If you think it's fixed, find someone with a powerpc to check it. If you can't verify that the bug is fixed, then the bug should be considered open for all purposes. BTW; I have a powerpc now, but I didn't three years ago (that's why it was not easy for me to answer questions about this bug). So I will try to test this myself. Thanks for the reminder. I can't see how it helps to have a bug on the BTS open for 6 years without response from the submitter and without action from the maintainer(s) while a ton of upstream releases have been released since then. If someone is indeed experiencing this bug it may reopen this (or, create a new one, in case he didn't see this one). *Then* we can began investigating this, since we'll have a guinea pig to test this on. It appears that you reopened the bug and you are volunteering to be that guinea pig; that fulfills my expectations, so I won't close it. Be warned though that I will close this again if considerable time passes without action by you or anyone else (including the submitter). Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
