Bug#458877: asterisk: FTBFS: E: Couldn't find package libc-client2006j2-dev

[Faidon Liambotis]

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

[Faidon Liambotis]

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

[Faidon Liambotis]

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:

> 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

[Faidon Liambotis]

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#458105: New upstream version 0.5.6

[Faidon Liambotis]

Marco Rodrigues wrote:
> Please update to the latest upstream version 0.5.6
> 
> http://developer.berlios.de/project/shownotes.php?group_id=1208&release_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#458106: New upstream version 0.6.1

[Faidon Liambotis]

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#447245: zaptel-source: OSLEC echo canceler renders zaptel channels unusable

[Faidon Liambotis]

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

[Faidon Liambotis]

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

[Faidon Liambotis]

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

> 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#452595: Asterisk SNMP OID's not available.

[Faidon Liambotis]

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#457063: asterisk: CVE-2007-6430 remote unauthenticated sessions

[Faidon Liambotis]

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#454342: asterisk: tos-libcap patch is broken

[Faidon Liambotis]

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#454155: asterisk: SQL Injection issue in res_config_pgsql/cdr_pgsql (AST-2007-025/AST-2007-026)

[Faidon Liambotis]

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#454133: pwlib: CVE-2007-4897 remote denial of service

[Faidon Liambotis]

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#153564: libpt's PlayFile does not work properly under powerpc

[Faidon Liambotis]

[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#153564: libpt's PlayFile does not work properly under powerpc

[Faidon Liambotis]

Santiago Vila wrote:
> If you can't see how it helps to have a bug on the BTS that someone
> reproduced at the time it was submitted then you don't understand how
> the BTS works. Please do not manipulate bugs in the BTS if you don't
> understand how the BTS works.
> 
> A bug is not fixed automatically by waiting some amount of time or
> just because new upstream releases happened. A bug is fixed when it's fixed.
This is getting tired. We both know how the BTS works.
Various ways to insult you as you did come to mind, but is there a need
to go there? Can we keep this discussion on the facts?

- When we close bugs, we almost *never* know if it is actually fixed in
  a release. We make a judgement  that may be wrong. That's why "reopen"
  exists in the first place.
- There have been 48 releases of pwlib since the bug was initially
  reported. The possibility that this bug was fixed in one of these was
  quite high.
- The usual way to close such a bug is for the submitter(s) to test if
  it is fixed or not. You were asked for an update and didn't respond
  for 2 and a half years.
- Therefore, there were probable fixes and no feedback. Closing the bug
  is the most sensible option.
- Moreover, there's always the option of re-opening the bug, if it
  exists. And you did that. And I'm happy for that (well, as happy as
  one can be on a bug report) since that was one of the acceptable
  scenarios.

Next time, if you don't want to be annoyed to see one of the bugs that
you submit close, please respond when the maintainer asks you for feedback.

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.)

Kilian?

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

[Faidon Liambotis]

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]

Bug#299583: libpri1: D-Channel stop working when upgrading to 1.0.4-1 to 1.0.4-2

[Faidon Liambotis]

tags 299583 + moreinfo unreproducible
thanks

I apologize beforehand for being so late in responding you.
Since huge progress has been made by both of our upstreams since 1.0.x,
could you test if this bug still occurs for you.

I realize that you may not use asterisk at all after such a long time
with problems; if so, please tell us so we can close the bug report.

Thanks,
Faidon



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

Bug#453161: Patch to fix libpri FTBFS

[Faidon Liambotis]

Aurelien Jarno wrote:
> As far as I understand, the patch is correct. If you need a header you
> have to include it and do not assume it is included by another one. This
> also improves portability among various OS.
My concern was that this is breaking various unrelated packages.
Lucas said though that this is not affecting many (~10) so it's probably
fine.

Regards,
Faidon



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

Bug#453161: Patch to fix libpri FTBFS

[Faidon Liambotis]

brian m. carlson wrote:
> Attached is a patch to include stddef.h, since sys/time.h no longer
> includes it.
Thanks!

Damn, I had that patch but run out of network & battery in the airport
before testing it :-)

I will upload after confirming that this changing sys/time.h is supposed
to be OK (I don't believe it is, but the maintainers may disagree for a
good reason).
Lucas, did you have any more of these?

Regards,
Faidon



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

Bug#448118: overlapdial does not work with package libpri1.0, blockdial works fine. With an older version of libpri, such as 1.2, overlapdial still works.

[Faidon Liambotis]

tags 448118 + upstream pending
thanks

Stephan Seitz wrote:
> Yes, I was bitten by this bug, too, when I upgraded to Asterisk version
> 1.4.13-BRIstuffed-0.4.0-test4. My Zap channel which is needing  
> overlapdial stopped working.
> 
> According to http://www.ip-phone-forum.de/showthread.php?p=940540
> (German) this is a bug in Bristuff:
> „Ja. Genau. Mit der libpri-1.4.1 aus bristuff-0.40.test4 kann ich an der
> als NT konfigurierten hfc-Karte nicht wählen. Nach dem Löschen der libs
> und Kompilieren der libpri-1.2.4 aus bristuff-0.30 geht es.”
> Summary: libpri-1.4.1 and bristuff-0.40.test4 don’t work with a HFC ISDN
> card configured in NT mode.
> 
> Using the libs from the package libpri1.2_1.2.4-1 (bypassing the
> dependency chain) 1.4.13 is working fine like the 1.2version before.
Fortunately, Tzafrir fixed the bug :-)
It's pending upload. Real soon now (tm).

Thanks,
Faidon



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

Bug#399970: current status of chan_misdn

[Faidon Liambotis]

Simon Richter wrote:
>> Simon Richter has packaged the up-to-date misdn-user package (called 
>> libmisdn-dev andn libisdnnet-dev in Debian) and uploaded to experimental. It 
>> should theoretically be possible to build chan_misdn against those two 
>> packages.
> 
> In theory, yes. The problem is that I don't want to move these to
> unstable until there are a few more safeguards against kernel crashes in
> place, and building unstable packages against packages in experimental
> is generally frowned upon. The out-of-tree chan_misdn no longer
> compiles, and this cannot be fixed trivially (I've tried...).
> 
> I hope we can make some progress on that front in Extremadura. :-)
Moreover, I've tried building the chan_misdn as shipped by Αsterisk with
mISDN from experimental and it failed to build.

We'll work on it in Extremadura :-)

Regards,
Faidon



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

Bug#452596: Upgrade to 1.4.13 needs UPGRADE notes for app_voicemail changes.

[Faidon Liambotis]

Jon Webster wrote:
> When upgrading a previous version of asterisk to 1.4.13, 3 three
> voicemail modules are in the modules directory and conflict with each
> other (preventing asterisk from starting).

> After an upgrade, modules.conf must be updated to 'noload' all but the
> chosen voicemail module or else asterisk will not start.
I don't understand.

We do ship a modified modules.conf that includes those noload statements
and we do depend on the exact same version of asterisk-config.

As far as I know, the only way that would happen is if you had a
modified modules.conf and you choose to keep your version instead of
using ours (or updating yours) to the prompt.

If that's the case, we can't do anything more but add a note on
NEWS.Debian, which I will do.

Regards,
Faidon



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

Bug#452054: asterisk: Please package version 1.4.14

[Faidon Liambotis]

tags 452054 + pending
thanks

Alessandro Polverini wrote:
> Package: asterisk
> Version: 1:1.4.13~dfsg-2~etch.4751
> Severity: wishlist
This is already packaged in our SVN repository.
We won't do an upload to unstable until the one we have now gets to
testing which could take a while longer.

As for snapshots, buildserver's britney is not migrating the new
package. We'll have to look into that.

Regards,
Faidon



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

Bug#448118: overlapdial does not work with package libpri1.0, blockdial works fine. With an older version of libpri, such as 1.2, overlapdial still works.

[Faidon Liambotis]

Frank Segtrop wrote:
> This works fine with blockdial, and it works with an older version of
> libpri.
Which one?

Regards,
Faidon



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

Bug#445336: [hppa] ICE when building asterisk

[Faidon Liambotis]

Martin Michlmayr wrote:
> Upstream's initial reponse was that it's "doubtful there will be a
> quick fix for this", so I suggest you put in a workaround into your
> package to use -O1 on hppa for now.
This is already happening.

I guess we'll remove it on gcc-4.3 :-)

Thanks,
Faidon



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

Bug#447277: perl: Errno architecture does not match executable architecture

[Faidon Liambotis]

severity 447277 important
thanks

Hi,

Brent G. wrote:
> Same as my report # 443262, breaks all softawre which uses perl with same 
> error messages.
> If I remove that module, then the related software still does not run since 
> it depends on that module which isn't included in 
> perl-modules
> 
> So every time you push out a new perl package I have to manually go out, 
> fetch the tarball and reinstall since even using CPAN.pm 
> is broken.
I am not the maintainer but I did push the last upload.

I'm looking at #443262 for the first time and see that you had lots of
locally installed modules, including the one that had a problem, and you
were asked to try with the ones that Debian shipped.
You didn't answer to that though and the bug was closed.

So, again, can you check with Debian's modules and see if you can
reproduce the error?

Regards,
Faidon



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

Bug#443558: h2ph does not generate correct output for "#if defined __x86_64__"

[Faidon Liambotis]

pacakge perl
forcemerge 443785 443558 446629
tag 443785 + patch
thanks

Hi,
The patch attached by Matt Kraai for 443785 also fixed the other RC bug
(#443558) and another important bug.
Since both of the RC bugs are open for ~25 days, I have prepared an NMU.

There is an NMU policy[0] in effect since September that mandates that
this should be a 0-day NMU.

I intend to do an upload fixing these bugs tomorrow, unless the
maintainer steps up.

Regards,
Faidon

1: http://lists.debian.org/debian-devel-announce/2007/09/msg0.html



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

Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver

[Faidon Liambotis]

Robert Edmonds wrote:
> Any modification to the tg3 driver to produce a GR 2006-004 compliant
> driver would have to diverge from the kernel team's patch acceptance
> guidelines[0] since upstream is intransigent[1] on making tg3
> firmware-free or firmware-optional.  The kernel team does not appear to
> be interested in maintaining such a driver, and it appears future linux
> kernel source packages will be patched[2] to simply remove the blobs of
> firmware (I don't know why the driver isn't simply removed entirely
> since the result does not compile).
This seems totally inappropriate.

If the driver includes non-free firmwares these should be removed or
split up from the driver source, not remove the driver entirely.
If what you say is right, the driver *works* for most of the hardware
without non-free blobs.
Therefore, I can't understand how removing the driver serves our users.

Any rationale behind that decision?
I feel like I'm arguing for something completely obvious...

Regards,
Faidon



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

Bug#445866: ITP: perforce -- closed source revision control system

[Faidon Liambotis]

Daniel Jacobowitz wrote:
> On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. S?nchez wrote:
>> Given the great abundance of revision control systems already packaged
>> for Debian, what is the point of adding another?  Especially when it is
>> non-free.
> 
> How about "people use it"?  There's plenty of installations of
> perforce; I think making it easier to use Debian with them is
> within the mandate for non-free.
I'd say upload only the client to non-free.

We should provide users a way to use their existent preforce servers but
we should not encourage new installations of perforce.

Sounds like a compromise to me :)

Regards,
Faidon



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

Bug#444712: rate-engine: should this package be removed?

[Faidon Liambotis]

severity 444712 normal
reassign 444712 ftp.debian.org
retitle 444712 RM: rate-engine -- RoM; RC-buggy; abandoned upstream; not part 
of etch; low popcon
thanks

> While reviewing packages that were not included in Etch, your package
> came up as a possible candidate for removal from Debian, because:
> 
>  * 1 RC bug opened for a very long time.
>  * low popcon score (10 insts)
Lucas, thanks for doing this.

ftp-masters, please remove this package from unstable.
Additionally to what Lucas said, it is not present in lenny and
it is abandoned upstream.

Thanks,
Faidon
on behalf of the Debian VoIP packaging team, maintainer



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

Bug#445336: [hppa] ICE when building asterisk

[Faidon Liambotis]

Package: gcc-4.2
Version: 4.2.1-5
Severity: grave

As can be witnessed from the build logs on buildd.d.o[1], gcc-4.2
produces an ICE when trying to build pbx_dundi.c on hppa.

The log doesn't show the gcc arguments (upstream Makefiles have the "pretty"
build feature, disabled in our trunk). These are:

> gcc -o pbx_dundi.o -c pbx/pbx_dundi.c \
> -pthread -Iinclude  -pipe -Wall \
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations \
> -g3 -include include/asterisk/autoconfig.h -O2 -fPIC \
> -DAST_MODULE=\"pbx_dundi\"
> pbx/pbx_dundi.c: In function 'handle_command_response':
> pbx/pbx_dundi.c:1885: internal compiler error: in delete_output_reload,
> at reload1.c:7958
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> For Debian GNU/Linux specific bug reporting instructions,
> see .

The build is a bit tricky because of autoconf magic etc.
There is an extracted source that will build the file using the above
arguments on paer.debian.org:~paravoid/asterisk-1.4.11~dfsg

Unfortunately, line 1885 is a closing brace for a *HUGE* function, so it
really hard to pinpoint this further.

However, I've tried with gcc-4.1 and gcc-snapshot and they both manage to
compile without problems; may be the bug is found and fixed upstream
already.

Thanks,
Faidon

1: http://buildd.debian.org/build.php?arch=hppa&pkg=asterisk



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

Bug#444322: asterisk: Build depends on libsnmp10-dev

[Faidon Liambotis]

Hi,

Kurt Roeckx wrote:
> Your package has a build dependency on: libsnmp10-dev | libsnmp-dev
> 
> But libsnmp10-dev doesn't exists anymore.  The buildds only try the
> first alternative, so they fail.
> 
> Even apt-get build-dep doesn't seem to be working.
> 
> So, you'll need to atleast put libsnmp-dev first in the list of
> alternatives.
Thanks for your report! I will fix this ASAP.

SNMP maintainers, I would expect an announcement for this transition,
either via d-d-a or by filing bugs against all reverse deps that depend
on libsnmp10-dev.

pbuilder works fine while sbuild isn't and that why went unnoticed.

Thanks,
Faidon



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

Bug#376347: Voicetronix's vpb-driver

[Faidon Liambotis]

Hello,
I am a member of the Debian VoIP packaging team and I'm mainly
maintaining Asterisk.

While investigating an open wishlist bug report which requests chan_vpb,
your name came up: you have apparently ITPed vpb-driver and you have
actually successfully Debianized it; I was surprised to see in the
upstream tarball a complete debian/ directory written by a DD.

So, I'm contacting you seeking for cooperation. I'd very much like to
fulfill this wish that a user had and have a more complete package.
However, I don't own such a card (and neither anyone else in the team)
and this could be hard for us.

Your debian/copyright is a bit worrying: you mention non-LGPL (and
non-DFSG-free) executables present in vpb-driver.
Is that a big part? Can these be stripped and still have a functional
-even for some of the cards- driver?

I have also found that opal (maintained by the team; primarily Kilian
Krause) provides vpbapi.h -- I'm not sure why to be honest.

Would you be interested in cooperating?
Joining pkg-voip and importing your work in the SVN repository would be
the first step (uploading to Debian will be the second I guess :).
Plus, assuming that you have such a card, I would be glad to have you as
a guinea pig for Asterisk packages with chan_vpb enabled.

What do you think?

Best regards,
Faidon



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

Bug#444147: Generated images are *much* larger

[Faidon Liambotis]

Package: graphviz
Version: 2.12-4
Severity: grave

It appears that the newest graphviz in unstable creates some much
cleared images (antialiazed etc.) by the use of pango.

Unfortunately, this means that the generated images are *much* larger.
This may be not a very serious problem by itself but doxygen uses
graphviz and many packages in Debian generate their -doc packages using
doxygen.

asterisk-doc images were 13MB and with the newer graphviz this figure
gets to 112M (10 times more!). The package size gets from 28MB to 122MB.
I can't imagine what would happen on bigger software suites.
This will affect seriously all Debian mirrors!

I'm not sure what the proper solution -if any- would be and if this bug
would need to be reassigned to doxygen, but I'm filing this here since
the graphviz maintainer would know the situation better.

The severity may seem a bit inflated since there is no actual defect;
however, there is a need for a workaround or fix ASAP before this
seriously hits all mirrors.

Regards,
Faidon



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

Bug#443583: Wrong path for the dellWirelessCtl utility

[Faidon Liambotis]

Package: hal
Version: 0.5.9.1-4
Severity: normal

HAL provides a method for accessing kill switches on various hardware
(hal-system-killswitch-get-power-linux/hal-system-killswitch-set-power-linux).
For example, NetworkManager uses those methods to kill the WiFi hardware
when the user disables wireless networking.

On Dell hardware, HAL calls the dellWirelessCtl utility which handles
the switching for WiFi, Bluetooth and WWAN.

In Debian, libsmbios-bin places dellWirelessCtl in /usr/sbin, which is
correct since only root can actually turn on and off killswitches.

However, HAL calls /usr/bin/dellWirelessCtl and fails.
Besides not having a working killswitch, this results in repeated
NetworkManager errors in syslog.

Regards,
Faidon

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (600, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages hal depends on:
ii  adduser   3.105  add and remove users and groups
ii  dbus  1.1.1-3simple interprocess messaging syst
ii  hal-info  20070618-1 Hardware Abstraction Layer - fdi f
ii  libc6 2.6.1-1+b1 GNU C Library: Shared libraries
ii  libdbus-1-3   1.1.1-3simple interprocess messaging syst
ii  libdbus-glib-1-2  0.74-1 simple interprocess messaging syst
ii  libexpat1 1.95.8-4   XML parsing C library - runtime li
ii  libgcc1   1:4.2.1-4  GCC support library
ii  libglib2.0-0  2.14.0-2   The GLib library of C routines
ii  libhal-storage1   0.5.9.1-4  Hardware Abstraction Layer - share
ii  libhal1   0.5.9.1-4  Hardware Abstraction Layer - share
ii  libsmbios10.13.6-1   Provide access to (SM)BIOS informa
ii  libstdc++64.2.1-4The GNU Standard C++ Library v3
ii  libusb-0.1-4  2:0.1.12-7 userspace USB programming library
ii  libvolume-id0 0.114-2libvolume_id shared library
ii  lsb-base  3.1-24 Linux Standard Base 3.1 init scrip
ii  pciutils  1:2.2.4~pre4-1 Linux PCI Utilities
ii  udev  0.114-2/dev/ and hotplug management daemo
ii  usbutils  0.72-8 Linux USB utilities

Versions of packages hal recommends:
ii  eject 2.1.5-5ejects CDs and operates CD-Changer

-- no debconf information



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

Bug#353227: asterisk: Doesn't lock voicemail.conf for update

[Faidon Liambotis]

forwarded 353227 http://bugs.digium.com/view.php?id=10781
thanks

Hi,
On behalf of the team, sorry for the very very very late response :-)

This problem appears to be more generic since there is a
config_text_file_save() function nowdays and I have confirmed that it
doesn't use flock().
This would be a bigger problem when using e.g. asterisk-gui that tried
to write to the configuration files using the above function.

Adding the locks isn't that trivial since this means that it may block
indefinitely or fail immediately, none of which is a good thing for this
type of application.

I've forwarded the bug upstream so we can get their opinion and/or code.

Thanks,
Faidon



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

Bug#433779: asterisk doesn't work correctly after boot

[Faidon Liambotis]

Hi,
Sorry for the late response.

Hasse Hagen Johansen wrote:

> Faidon> Then send us the debug output :) Don't forget to ommit
> Faidon> sensitive information from the output.  May be something
> Faidon> is wrong with the way Asterisk registers; this will help
> Faidon> us pinpoint it.
> 
> I hope I did :-)
Thanks, this helped much.

However, Asterisk is behaving like there is no peer named 'musimi'.
Can you also send the relevant entries from your sip.conf (stripping of
course any sensitive information).

Regards,
Faidon



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

Bug#438702: Asterisk v1.4.9~dfsg-1 Crashed

[Faidon Liambotis]

forwarded 438702 http://bugs.digium.com/view.php?id=10780
thanks

Hello,
I have forwarded your bug to upstream, i.e. Digium's bug tracking
system. You can find it on the above URL.

Its status will be automatically get tracked here.

Thanks,
Faidon




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

Bug#438702: Asterisk v1.4.9~dfsg-1 Crashed

[Faidon Liambotis]

Hello,
Sorry for the late response.

GNUbie wrote:
> In addition to the previous information I sent to you regarding the
> Asterisk crash problem, below is the output of the backtrace of the core
> dump file I uploaded for you:


This backtrace is useless because you produced it without installing
asterisk-dbg first.
However, you did manage to crash asterisk with a binary package I was
able to obtain as well and I've managed to produce a useful backtrace
that we need to forward to upstream and/or fix the bug ourselves.

I don't have for either at the moment; I hope I will have the necessary
time in ~2 weeks.
In the mean time, may be someone else from the team (or not) wants to
help solve this bug.
For that reason and for reference, I'm attaching the backtraces (bt, bt
full, thread apply all bt) here.

Regards,
Faidon
Thread 10 (process 8100):
#0  0xb7f89410 in ?? ()
#1  0xbfc63388 in ?? ()
#2  0x in ?? ()
#3  0x0001 in ?? ()
#4  0xb7e83903 in poll () from /lib/tls/i686/cmov/libc.so.6
#5  0x08066b0a in monitor_sig_flags (unused=0x0) at asterisk.c:2510
#6  0x08069cdc in main (argc=8, argv=0xbfc637b4) at asterisk.c:2989

Thread 9 (process 8102):
#0  0xb7f89410 in ?? ()
#1  0xb7d88348 in ?? ()
#2  0x in ?? ()
#3  0x0001 in ?? ()
#4  0xb7e83903 in poll () from /lib/tls/i686/cmov/libc.so.6
#5  0x080667d9 in listener (unused=0x0) at asterisk.c:971
#6  0x080d5ae2 in dummy_start (data=0x814b208) at utils.c:775
#7  0xb7f72240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7e8d4ae in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 8 (process 8103):
#0  0xb7f89410 in ?? ()
#1  0xb7d4c418 in ?? ()
#2  0x0061 in ?? ()
#3  0x in ?? ()

Thread 7 (process 8104):
#0  0xb7f89410 in ?? ()
#1  0xb76d5038 in ?? ()
#2  0xb7eeeff4 in ?? () from /lib/tls/i686/cmov/libc.so.6
#3  0xb76d5024 in ?? ()
#4  0xb7e4fac6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7e4f8eb in sleep () from /lib/tls/i686/cmov/libc.so.6
#6  0xb76d7f34 in scan_thread (unused=0x0) at pbx_spool.c:458
#7  0x080d5ae2 in dummy_start (data=0x81556b0) at utils.c:775
#8  0xb7f72240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#9  0xb7e8d4ae in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 6 (process 8105):
#0  0xb7f89410 in ?? ()
#1  0xb7408418 in ?? ()
#2  0xb740830c in ?? ()
#3  0xb740838c in ?? ()
#4  0xb7e86141 in select () from /lib/tls/i686/cmov/libc.so.6
#5  0xb75137ce in sound_thread (unused=0x0) at 
/build/asterisk-1.4.11~dfsg/include/asterisk/channel.h:1320
#6  0x080d5ae2 in dummy_start (data=0x81746a0) at utils.c:775
#7  0xb7f72240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7e8d4ae in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 5 (process 8106):
#0  0xb7f89410 in ?? ()
#1  0xb71b3418 in ?? ()
#2  0x in ?? ()

Thread 4 (process 8107):
#0  0xb7f89410 in ?? ()
#1  0xb704ff98 in ?? ()
#2  0x03e8 in ?? ()
#3  0x0002 in ?? ()
#4  0xb7e83903 in poll () from /lib/tls/i686/cmov/libc.so.6
#5  0xb70cadb9 in do_monitor (data=0x0) at chan_zap.c:7139
#6  0x080d5ae2 in dummy_start (data=0x81d0d18) at utils.c:775
#7  0xb7f72240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7e8d4ae in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (process 8108):
#0  0xb7f89410 in ?? ()
#1  0xb6dde318 in ?? ()
#2  0x01db in ?? ()
#3  0x0001 in ?? ()
#4  0xb7e83903 in poll () from /lib/tls/i686/cmov/libc.so.6
#5  0x08098b7c in ast_io_wait (ioc=0x81e0748, howlong=475) at io.c:266
#6  0xb6e10fd7 in do_monitor (data=0x0) at chan_sip.c:15365
#7  0x080d5ae2 in dummy_start (data=0x81e2b58) at utils.c:775
#8  0xb7f72240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#9  0xb7e8d4ae in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (process 10946):
#0  0xb7f89410 in ?? ()
#1  0xb6da2198 in ?? ()
#2  0x in ?? ()
#3  0x0002 in ?? ()
#4  0xb7e83903 in poll () from /lib/tls/i686/cmov/libc.so.6
#5  0x08067ebe in netconsole (vconsole=0x813dde0) at asterisk.c:920
#6  0x080d5ae2 in dummy_start (data=0x81e2f18) at utils.c:775
#7  0xb7f72240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#8  0xb7e8d4ae in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (process 10950):
#0  0xb7e27709 in free () from /lib/tls/i686/cmov/libc.so.6
#1  0x080944d6 in ast_frame_free (fr=0xb7eeeff4, cache=1) at frame.c:360
#2  0xb7324bca in dial_exec_full (chan=0x81eed08, data=0xb6d63ff8, 
peerflags=0xb6d5ff24, continue_exec=0x0)
at /build/asterisk-1.4.11~dfsg/include/asterisk/frame.h:390
#3  0xb7328f2d in dial_exec (chan=0x81eed08, data=0xb6d63ff8) at app_dial.c:1728
#4  0x080aa757 in pbx_exec (c=0x81eed08, app=0x81ca1c0, data=0xb6d63ff8) at 
pbx.c:532
#5  0x080aeec3 in pbx_extension_helper (c=0x81eed08, con=, 
context=0x81eee88 "extensions", 
exten=0x81eeed8 "997155754", priority=1, label=0x0, callerid=0x81e3ce0 
"201", action=E_SPAWN) at pbx.c:1833
#6  0x080b056e in __ast_pbx_run (c=0x81eed08) at pbx.c:2388
#7

Bug#441237:

[Faidon Liambotis]

reassign 441237 asterisk-chan-capi 1.0.1-1
severity 441237 grave
retitle 441237 compiled with asterisk-dev 1.2 and segfaults with 1.4
thanks

John Hughes wrote:
> Tried recompiling asterisk-chan-capi, bug went away, something wrong
> with asterisk-chan-capi 1.0.1-1?
> 
> I guess problem is that asterisk-chan-capi is compiled against 1.2, but
> I'm using 1.4.
> 
> A versioning bug.
Is this 100% reproducable (both the crashing and the non-crashing build)?

Thanks,
Faidon



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

Bug#440187: CVE-2007-4521 remote denial of service when using IMAP voicemail storage backend

[Faidon Liambotis]

Nico Golde wrote:
> please use 
> http://lists.digium.com/pipermail/asterisk-commits/2007-August/015743.html 
> then to fix this.
I know, I've seen it but I'm not going to add the patch since
a) This is a very low security risk
b) This is not present and is not going to be present in Debian
c) There is going to be a 1.4.12 release pretty soon

Regards,
Faidon


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

Bug#419370: Asterisk security bugs

[Faidon Liambotis]

# ASA-2007-016, CVE-2007-3764
close 376767 1:1.2.13~dfsg-2etch1

# ASA-2007-011, CVE-2007-1594, CVE-2007-2297
close 419820 1:1.2.13~dfsg-2etch1
found 419820 1:1.0.7.dfsg.1-2
fixed 419820 1:1.0.7.dfsg.1-2sarge5

# CVE-2007-1306
close 419370 1:1.2.13~dfsg-2etch1
thanks

All of the known Asterisk security vulnerabilities (CVE-2007-1306,
CVE-2007-1561, CVE-2007-2294, CVE-2007-2297, CVE-2007-2488,
CVE-2007-3762, CVE-2007-3763 and CVE-2007-3764) are fixed in
1:1.2.13~dfsg-2etch1 for stable (etch), 1:1.0.7.dfsg.1-2sarge5 for
oldstable (sarge) and 1:1.4.11~dfsg.1 for unstable (sid).
Current testing (lenny) is still vulnerable, but this is the least of
its problems.
We are hoping to migrate the unstable version soon enough.

The relevant Debian Security Advisory is DSA 1358-1.

Regards,
Faidon


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

Bug#433779: asterisk doesn't work correctly after boot

[Faidon Liambotis]

Hello,
Thanks for all the information you provided, you've been very helpful.

On an unrelated matter, it saddens me that you decide to not use our
packages. Can you pinpoint us on the fixes that Danish CID wants (a bug
report on bugs.digium.com would be the best).
We have patched Asterisk for such issues in the past (UK CID in
particular), so there is precedent.

Hasse Hagen Johansen wrote:
> First this bug can now get a lower priority I think(The nameserver
> just have to be up before asterisk and that I can easely fix)
The bug you are describing in this message seems important to me, so I
won't deflate its priority, yet :)

> I am calling from a cellphone through pstn/sip gateway(musimi.dk)
> which is then talking to my local asterisk
> 
> When the nameserver is not available. The following happens:
> 
> Asterisk will retry registering. WHen my system is then fully up I can
> see that asterisk has registrated at my upstream sip provider by
> issuing "sip show registry" I then can see that asterisk have
> registrated to my upstream provider, but I still get the failure tone.
Hrm, that's weird. May be it is not registering properly?

> The problem is that when the nameserver is not available:
> 3. But I would still get a failure tone from my upstream provider, and
> my local asterisk doesn't even "see anything" from upstream like it
> does when all is working...I don't
> get anything in the console at this point. I have restart or restart
> asterisk for it to work
Could you try doing the opposite at that step?
i.e. try making an outbound call. It will probably work, even if the
registration has failed, since most SIP providers don't require you to
REGISTER before making calls (and INVITEs are authenticated).

Could you perform something a bit harder for me, please?

Shutdown your local DNS server and start Asterisk.
Type "set verbose 10" and "sip set debug" on your Asterisk console.
Wait a bit and then start your local DNS server.
Then wait until the register timers hit and Asterisk registers to your
SIP provider.

Then send us the debug output :) Don't forget to ommit sensitive
information from the output.
May be something is wrong with the way Asterisk registers; this will
help us pinpoint it.

Thanks a lot,
Faidon


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

Bug#439331: asterisk: Dynamic DUNDi peering support not implemented

[Faidon Liambotis]

severity 439331 wishlist
tag 439331 upstream
forwarded 439331 http://bugs.digium.com/view.php?id=10546
thanks

David Smith wrote:
> The sample DUNDi configuration file claims you can specify a
> peer with an EID of '*' to match any peer but this
> functionality is not implemented upstream. Please see
> upstream's bug tracker issue #10546_ , there is a patch
> attached.
> 
> I'd very much like the support to be included in the next
> Debian release.
While we occasionally include stuff that upstream isn't, I'd like to
first hear from upstream about it.

On the bug report you submitted there are comments from others regarding
this feature. I'm not sure it works or what its implications are and
personally I have zero experience with DUNDi.

I will reconsider it once it gets merged upstream.

Regards,
Faidon


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

Bug#438702: Asterisk v1.4.9~dfsg-1 Crashed

[Faidon Liambotis]

GNUbie wrote:
> So, after a few call attempts to a GSM mobile phone and PSTN telephone,
> the Asterisk service crashed and you can download the core dump file it
> generated at http://files-upload.com/files/47/core.asterisk-1.4.9 or
> at http://www.filecrunch.com/file/~jab6ay
>  .  I hope that this core dump
> file can help provide you information on what's the cause of the problem
> and a possible solution on your side.
It is hard for us to examine a core file when we don't have exactly the
same version.

It would be better if you used a binary of our own[1] and preferrably
the latest upstream version 1.4.11 (i.e. packages >= 1:1.4.11~dfsg-1)

> I would also like to add info about this crash problem that I think
> Asterisk crashes when the caller is from a SIP (soft)phone calling to a
> PSTN telephone because I remember that I've been using it calling from
> an analog phone to a PSTN telephone and vice versa but the Asterisk
> don't crash or even the channels are released properly after the call.
To a PSTN telephone through what?
zaptel? analog or ISDN? BRI or PRI? Which card exactly?

What version of zaptel are you using?
If this was an ISDN interface, what version of libpri are you using?

Please provide as much information as possible. Whatever you may think
that is important or unusual about your setup.

Unfortunately, it is working fine for me and for many others, so it is
something specific to your setup.

All in all, a proper core dump with a known version will help us most.

Thanks a lot,
Faidon

1: If you use unstable, fetch the package from the archive. If you are
using etch, add
  deb http://pkg-voip.buildserver.net/debian etch main
to your /etc/apt/sources.list and install the package from there.


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

Bug#181756: base: init does not respect multiple consoles

[Faidon Liambotis]

# help is not needed any more, a patch is attached to the BTS
tags 181756 - help
thanks

Any plans on merging this patch?
I've been hit by this bug as well and I'd like to see a solution.
I haven't tested Martin's patch yet but he seems to know what he is doing.

Martin, have you tried pushing this upstream?

Regards,
Faidon


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

Bug#439197: Build-depends libpri-dev version not specific enough

[Faidon Liambotis]

Martijn Grendelman wrote:
> One more thing: even though the build-dep is updated, the binary
> asterisk package that is built, still gets a "Depends: libpri1.0
> (>=1.4)", so one can upgrade Asterisk without upgrading libpri. I
> haven't tested this, but I imagine that this could break things.
Actually, no it wouldn't.
The binary package name was changed to libpri1.0 (from libpri1.2) in
1.4.1-1.
So, there is no libpri1.0 that could fulfill this dependency without
providing a bristuffed libpri.

> The actual problem is in the libpri package, that ships a 'shlibs' file
> with this version. Perhaps I should file a bug against libpri?
FWIW, In any other case you would be right.

Regards,
Faidon


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

Bug#439197: Build-depends libpri-dev version not specific enough

[Faidon Liambotis]

tag 439197 + confirmed pending
thanks

Martijn Grendelman wrote:
> Asterisk 1.4.11~dfsg-1 uses a patch named "use-libpri-bristuffed", that
> makes the build process depend on a version of libpri-dev that supplies
> the file "/usr/include/bristuffed/libpri.h". If this file is not
> present, the build fails.
> 
> /usr/include/bristuffed/libpri.h is present in libpri-dev 1.4.1-1 and
> up, but not in 1.4.0-2 and before.
> 
> Asterisk build-depends on libpri-dev (>= 1.4). I think this should be
> changed to (>= 1.4.1).
You're absolutely right, thanks.
Fixed in r4246, will appear in Debian in 1:1.4.11~dfsg-2.

Regards,
Faidon


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

Bug#435146: Bug#433884: Should not depend on libopenH323, libpt, libSDL, libssl, libldap, ...

[Faidon Liambotis]

close 433884 1:1.4.11~dfsg-1
thanks

Faidon Liambotis wrote:
> Unfortunately, I was wrong and I painfully discovered that this fix had
> some serious implications (namely, Asterisk was segfaulting on startup,
> #435146) and has been reverted in the pending-upload version of
> 1:1.4.10.1~dfsg-1.
> 
> This results in a lot of false dependencies on the main Asterisk
> package, but at least chan_h323.so works now.
> 
> The bug has been reopened until we find a proper solution.
I workarounded this (twice).
It is a crude hack but it works until the libopenh323 bug (#438815) gets
fixed.

FWIW, #435146 also affected chan-oh323 and my second attempt to
workaround this also covers for this.

Regards,
Faidon


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

Bug#433779: asterisk doesn't work correctly after boot

[Faidon Liambotis]

Hasse Hagen Johansen wrote:
> Hi. The problem is this. I use asterisk connecting to a remote SIP 
> provider(VoIP<->PSTN). When booting my machine asterisk starts, but 
> doesn't work correctly. I believe the remote provider cannot contact 
> my asterisk server. When I call in from outside(thorugh the remote 
> provider) I just get the failure tone
> 
> I can then restart asterisk by using the init script and then it works. 
> So I believe there is something wrong.
> 
> I have tried moving the execution of the init script later in rc.x 
> directorys using update-rc.d but that haven't helped(I thought it might 
> be because of my internet interface wasn't configured by dhcp yet)
This sounds like the registration to the SIP servers fails (because
networking isn't quite working at that point) and never attempted again.

What's the value of registertimeout and registerattempts (if existent)
on your sip.conf?

Can you paste us a "sip show registry" from the Asterisk console at the
point that the incoming calls fail?

If it is registered but the call is not coming through, could you "set
verbose 10" and try calling in and paste us the output?

Regards,
Faidon


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

Bug#386312: asterisk: deadlocks on channels

[Faidon Liambotis]

Hello,
We would appreciate it if you could check with a recent version of
asterisk (1.4), either from unstable or from pkg-voip.buildserver.net
builds.

If you do, you should probably report this to bugs.digium.com and reply
here saying so.
We could do it of course but it would be much better if you do since you
may be contacted for testing a possible fix etc.

Thanks,
Faidon


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

Bug#438817: ABI breakage between notrace and -ptrace/-develop variants

[Faidon Liambotis]

clone 438817 -1
reassign -1 pwlib 1.10.7~dfsg1-1
thanks

The same apply for pwlib of course even though this has migrated to
testing. Fortunately libpt-dev does not provide an openh323u.mak-like
makefile.

Regards,
Faidon


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

Bug#438817: ABI breakage between notrace and -ptrace/-develop variants

[Faidon Liambotis]

Source: openh323
Version: 1.18.0.dfsg-2
Severity: grave

openh323 now builds three different variants of the library: the plain,
the -ptrace one and the -develop one.

The plain version is now compiled with NOTRACE which unfortunately
changes the ABI. This is a bug by itself, since there was no SONAME bump
(and IMHO we shouldn't break the SONAME) and programs linked against the
old version of libopenh323-dev wouldn't necessarily work with the new
libopenh323-1.18.0 package

Besides that, openh323u.mak sets NOTRACE to nothing which results in
passing -DPTRACING to all source files of the program linking against
libopenh323.

Programs expect that when PTRACING is defined, the library is supporting
PTRACE and may use it to guard such function calls.

Until upstream provides a better way that does not break the ABI (e.g.
by providing stub functions), the -ptrace binary should be reinstated as
the
default one.
In case the performance benefits are big enough and upstream does not
help, we could create another package called -notrace/-server/-something
and
ship different shlibs and a modified openh323u.mak makefile in a
separate -dev
package.

I've discussed this briefly with Kilian on IRC but I'm reporting it
anyway to
the BTS with the appropriate severity so that the package won't migrate to
testing.

Regards,
Faidon


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

Bug#435146: asterisk-h323: Asterisk crashes on startup with H323 package installed.

[Faidon Liambotis]

clone 435146 -1
reassign -1 libopenh323-1.18.0 1.18.0.dfsg-1
retitle -1 Segfault when dlclose()ing libopenh323
tags -1 -pending
thanks

I've investigating this for hours and I've concluded to this:

It seems that Asterisk's dynamic loader loads modules in two passes;
modules with global symbols are loaded in the first pass while the rest
of the modules (which can use these global symbols, hence the need for
two passes) are loaded in the second.
The information of whether a module contains global symbols or not is
stored inside the module as a flag.
Hence, the dynamic loader dlopen()s libraries with RTLD_LAZY |
RTLD_LOCAL, checks the flags and:
* if it is flagged global, it continues by promoting it to RTLD_GLOBAL,
* if it is not, it calls dlclose(), pending loading in the second pass.

chan_h323 is one of those that are not flagged that way; hence it is
dlopen()ed/dlclose()d in the first pass and dlopen()ed another time in
the second.

Of course, when dlopening a shared library, all of its dependencies
(e.g. libopenh323, libpt, libSDL etc. for chan_h323.so) are dynamically
loaded too and on dlclose() they are also closed.

It seems that Asterisk segfaults on the dlclose() of chan_h323.so which
in turn is caused by unloading libopenh323.

I wrote a very simple test suite that proves this and tested it with
both 1.18 and 1.19[1]. Unfortunately the backtrace, as shown earlier in
the bug report, is quite cryptic and C++ is not my area of expertise.
It is worth noting however, that if RTLD_NOW is used instead of
RTLD_LAZY (or the environment has LD_BIND_NOW, these two are equivalent)
the bug does not occur.

This is definitely a libopenh323 bug and Asterisk workarounds it by
linking the main asterisk binary against libopenh323 and hence avoiding
unloading it when its loader dlclose()s chan_h323.so.

Regards,
Faidon

[1]:
#include 
#include 
#include 

int main(int argc, char **argv)
{
void *handle;
char *error;
char *library;

if (argc < 2) {
fprintf(stderr, "Usage: %s foo.so\n", argv[0]);
exit(EXIT_FAILURE);
}

library = argv[1];

handle = dlopen(library, RTLD_LAZY | RTLD_LOCAL);
if (!handle) {
fprintf(stderr, "%s\n", dlerror());
exit(EXIT_FAILURE);
}

dlerror();  /* Clear any existing error */

printf("loaded '%s', trying to unload...\n", library);

/* unload dynamic library */
dlclose(handle);
if ((error = dlerror()) != NULL)  {
fprintf(stderr, "%s\n", error);
exit(EXIT_FAILURE);
}
printf("unloaded '%s', exiting...\n", library);

exit(EXIT_SUCCESS);
}


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

Bug#433884: Should not depend on libopenH323, libpt, libSDL, libssl, libldap, ...

[Faidon Liambotis]

# mark it found on the pending upload
found 433884 1:1.4.10.1~dfsg-1
severity 433884 important
thanks

Faidon Liambotis wrote:
> Oh and the patch is build-tested and runtime-without-H.323 tested but I 
> don't expect any problems (ldd chan_h323.so is fine)
Unfortunately, I was wrong and I painfully discovered that this fix had
some serious implications (namely, Asterisk was segfaulting on startup,
#435146) and has been reverted in the pending-upload version of
1:1.4.10.1~dfsg-1.

This results in a lot of false dependencies on the main Asterisk
package, but at least chan_h323.so works now.

The bug has been reopened until we find a proper solution.

Regards,
Faidon


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

Bug#435521: closed by Mark Purcell <[EMAIL PROTECTED]> (Re: Asterisk SIP DOS Vulnerability)

[Faidon Liambotis]

Martin Schulze wrote:
> Faidon Liambotis wrote:
>> Granted, we have a very very bad record as maintainers of supporting
>> this security-wise but I think we can try to change that. I certainly
>> will try my best to provide you with patched versions to upload.
>> I haven't discuss this with the rest of the team yet but I think they
>> are willing of helping with this.
> 
> The main problem is that Asterisk is team maintained and nobody in
> the team (except you at the moment) seems to care about a save version
> of asterisk in stable and oldstable.  The security team itself is not
> able to support the package on its own and thus has to depend on the
> respective maintainers.
Right. FWIW, you can count on me for security updates, even if the rest
of the team doesn't change their minds wrt security fixes.

Since you have no previous grounds to trust me on this though, I'd
propose to postpone this discussion closer to the release of lenny so
you can have some hard facts regarding my (our?) responsiveness or
carelessness.

Is that acceptable to you (you being security@)?

>> I don't think that it serves our users to not provide security support
>> for asterisk, especially considering its popularity.
> 
> The question is what is better:
> 
>  . stale version of Asterisk with local and remote vulnerabilities
>in Debian stable, OR
> 
>  . no version of Asterisk in Debian stable at all
> 
> Moritz preference is the second.
If it comes to that, I definitely agree with this.

Regards,
Faidon


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

Bug#435521: closed by Mark Purcell <[EMAIL PROTECTED]> (Re: Asterisk SIP DOS Vulnerability)

[Faidon Liambotis]

[removing pkg-voip and security team members from the Cc list since they
will get the mail]

Moritz Muehlenhoff wrote:
> For Etch we need to bite the bullet and continue to support it (see my 
> previous
> mail to Faidon), but with the current strain of vulnerabilities (19 in 2007 
> alone!)
> we can't support it for Lenny again. In some cases we need to accept 
> notoriously
> error-prone packages because they are terribly important (like PHP and 
> Linux), but
> we can't do that for Asterisk.
> 
> For Lenny I see three solutions: (in order of my personal preferrence)
> 1. Move it to volatile.debian.org and support it through builds of the 
> current Digium
>maintenance release
> 2. Drop it from stable and support it out of the archive through builds of 
> the current
>Digium maintenance release
> 3. For Lenny we'll most likely have a way to flag packages not having 
> security support
>(see #436161). So, it could be included in Lenny w/o security support. 
> There might
>still be use cases, e.g. a company-wide internal PBX.
I have to say that I find all of these unacceptable.

Granted, Asterisk had some vulnerabilities recently -which IMHO is
because it's getting more attention recently- but upstream has a good
record responding to these in time with code and even their own advisories!

They even provide security updates to their old major version (1.2) at
the same time as the new one (1.4) which fits our release cycle.

The fixes are easily spotted since they do have both of their VCS and
BTS open: the commit messages refer to the advisory and the advisories
link to the bug.
In the fixes I sent you, the patches are from their repository
*completely* unchanged. They applied cleanly to our version!

Other vendors and distributions security support Asterisk, including
Ubuntu which contains versions of ours.

Granted, we have a very very bad record as maintainers of supporting
this security-wise but I think we can try to change that. I certainly
will try my best to provide you with patched versions to upload.
I haven't discuss this with the rest of the team yet but I think they
are willing of helping with this.

I don't think that it serves our users to not provide security support
for asterisk, especially considering its popularity.

Regards,
Faidon


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

Bug#437804: libpri1.0: Fails to upgrade (overwrite error) and gratuitous name change?

[Faidon Liambotis]

Raphael Hertzog wrote:
> At the very least, when you change the package name and when the SONAME
> doesn't change (thus the library file has the same name), please make sure
> that it correctly Replaces/Conflicts/Provides the previous package (with
> version ranges that match reality).
This is my fault.
I added Replaces/Conflicts for stable's version.
We have Asterisk 1.2 in testing and I thought we had libpri 1.2 as well.

Obviously, I was wrong and libpri1.2 v1.4 managed to get in and we
didn't conflict with it.

I'll fix it ASAP.

Sorry for the inconvenience,
Faidon


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

Bug#436404: ITP: asterisk-addons -- Asterisk GPL-only plugins

[Faidon Liambotis]

Package: wnpp
Severity: wishlist
Owner: Faidon Liambotis <[EMAIL PROTECTED]>

* Package name: asterisk-addons
  Version : 1.4.2
  Upstream Author : Digium Inc. (http://www.digium.com/) and others
* URL : http://www.asterisk.org/
* License : GPL
  Programming Lang: C
  Description : Asterisk GPL-only plugins

asterisk-addons is a plugin package distributed by Digium and containing
plugins that are licensed under the GPL but their authors have not
signed the
copyright disclaimer, necessary for Digium to distribute them under a
commercial license and hence not included in the main Asterisk
distribution.
They are, however, suitable for all intents and purposes for inclusion
in Debian.

This is not going to be the actual description, since this is going to
be a multi-binary package, one for each plugin.

WIP can be found on pkg-voip-maintainers subversion repository on
alioth.


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

Bug#255251: asterisk: please add apllication prepaid

[Faidon Liambotis]

notfound 255251 1.0-1
thanks

There quite a few prepaid applications and I don't think it makes sense
to have open indefinitely a wishlist bug on the asterisk package.

If you have something specific in mind, please fill a RFP bug on the
wnpp package[1] and Cc it to the Debian VoIP maintainers team[2] mailing
list so we can do something about it.

Thanks,
Faidon

1: http://www.debian.org/devel/wnpp/
2: [EMAIL PROTECTED]


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

Bug#377272: libpri1.2: SIGSEGV on zaphfc dialout

[Faidon Liambotis]

tags 377272 + unreproducible moreinfo
thanks

Hello,
I can't seem to reproduce this on my system with a zaphfc.

Can you check with the latest version of asterisk and libpri from
unstable and tell us if you're still experiencing the problem?

If you are, any more information you could supply about your setup
(zaptel.conf, zapata.conf, any strange commands in the dialpan, if this
was a call originated from another ISDN interface, which country/network
are you using, if you are using NT or TE etc.) would be helpful in our
contact with bristuff upstream.

Regards,
Faidon


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

Bug#275119: Sparc sun4u packages needed.

[Faidon Liambotis]

package asterisk
notfound 275119 1:0.9.1+1.0RC1-8
thanks

Debian is dropping support for sparc32[1] and will enable Ultrasparc
optimizations; libc6-sparcv9 is to be dropped and v9 optimizations will
get enabled on the libc6 package. The GCC 4.2 will produce v9-optimized
binaries by default.

This bug will be closed by Debian in the immediate future and there is
no reason to keep it open on Asterisk's BTS.

Since it wasn't actually fixed, I'm marking it as "not found".

Regards,
Faidon

1: http://lists.debian.org/debian-devel-announce/2007/07/msg6.html


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

Bug#427713: Bug#427724: should add interface to bridge when launching via /etc/network/interfaces

[Faidon Liambotis]

package hostapd
retitle 427713 hook script should get moved to 000madwifi
reassign 427713 madwifi-tools
thanks


In a dynamic setup that launches hostapd via /etc/network/interfaces
and wireless interfaces can be brought up and down any time,
statically configuring the bridge via /etc/network/interfaces is
obviously not possible.

Dynamic interfaces are a problem since they're generated *after* the
bridge is created, so the above won't work.

There is currently an issue that some madwifi interfaces don't exist
before the execution of their hook script and other hook scripts
(bridge-utils, hostapd) are executed before madwifi's hook script.

You're suggesting on #427713 that we should move hostapd to zz-hostapd,
as a sysvinit-style workaround for the lack of dependencies in ifupdown
hooks.

The same should apply to bridge-utils, which would solve #427724, don't
you think?

FWIW, I don't.
I think that the proper workaround would be to rename madwifi to
000madwifi, since that's where the problem lies.

Best regards,
Faidon



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

Bug#433884: Should not depend on libopenH323, libpt, libSDL, libssl, libldap, ...

[Faidon Liambotis]

Tzafrir Cohen wrote:

--- asterisk-1.4.8~dfsg.orig/main/Makefile
+++ asterisk-1.4.8~dfsg/main/Makefile
@@ -120,13 +120,6 @@ AST_EMBED_LDFLAGS:=$(foreach dep,$(EMBED
 AST_EMBED_LIBS:=$(foreach dep,$(EMBED_LIBS),$(value $(dep)))
 OBJS:=$(sort $(OBJS))
 
-ifneq ($(wildcard ../channels/h323/Makefile.ast),)

-  include ../channels/h323/Makefile.ast
-else
-  H323LDFLAGS=
-  H323LDLIBS=
-endif
-


Why wouldn't ../channels/h323/Makefile.ast be present? Elementary,
Watson: on the first run of make we generate it and then stop 'make'.
:-(
I'm removing the whole thing because I'm removing the only users of 
H323LDFLAGS/LIBS.



 asterisk: $(OBJS) editline/libedit.a db1-ast/libdb1.a $(AST_EMBED_LDSCRIPTS)
@$(ASTTOPDIR)/build_tools/make_build_h > 
$(ASTTOPDIR)/include/asterisk/build.h.tmp
@if cmp -s $(ASTTOPDIR)/include/asterisk/build.h.tmp 
$(ASTTOPDIR)/include/asterisk/build.h ; then echo ; else \
@@ -135,7 +128,7 @@ asterisk: $(OBJS) editline/libedit.a db1
@rm -f $(ASTTOPDIR)/include/asterisk/build.h.tmp
@$(CC) -c -o buildinfo.o $(ASTCFLAGS) buildinfo.c
$(ECHO_PREFIX) echo "   [LD] $^ -> $@"
-   $(CMD_PREFIX) $(CXX) $(STATIC_BUILD) -o $@ $(ASTLINK) 
$(AST_EMBED_LDFLAGS) $(ASTLDFLAGS) $(H323LDFLAGS) $^ buildinfo.o $(AST_LIBS) 
$(AST_EMBED_LIBS) $(H323LDLIBS)
+   $(CMD_PREFIX) $(CC) $(STATIC_BUILD) -o $@ $(ASTLINK) 
$(AST_EMBED_LDFLAGS) $(ASTLDFLAGS) $^ buildinfo.o $(AST_LIBS) $(AST_EMBED_LIBS)
@$(ASTTOPDIR)/build_tools/strip_nonapi $@
 
 clean::


I haven't tried it. But at first glance it seems as if this will breake
building chan_h323, right?

No. That's building main/asterisk.
chan_h323.so is getting built by channels/h323/Makefile which has the 
appropriate compiler/linker arguments.


As for your other mail, I'm not very familiar with the situation wrt the 
embedded modules, but it looks like this should go to AST_EMBED_LIBS.


Not that it matters for us, anyway.

Oh and the patch is build-tested and runtime-without-H.323 tested but I 
don't expect any problems (ldd chan_h323.so is fine)


Regards,
Faidon


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

Bug#433884: Should not depend on libopenH323, libpt, libSDL, libssl, libldap, ...

[Faidon Liambotis]

Turns out that H323LDFLAGS/H323LDLIBS are only included in main/Makefile 
because of this.

Second version of the patch that removes the craft.
--- asterisk-1.4.8~dfsg.orig/main/Makefile
+++ asterisk-1.4.8~dfsg/main/Makefile
@@ -120,13 +120,6 @@ AST_EMBED_LDFLAGS:=$(foreach dep,$(EMBED
 AST_EMBED_LIBS:=$(foreach dep,$(EMBED_LIBS),$(value $(dep)))
 OBJS:=$(sort $(OBJS))
 
-ifneq ($(wildcard ../channels/h323/Makefile.ast),)
-  include ../channels/h323/Makefile.ast
-else
-  H323LDFLAGS=
-  H323LDLIBS=
-endif
-
 asterisk: $(OBJS) editline/libedit.a db1-ast/libdb1.a $(AST_EMBED_LDSCRIPTS)
@$(ASTTOPDIR)/build_tools/make_build_h > 
$(ASTTOPDIR)/include/asterisk/build.h.tmp
@if cmp -s $(ASTTOPDIR)/include/asterisk/build.h.tmp 
$(ASTTOPDIR)/include/asterisk/build.h ; then echo ; else \
@@ -135,7 +128,7 @@ asterisk: $(OBJS) editline/libedit.a db1
@rm -f $(ASTTOPDIR)/include/asterisk/build.h.tmp
@$(CC) -c -o buildinfo.o $(ASTCFLAGS) buildinfo.c
$(ECHO_PREFIX) echo "   [LD] $^ -> $@"
-   $(CMD_PREFIX) $(CXX) $(STATIC_BUILD) -o $@ $(ASTLINK) 
$(AST_EMBED_LDFLAGS) $(ASTLDFLAGS) $(H323LDFLAGS) $^ buildinfo.o $(AST_LIBS) 
$(AST_EMBED_LIBS) $(H323LDLIBS)
+   $(CMD_PREFIX) $(CC) $(STATIC_BUILD) -o $@ $(ASTLINK) 
$(AST_EMBED_LDFLAGS) $(ASTLDFLAGS) $^ buildinfo.o $(AST_LIBS) $(AST_EMBED_LIBS)
@$(ASTTOPDIR)/build_tools/strip_nonapi $@
 
 clean::

Bug#433884: Should not depend on libopenH323, libpt, libSDL, libssl, libldap, ...

[Faidon Liambotis]

Package: asterisk
Version: 1:1.4.2~dfsg-2
Severity: serious
Tags: patch

Upstream's makefile builds the "asterisk" binary with CXX and H323LBLIBS.
That is,
  -lopenh323 -lpt -lldap -llber -lldap_r -lpthread -lsasl2 -lssl -lcrypto
  -lexpat -lSDL -lresolv -ldl

I don't know why they did this -- I checked, and it was introduced in
r43281 along with many other chan_h323 changes and no useful comments.

There shouldn't be any reason to do that; only chan_h323.so needs these
libraries.

This results for the following added dependencies for the asterisk package:
  libopenh323-1.18.0 libpt-1.10.0 libldap2 libsasl2-2, libexpat1,
  libsdl1.2debian

The attached patch fixes this bug.

This bug is present in at least the 2 recent versions of Asterisk, and
since I have no indication from the changelog that it was ever fixed in
Debian, I'm marking it found for the earliest version of 1.4 I could
find in the changelog.
I think britney is using version tracking nowdays so this will hopefully
allow the security fix in lenny.

Regards,
Faidon
--- asterisk-1.4.8~dfsg+bristuff.orig/main/Makefile
+++ asterisk-1.4.8~dfsg+bristuff/main/Makefile
@@ -135,7 +135,7 @@ asterisk: $(OBJS) editline/libedit.a db1
@rm -f $(ASTTOPDIR)/include/asterisk/build.h.tmp
@$(CC) -c -o buildinfo.o $(ASTCFLAGS) buildinfo.c
$(ECHO_PREFIX) echo "   [LD] $^ -> $@"
-   $(CMD_PREFIX) $(CXX) $(STATIC_BUILD) -o $@ $(ASTLINK) 
$(AST_EMBED_LDFLAGS) $(ASTLDFLAGS) $(H323LDFLAGS) $^ buildinfo.o $(AST_LIBS) 
$(AST_EMBED_LIBS) $(H323LDLIBS)
+   $(CMD_PREFIX) $(CC) $(STATIC_BUILD) -o $@ $(ASTLINK) 
$(AST_EMBED_LDFLAGS) $(ASTLDFLAGS) $^ buildinfo.o $(AST_LIBS) $(AST_EMBED_LIBS)
@$(ASTTOPDIR)/build_tools/strip_nonapi $@
 
 clean::

Bug#430622: ITP: dbeacon -- Multicast Beacon

[Faidon Liambotis]

Package: wnpp
Severity: wishlist
Owner: Faidon Liambotis <[EMAIL PROTECTED]>

* Package name: dbeacon
  Version : 0.3.9
  Upstream Author : Hugo Santos <[EMAIL PROTECTED]>
* URL : http://fivebits.net/proj/dbeacon/
* License : GPLv2
  Programming Lang: C++
  Description : Multicast Beacon

dbeacon is a multicast beacon. Its main purpose is to monitor other
beacon's reachability and collect statistics such as loss, delay and
jitter between them.

dbeacon supports both IPv4 and IPv6 multicast, collecting information
using both Any Source Multicast (ASM) and Source-Specific Multicast
(SSM).

This package also includes dbeacon matrix, a Perl script to generate
beacon reachability matrices in HTML.


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

Bug#424049: Proposed solution

[Faidon Liambotis]

package libopenh323-1.18.0
tag 424049 + patch
package libpt-1.10.0
tag 424050 + patch
thanks control

[3rd mail against the same package with patches attached in a row!]

As I stated before, the major blocker in removing the conflicts between 
different versions of libpt/libopenh323 is the /usr/lib/pwlib/ (and its 
respective /usr/lib/debug one) directory, which is present in both 
libraries and is common between different versions.


Attached you will find two patches -one for each library- in which I 
attempt to resolve this by placing the pwlib plugins and H.323 codecs in


 /usr/lib/pwlib/${PWLIB_VERSION}/foo/bar
(e.g. /usr/lib/pwlib/1.10.2/codecs/audio)
instead of
 /usr/lib/pwlib/foo/bar

This is a bit suboptimal, because we can have the same SONAME but a 
different minor or build version which will result in tightened 
dependencies for no reason. This is not however such a big deal and it's 
certainly better than the current situation.


As always, I'm including patches for "configure" along with configure.ac 
to avoid an unnecessary build-dependency on autoconf.


Please not that the patches are only build-tested for the moment. 
Feedback is welcome!
Also please not that the patches do not include the removal of 
Conflicts/Replaces from debian/control, this has to be done by the 
maintainer(s).


Please apply. Having multiple versions of the same library installed and 
happily coexist is standard procedure in Debian and for a good reason.


Best regards,
Faidon

P.S. On a side note, the whole mess with 
LIBH323COMPAT/LIBPTCOMPAT{1,2,3} should really be resolved. Libraries 
have SONAMEs that indicate their ABI, that's all that matters.
We shouldn't care about the "build number" or the minor revision that 
didn't break the ABI and we certainly shouldn't create useless symlinks. 
Look e.g. at libpcap0.8, which has a 0.8 soname but its version is 0.9.5 
-- there was a discussion on debian-devel some time ago about this.


diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-alsa.dirs 
pwlib-1.10.2/debian/libpt-plugins-alsa.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-alsa.dirs2007-05-15 
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-alsa.dirs 1970-01-01 02:00:00.0 
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/sound/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-avc.dirs 
pwlib-1.10.2/debian/libpt-plugins-avc.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-avc.dirs 2007-05-15 
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-avc.dirs  1970-01-01 02:00:00.0 
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-dc.dirs 
pwlib-1.10.2/debian/libpt-plugins-dc.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-dc.dirs  2007-05-15 
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-dc.dirs   1970-01-01 02:00:00.0 
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-oss.dirs 
pwlib-1.10.2/debian/libpt-plugins-oss.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-oss.dirs 2007-05-15 
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-oss.dirs  1970-01-01 02:00:00.0 
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/sound/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-v4l2.dirs 
pwlib-1.10.2/debian/libpt-plugins-v4l2.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-v4l2.dirs2007-05-15 
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-v4l2.dirs 1970-01-01 02:00:00.0 
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-v4l.dirs 
pwlib-1.10.2/debian/libpt-plugins-v4l.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-v4l.dirs 2007-05-15 
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-v4l.dirs  1970-01-01 02:00:00.0 
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/rules pwlib-1.10.2/debian/rules
--- pwlib-1.10.2.orig/debian/rules  2007-05-15 17:46:23.0 +0300
+++ pwlib-1.10.2/debian/rules   2007-05-30 06:49:35.0 +0300
@@ -188,28 +188,34 @@
 
 # plugins
#libpt-plugins-v4l
+   mkdir -p 
debian/libpt-plugins-v4l/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
cp plugins/pwlib/device/videoinput/v4l_pwplugin.so \
-   debian/libpt-plugins-v4l/usr/lib/pwlib/device/videoinput/
+   
debian/libpt-plugins-v4l/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/

#libpt-plugins-v4l2
+   mkdir -p 
debian/libpt-plugins-v4l2/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
cp plugins/pwlib/device/videoinput/v4l2_pwplugin.so \
-   debian/libpt-plugins-v4l2/usr/lib/pwlib/device/videoinput/
+   
debian/libpt-plugins-v4l2/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
 
#libpt-plugins-avc
+   mkdir -p 
debian/libpt-plugins-avc/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
cp plug

Bug#426681: Should use libgsm instead of embedding a copy

[Faidon Liambotis]

Package: libopenh323-1.18.0
Version: 1.18.0.dfsg-1+b1
Severity: important
Tags: patch

Upstream has commented-out the support for system's GSM library (libgsm)
because the default library isn't compiled with WAV49.

Debian's version is however and that's why some time ago, libgsm1-dev
was added to the build-dependencies of the source package.

The patch below uncomments upstreams' code so that libgsm is used
again. I run autoconf and I'm supplying a patch for configure, besides
configure.ac to spare the extra build-dependency.

Severity important since this will result in quite a few bugfixes that
Debian's version includes and will help with any future security
vulnerabilities, if that happens.

Best regards,
Faidon

diff -Nur openh323-1.18.0.dfsg.openh323-1.18.0.dfsg.orig/plugins/configure 
openh323-1.18.0.dfsg/plugins/configure
--- openh323-1.18.0.dfsg.orig/plugins/configure 2006-10-22 15:25:38.0 
+0300
+++ openh323-1.18.0.dfsg/plugins/configure  2007-05-30 10:23:32.0 
+0300
@@ -272,7 +272,7 @@
 PACKAGE_BUGREPORT=
 
 ac_unique_file="configure.ac"
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME 
PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix 
program_transform_name bindir sbindir libexecdir datadir sysconfdir 
sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir 
build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS CXX CXXFLAGS 
LDFLAGS CPPFLAGS ac_ct_CXX EXEEXT OBJEXT CC CFLAGS ac_ct_CC CPP EGREP 
INSTALLPREFIX LIBDIR build build_cpu build_vendor build_os host host_cpu 
host_vendor host_os target target_cpu target_vendor target_os LDSO 
H323_GSMAMR_NB_FLOAT H323_EMBEDDED_GSM H323_SYSTEM_SPEEX LIBOBJS LTLIBOBJS'
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME 
PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix 
program_transform_name bindir sbindir libexecdir datadir sysconfdir 
sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir 
build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS CXX CXXFLAGS 
LDFLAGS CPPFLAGS ac_ct_CXX EXEEXT OBJEXT CC CFLAGS ac_ct_CC CPP EGREP 
INSTALLPREFIX LIBDIR build build_cpu build_vendor build_os host host_cpu 
host_vendor host_os target target_cpu target_vendor target_os LDSO 
H323_GSMAMR_NB_FLOAT H323_EMBEDDED_GSM H323_SYSTEM_GSM H323_SYSTEM_SPEEX 
LIBOBJS LTLIBOBJS'
 ac_subst_files=''
 
 # Initialize some variables set by options.
@@ -817,6 +817,7 @@
   --disable-FEATURE   do not include FEATURE (same as --enable-FEATURE=no)
   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
   --enable-embeddedgsmembed GSM codec via static linking
+  --enable-localgsm use local version of GSM library rather than 
system version
   --enable-localspeex   use local version of Speex library rather than 
system version
 
 Some influential environment variables:
@@ -3137,6 +3127,100 @@
 
 
 
+H323_SYSTEM_GSM=0
+localgsm="xxx"
+# Check whether --enable-localgsm or --disable-localgsm was given.
+if test "${enable_localgsm+set}" = set; then
+  enableval="$enable_localgsm"
+  localgsm=$enableval
+fi;
+
+if test "${localgsm}" = "yes" ; then
+  { echo "$as_me:$LINENO: Forcing use of local GSM sources" >&5
+echo "$as_me: Forcing use of local GSM sources" >&6;}
+elif test "${localgsm}" = "no" ; then
+  { echo "$as_me:$LINENO: Forcing use of system GSM library" >&5
+echo "$as_me: Forcing use of system GSM library" >&6;}
+  H323_SYSTEM_GSM=1
+else
+  echo "$as_me:$LINENO: checking for gsm_create in -lgsm" >&5
+echo $ECHO_N "checking for gsm_create in -lgsm... $ECHO_C" >&6
+if test "${ac_cv_lib_gsm_gsm_create+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_check_lib_save_LIBS=$LIBS
+LIBS="-lgsm  $LIBS"
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char gsm_create ();
+int
+main ()
+{
+gsm_create ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+{ ac_try='test -z "$ac_c_werror_flag"   || test ! -s 
conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+{ ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_

Bug#426631: Should use libspeex instead of embedding a copy

[Faidon Liambotis]

Package: libopenh323-1.18.0
Version: 1.18.0.dfsg-1+b1
Severity: important
Tags: patch

Below you will find a patch that corrects the check done by configure so
that speex_audio_pwplugin.so will use libspeex instead of embeding a
copy of the Speex library.
This will result in more bugfixes and can be quite important in an event
of a security vulnerability in the Speex algorithm.

The irony is that the source build-depends on libspeex-dev, even though
it isn't used _at all_ in the binaries.
I guess we agree on the result and this is a technical bug.

Please apply.

Best regards,
Faidon

--- openh323-1.18.0.dfsg.orig/plugins/configure 2006-10-22 15:25:38.0 
+0300
+++ openh323-1.18.0.dfsg/plugins/configure  2007-05-30 09:40:37.0 
+0300
@@ -3243,7 +3243,7 @@
   printf("%s\n", header.speex_version);
 }
 C_FILE
-cc -o t t.c -lspeex > /dev/null 2>&1
+cc -o t t.c -I/usr/include/speex -lspeex > /dev/null 2>&1
 if test \! -x t ; then
   echo "$as_me:$LINENO: result: cannot determine - using library version" 
>&5
 echo "${ECHO_T}cannot determine - using library version" >&6
--- openh323-1.18.0.dfsg.orig/plugins/configure.ac  2006-10-22 
15:25:38.0 +0300
+++ openh323-1.18.0.dfsg/plugins/configure.ac   2007-05-30 09:38:51.0 
+0300
@@ -117,7 +117,7 @@
   printf("%s\n", header.speex_version);
 }
 C_FILE
-cc -o t t.c -lspeex > /dev/null 2>&1
+cc -o t t.c -I/usr/include/speex -lspeex > /dev/null 2>&1
 if test \! -x t ; then
   AC_MSG_RESULT(cannot determine - using library version)
 else


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

Bug#320105: libpt/openh323 conflict with older versions

[Faidon Liambotis]

clone 320113 -1
reassign -1 libopenh323-1.18.0
retitle -1 Shouldn't Conflict & Replace previous ABI/API versions
submitter -1 !
clone 320105 -2
reassign -2 libpt-1.10.0
retitle -2 Shouldn't Conflict & Replace previous ABI/API versions
submitter -2 !
thanks

Please don't conflict & replace with previous ABI/API versions. There is 
not a single reason to conflict with older versions.
The package names are different, the file contents are different and the 
packages can happily coexist. In fact, they _should_ be able to coexist.


There is a reason we include the SONAME in the package name and we just 
don't call them "libopenh323" and "libpt".


You've done this in the past, I reported it and you fixed it. You should 
had it keep that way :/


[on a second thought, libopenh323 includes /usr/lib/pwlib/codecs/ which 
exists in older versions too; do *not* do that, place it under a 
different, version-dependent path!]


Regards,
Faidon


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

Bug#423247: hostap-driver: should this package be removed?

[Faidon Liambotis]

severity 423247 normal
reassign 423247 ftp.debian.org
retitle 423247 RM: hostap-driver -- RoM; now included in kernel
thanks

Lucas Nussbaum wrote:

While reviewing packages that were not included in Etch, your package
came up as a possible candidate for removal from Debian, because:
 * According to #363377, hostap is now included in the kernel

Thanks for reminding me and for doing this :-)


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

Bug#415560: e2fsprogs: Please remove the WIP request from the license

[Faidon Liambotis]

Package: e2fsprogs
Version: 1.39+1.40-WIP-2006.11.14+dfsg-2
Severity: minor

COPYING and debian/copyright mention request that distributions should
not ship WIP or pre- releases. Since we are going to release etch with a
WIP version and the upstream author is the maintainer, this note is
probably obsolete.
It is debatable if this is a license requirement (in which case this
should be RC) or just a friendly request.
Nevertheless, since we're talking about the same person here, Theodore
Ts'o (which I hope isn't a split personality :-), I'm classifying this
as "minor".

Regards,
Faidon

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)

Versions of packages e2fsprogs depends on:
ii  e2fslibs 1.39+1.40-WIP-2006.11.14+dfsg-2 ext2 filesystem libraries
ii  libblkid 1.39+1.40-WIP-2006.11.14+dfsg-2 block device id library
ii  libc62.3.6.ds1-13GNU C Library: Shared libraries
ii  libcomer 1.39+1.40-WIP-2006.11.14+dfsg-2 common error description library
ii  libss2   1.39+1.40-WIP-2006.11.14+dfsg-2 command-line interface parsing lib
ii  libuuid1 1.39+1.40-WIP-2006.11.14+dfsg-2 universally unique id library

e2fsprogs recommends no packages.

-- no debconf information


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

Bug#368748: ITP: network-manager-openvpn -- OpenVPN network-manager plugin

[Faidon Liambotis]

Hi,
What is the status of this ITP?
I've successfully created a package for this and it's working fine on my
laptop. I could upload it if you're not interested anymore.
I don't have problem setting you as an Uploader btw.

Regards,
Faidon


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

Bug#397619: libcfitsio2: wrong byteswap on arm and mipsel architectures

[Faidon Liambotis]

It turns that my cfitsio2.diff was broken on MIPS.
The attached one is a new revision which is compile and runtime tested
on a MIPSEL machine (vaughan).
I'm not going to test this on MIPS B-E or ARM because it's trivial
enough that doesn't warrant the trouble of installing the
build-dependencies on the porter machines. It was time-consuming enough
to test on MIPSEL...
I also found out that checking for __ARMEL__ should be enough to
separate the big-endian from the little-endian ARM.
(Although I'd prefer checking for __BYTE_ORDER ==
__LITTLE_ENDIAN/__BIG_ENDIAN...)

I will NMU these bugs if the maintainer doesn't respond in a week.

Regards,
Faidon
--- fitsio2.h   2006-11-11 00:46:44.0 +0200
+++ fitsio2.h   2006-11-11 04:24:00.0 +0200
@@ -52,6 +52,12 @@
 
 /* the following block determines the size of longs on SGI IRIX machines */
 #if defined(_MIPS_SZLONG)
+#  define MACHINE NATIVE
+#  if defined(MIPSEL)
+#define BYTESWAPPED TRUE
+#  elif
+#define BYTESWAPPED FALSE
+#  endif
 #  if _MIPS_SZLONG == 32
 #define LONGSIZE 32
 #  elif _MIPS_SZLONG == 64
@@ -59,9 +65,8 @@
 #  else
 #error "can't handle long size given by _MIPS_SZLONG"
 #  endif
-#endif
 
-#if defined(vax) && defined(VMS)
+#elif defined(vax) && defined(VMS)
  
 #define MACHINE VAXVMS
 #define BYTESWAPPED TRUE
@@ -132,6 +137,12 @@
 #define MACHINE PC64BIT
 #define LONGSIZE 64   
 
+#elif defined(__arm__)
+
+/*  ARM Little-endian */
+#define MACHINE NATIVE
+#define BYTESWAPPED TRUE
+ 
 #else
 
 /*  assume machine uses the same IEEE formats as used in FITS files */

Bug#397619: libcfitsio2: wrong byteswap on arm and mipsel architectures

[Faidon Liambotis]

Attached are two separate patches: one for cfitsio 2.510-1 and one for
cfitsio3 3.006-1.1.
The previous approach that was applied to cfitsio3 (and only that) had
two problems; the first one, regarding MIPSEL, was that it was handled
in an "elif" case, while MIPS was already handled in a previous
condition. The second one, regarding ARM, was that it was checking for
"defined(arm)" instead of "defined(__arm__)".

The patches fix both of these issues. However, they make the assumption
that ARM is always Little-Endian which is not true. arm big-endian is
not currently an official Debian port though, which makes the issue non-RC.

The patches are neither compile tested or runtime tested.
I'm currently trying to test them on vaughan, one of Debian's mipsel
development machine which has the necessary build dependencies (unlike
casals (mips) and leisner (arm) which lack them). The machine's speed
doesn't help though :-(

Dr. Pence, I would suggest to use endian.h and __BYTE_ORDER to check for
 endianness instead of hard-coding each variant of every architecture in
the world. This would help avoid current and future problems.

Regards,
Faidon
--- fitsio2.h   2006-11-11 00:43:42.0 +0200
+++ fitsio2.h   2006-11-11 00:51:02.0 +0200
@@ -79,7 +79,11 @@
 
 #elif defined(_MIPS_SZLONG)
 
-#define BYTESWAPPED FALSE
+#if defined(MIPSEL)
+#  define BYTESWAPPED TRUE
+#elif
+#  define BYTESWAPPED FALSE
+#endif
 #  if _MIPS_SZLONG == 32
 #define LONGSIZE 32
 #  elif _MIPS_SZLONG == 64
@@ -125,13 +129,18 @@
  
 #elif defined(__i386) || defined(__i386__) || defined(__i486__) || 
defined(__i586__) \
   || defined(_MSC_VER) || defined(__BORLANDC__) || defined(__TURBOC__) \
-  || defined(_NI_mswin_) || defined(__EMX__) \
-  || defined(MIPSEL) || defined(arm)
+  || defined(_NI_mswin_) || defined(__EMX__)
 
 /*  generic 32-bit IBM PC */
 #define MACHINE IBMPC
 #define BYTESWAPPED TRUE
 
+#elif defined(__arm__)
+
+/*  ARM Little-endian */
+#define MACHINE NATIVE
+#define BYTESWAPPED TRUE
+
 #else
 
 /* == 
*/
--- fitsio2.h   2006-11-11 00:46:44.0 +0200
+++ fitsio2.h   2006-11-11 00:49:38.0 +0200
@@ -52,6 +52,11 @@
 
 /* the following block determines the size of longs on SGI IRIX machines */
 #if defined(_MIPS_SZLONG)
+#  if defined(MIPSEL)
+#define BYTESWAPPED TRUE
+#  elif
+#define BYTESWAPPED FALSE
+#  endif
 #  if _MIPS_SZLONG == 32
 #define LONGSIZE 32
 #  elif _MIPS_SZLONG == 64
@@ -132,6 +137,12 @@
 #define MACHINE PC64BIT
 #define LONGSIZE 64   
 
+#elif defined(__arm__)
+
+/*  ARM Little-endian */
+#define MACHINE NATIVE
+#define BYTESWAPPED TRUE
+ 
 #else
 
 /*  assume machine uses the same IEEE formats as used in FITS files */

Bug#363377: Raise severity

[Faidon Liambotis]

retitle 363377 Inform users that HostAP is merged in recent kernels
thanks control

Hi,
Moritz Muehlenhoff wrote:
> Etch will only ship a 2.6.18 kernel, please update have it.
This bug isn't actually a FTBFS, since hostap-source isn't needed in
recent kernels. The driver was merged in mainline 2.6.14 and the package
exists to serve users of older kernels.

It definitely should be kept out of testing (CCing release team) and it
should be noted (in the package description and in the build log) that
users don't have to build the modules anymore.

Release team, could you add a hint so we don't have to keep this bug
open to keep the package out of testing?

Regards,
Faidon


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

Bug#393443: Please use /usr/sbin instead of /usr/bin for utilities meant to be used by root

[Faidon Liambotis]

Package: libsmbios-bin
Version: 0.12.1-1
Severity: serious

Several of the utilities that this package provides are meant to be run by
root and spawn an error when invoked by an unprivileged user.
Please move those utilities to /usr/sbin, as mandated by FHS.

Regards,
Faidon

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages libsmbios-bin depends on:
ii  libc6  2.3.6.ds1-6   GNU C Library: Shared libraries
ii  libgcc11:4.1.1-16GCC support library
ii  libsmbios1 0.12.1-1  Provide access to (SM)BIOS informa
ii  libsmbiosxml1  0.12.1-1  Provide XML access to (SM)BIOS inf
ii  libstdc++6 4.1.1-16  The GNU Standard C++ Library v3
ii  libxml22.6.26.dfsg-4 GNOME XML library

libsmbios-bin recommends no packages.

-- no debconf information


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

Bug#382465: FTBFS on arm, sparc, ia64, hppa

[Faidon Liambotis]

Package: tla
Version: 1.3.5+dfsg-2
Severity: serious
Justification: no longer builds from source

tla 1.3.5+dfsg-2 fails to build from source on arm, sparc, ia64 and
hppa[1].
The error presented on all but arm is:
/build/buildd/tla-1.3.5+dfsg/src/tla/tests/test-framework: line 26:
18604 Bus error   ${builddir}/../tla/tla "$@"

arm shows a "MISMATCHED ARCHIVE CHECKSUM", which I'm not sure is tla's
fault:
  expected:
 MD5: f33ff22e02ce6c757bbd5f524f6fce6e
 SHA1: 19edf794d8697ef1ce41ae58415a77e8c3570100
  got:
 MD5: f33ff22e02ce6c757bbd5f524f6fce6e
 SHA1: 0532b3b8a2b14178a45cf80d30f5d476d5e3daa0

This bug currently blocks the neon transition.

Regards,
Faidon

1: http://buildd.debian.org/build.php?arch=&pkg=tla


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

Bug#353513: ipv6 support is really important

[Faidon Liambotis]

severity 353513 important
thanks

The latest release update explicitly mentions "stateful packet filtering
for both protocols" as a release goal therefore this bug is considered
as "important".

Laurence, IPv6 connection tracking is supported for a while, it will be
a shame for Debian's next release to miss this.

Regards,
Faidon


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

Bug#359202: RM: mozilla-firefox-locale-el

[Faidon Liambotis]

clone 359202 -1 -2 -3
reopen -1 !
reopen -2 !
reopen -3 !
retitle -1 RM: mozilla-firefox-locale-el; out-of-date, unused; obsoleted
retitle -2 RM: mozilla-firefox-locale-ko; out-of-date, unused; obsoleted
retitle -3 RM: mozilla-firefox-locale-nb; out-of-date, unused; obsoleted
thanks

Hi,
Please remove the final three non-transitional mozilla-firefox-locale-*.
They are unused, RC-buggy (mozilla-firefox 1.0 has been superseded by
firefox 1.5, #348356, #374186, #348360), obsolete
(mozilla-firefox-locale-all replaces all locales).
Since they haven't been RM/RoM so far, they can be safely considered
unmaintained as well.
As a plus, because of their long-standing not-to-be-fixed RC bugs,
they've been removed from testing.
These are their last (AFAIK) of their kind and they should be killed ASAP.

Respected maintainers are CCed, just in case and for their information.

Regards,
Faidon


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

Bug#381336: Please include Perl bindings

[Faidon Liambotis]

Package: hyperestraier
Version: 1.3.5-1
Severity: wishlist
Tags: patch

Upstream provides native Perl bindings by the means of XS.
Attached is a patch that enables the building of a libestraier-perl
package.
Note that it hasn't been heavily tested but the example scripts do work.

Is there a reason why this wasn't enabled in the first place?

Regards,
Faidon
diff -u hyperestraier-1.3.5/debian/rules hyperestraier-1.3.5/debian/rules
--- hyperestraier-1.3.5/debian/rules
+++ hyperestraier-1.3.5/debian/rules
@@ -42,7 +42,7 @@
 --includedir=\$${prefix}/include/estraier \
 --libexecdir=\$${prefix}/lib/estraier
 
-BINARY_PKGS = hyperestraier libestraier8 libestraier-dev libestraier-ruby1.8
+BINARY_PKGS = hyperestraier libestraier8 libestraier-dev libestraier-ruby1.8 
libestraier-perl
 
 JAVA_UNSUPPORTED_CPUS = zhppaz zmipsz zmipselz
 JAVA_UNSUPPORTED_SYSTEMS = zgnuz zkfreebsd-gnuz zknetbsd-gnuz
@@ -62,6 +62,7 @@
--enable-regex
cd rubypure && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES)
cd rubynative && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES)
+   cd perlnative && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES)
 ifeq "$(BUILD_JAVA)" "true"
cd javapure && $(CONFIGURE_VARS) ./configure $(CONFIGURE_SWITCHES) \
--libdir=\$${prefix}/share/hyperestraier 
@@ -78,6 +79,7 @@
$(MAKE) 
$(MAKE) estseek.fcgi
cd rubynative && $(MAKE)
+   cd perlnative && $(MAKE)
 ifeq "$(BUILD_JAVA)" "true"
cd javanative && $(MAKE)
 endif
@@ -102,6 +104,7 @@
-$(MAKE) distclean
-cd rubypure && $(MAKE) distclean
-cd rubynative && $(MAKE) distclean
+   -cd perlnative && $(MAKE) distclean
-cd javapure && $(MAKE) distclean
-cd javanative && $(MAKE) distclean
 ifneq "$(wildcard /usr/share/misc/config.sub)" ""
@@ -139,6 +142,11 @@
#cd rubynative && $(MAKE) install \
#   DESTDIR=$(CURDIR)/debian/libestraier-ruby1.8 \
#   MYRBLIBDIR=$(RUBYLIBDIR)
+   cd perlnative && $(MAKE) install \
+   DESTDIR=$(CURDIR)/debian/libestraier-perl
+   rm -rf $(CURDIR)/debian/libestraier-perl/usr/share/perl5
+   pod2man --section=3 perlnative/estraier-doc.pod \
+   > 
$(CURDIR)/debian/libestraier-perl/usr/share/man/man3/Estraier.3pm
install -m 755 rubynative/estcmd.rb \
$(CURDIR)/debian/libestraier-ruby1.8/usr/bin
install -m 644 rubynative/estraier-doc.rb \
@@ -189,7 +197,7 @@
dh_strip
dh_compress 
dh_fixperms
-#  dh_perl
+   dh_perl
 #  dh_python
dh_makeshlibs
dh_installdeb
diff -u hyperestraier-1.3.5/debian/control hyperestraier-1.3.5/debian/control
--- hyperestraier-1.3.5/debian/control
+++ hyperestraier-1.3.5/debian/control
@@ -52,6 +52,15 @@
  This package provides the Ruby interface for the Node API for
  Hyper Estraier.
 
+Package: libestraier-perl
+Architecture: any
+Depends: ${shlibs:Depends}, ${perl:Depends}
+Suggests: hyperestraier
+Description: Hyper Estraier Node API Libraries for Perl
+ Hyper Estraier is a full-text search system. 
+ This package provides the Perl interface for the Node API for
+ Hyper Estraier.
+
 Package: libestraier-java
 Architecture: any
 Section: libs
--- hyperestraier-1.3.5/perlnative/Makefile.in
+++ hyperestraier-1.3.5/perlnative/Makefile.in
@@ -29,10 +29,10 @@
 PERL = @PERL@
 POD2HTML = @POD2HTML@
 CC = gcc
-INC = -I. -I../.. -I$(HOME)/include -I/usr/local/include
+INC = -I. -I.. -I../.. -I/usr/include/estraier -I/usr/include/qdbm 
 OPTIMIZE = -O3 -fomit-frame-pointer
 LD = ld
-LIBS = -L../.. -L$(HOME)/lib -L/usr/local/lib @LIBS@
+LIBS = -L.. -L../.. -L$(HOME)/lib -L/usr/local/lib -lestraier @LIBS@
 RUNENV = 
LD_LIBRARY_PATH=.:..:/lib:/usr/lib:$(HOME)/lib:/usr/local/lib:@MYRUNPATH@
 
 
@@ -60,7 +60,7 @@
 
 
 install :
-   cd src && $(RUNENV) make install
+   cd src && $(RUNENV) make install_vendor
mkdir -p $(DESTDIR)$(MYPLBINDIR)
cp -Rf $(MYPLBINS) $(DESTDIR)$(MYPLBINDIR)
@printf '\n'
--- hyperestraier-1.3.5/debian/libestraier-perl.dirs
+++ hyperestraier-1.3.5/debian/libestraier-perl.dirs
@@ -0,0 +1,3 @@
+usr/lib/perl5
+usr/share/man/man3
+usr/bin
--- hyperestraier-1.3.5/debian/libestraier-perl.examples
+++ hyperestraier-1.3.5/debian/libestraier-perl.examples
@@ -0,0 +1 @@
+perlnative/example/example*

Bug#380632: please set /etc/hostapd/hostapd.conf access mode to 600

[Faidon Liambotis]

severity 380632 important
thanks

Lennart Poettering wrote:
> Please consider setting the hostapd.conf access mode to 600 by default, 
> because it
> might contain passwords if used in WPA-PSK mode.
You're absolutely right -- I wonder why I haven't done this...
It will be fixed in the next release.

Regards,
Faidon


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

Bug#376327: hostapd: lsb compliant init script

[Faidon Liambotis]

Hi,

Kel Modderman wrote:
> Attached patch uses lsb-base init functions library to enhance the
> current hostapd init script.
> 
> A summary of changes:
>  * INIT INFO block as per LSB specs, containing description, runlevel
>and should-start service information.
>  * Don't exit on non-zero exit status, instead report daemon status to
>the user. (remove set -e and pass "$?" to an lsb init function).
>  * Limit the $PATH to those that are required.
Wow, I was planning to do that for the 0.5.4-1 release.
You saved me the trouble, thanks a lot!

Regards,
Faidon


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

Bug#372142: fuse-utils: postrm removes device

[Faidon Liambotis]

tags 372142 + patch
thanks

One-liner for reference:

--- fuse-2.5.3-old/debian/fuse-utils.postrm 2006-06-13 21:59:22.0 
+0300
+++ fuse-2.5.3/debian/fuse-utils.postrm 2006-06-13 22:15:26.0 +0300
@@ -6,7 +6,6 @@
   purge|remove)
   dpkg-statoverride --remove /usr/bin/fusermount || true
   echo "removing fuse device..."
-  cd /dev; ./MAKEDEV -d fuse
   delgroup --system fuse || true;
   ;;

I can NMU if needed.

Regards,
Faidon


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

Bug#370801: installing this package prevents using orinico silver cards

[Faidon Liambotis]

Hi,

Joey Hess wrote:
> I have an orinico silver pcmcia card, and since hostap-utils blacklists
> orinico_cs, udev won't load the module when this card is inserted. The
> orinico_cs module is the only one that supports this card. Blacklisting
> it seems broken..
You are correct, the current behavior seems broken.
The blacklist is there because orinoco_cs was loaded for Prism cards
instead of hostap cards.
I guess this is now a kernel bug, since hostap is merged in to the kernel.
I'll remove the blacklist and discuss it with upstream/Linux kernel
maintainers.

Thanks,
Faidon


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

Bug#359091: dsniff: webspy doesn't work at all

[Faidon Liambotis]

tags 359091 moreinfo
thanks control

Hi,

Jan-Benedict Glaw wrote:
> It seems the dsniff program doesn't work at all on current Debian
> unstable. I tried to debug it and first of all found out that the
> build depends are probably wrong. It seems that it is making use of
> old libnet functions that are long gone in Debian's libnet1-dev
> package...
That's probably because you saw the unpatched source.
Try running "debian/rules patch" first.

> Part #2 is the dep'y on libnids. As it seems, the TCP callback is
> _only_ called upon tcp three-way handshake, but not subsequently (when
> data has arrived.)  This way, webspy will never ever try to invoke a
> browser to show the URLs...
I'm not sure of what are you referring too. Could you give me more info?
I couldn't find a bug from a quick glimpse of the code. I'm not a user
of webspy though, so I wouldn't know though...

Regards,
Faidon


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

Bug#351910: hostapd: does not work with madwifi anymore

[Faidon Liambotis]

Hi,
Sorry for taking so long to respond to this bug report, even though I've
mailed some of you in private.
I wasn't sure of what to do and I was hoping that the -old/-ng situation
would resolve itself with the passing of time.
As madwifi upstream now recommends -ng as the stable version and
considers -old as deprecated/obsolete, I've decided to support only -ng
in hostapd by including the respective headers in the source package, as
before.
Kel, I presume that this is OK with you since you've done the same for
wpasupplicant?
I'm currently preparing an upload that supports the stable 0.9.0 madwifi
(-ng) version. I hope that is OK with everyone.

Regards,
Faidon


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

Bug#365897: seg fault error in hostapd

[Faidon Liambotis]

notfound 365897 0.3.7-2
found 365897 1:0.3.7-2
close 365897 1:0.3.7-2sarge1
close 365897 1:0.5.0-1
thanks

The bug is fixed both in stable (by version 1:0.3.7-2sarge1) and in
etch/unstable.

Regards,
Faidon


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

Bug#365897: seg fault error in hostapd

[Faidon Liambotis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,
Matteo Rosi wrote:
| Package: Hostapd
| Version: 0.3.7-2
| Severity: critical
| Tags: security, patch, sarge
|
| Description:
| An invalid value, in a field of EAPoL frame, causes a segmantation fault
| error in hostapd deamon.
|
| We found it using Stress: a software for protocol implementation testing
| and security testing, you can find it at
|
| http://lart.det.unifi.it/Members/rosi/stress
Thanks for the detailed report.

Security team, please advise and/or upload. I believe the severity is
inflated, as this is just a DoS on the program, but I'm leaving it to
you to lower it.
Attached is a patch doing exactly what Matteo said, copied from upstream
and compile tested.
The version in sid/etch (0.5.0-1) is unaffected by this issue.

Regards,
Faidon

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEWQNsVty5d8XpUzMRAo8eAJ4kO2KQyGrNq5/R61hPojr72eV8lwCeI/e4
Eb1KKoaCKxSB7zL27FvY/XM=
=T51f
-END PGP SIGNATURE-
--- hostapd-0.3.7/wpa.c~	2005-01-24 05:36:45.0 +0200
+++ hostapd-0.3.7/wpa.c		2005-12-18 01:02:03.0 +0200
@@ -1414,6 +1642,14 @@
 	key = (struct wpa_eapol_key *) (hdr + 1);
 	key_info = ntohs(key->key_info);
 	key_data_length = ntohs(key->key_data_length);
+	if (key_data_length > data_len - sizeof(*hdr) - sizeof(*key)) {
+		wpa_printf(MSG_INFO, "WPA: Invalid EAPOL-Key frame - "
+			   "key_data overflow (%d > %lu)",
+			   key_data_length,
+			   (unsigned long) (data_len - sizeof(*hdr) -
+	sizeof(*key)));
+		return;
+	}
 
 	/* FIX: verify that the EAPOL-Key frame was encrypted if pairwise keys
 	 * are set */

Bug#335124: removal of automake1.6

[Faidon Liambotis]

package isdnutils
severity 335124 grave
thanks

automake1.6 is removed from the archive therefore isdnutils FTBFS.
Because of this, I'm setting the severity to grave.
An NMU is needed/pending for this package (see #344200). I'm
coordinating with Marco d'Itri to prepare those fixes.

Regards,
Faidon


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

Bug#337267: dsniff: FTBFS with openssl 0.9.8: field 'key' has incomplete type

[Faidon Liambotis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

package dsniff
tags 337267 + pending patch
thanks

Hi,

Daniel Schepler wrote:
> gcc -Wall -g -O2 -D_BSD_SOURCE -D_BSD_SOURCE -D__BSD_SOURCE -D__FAVOR_BSD 
> -DHAVE_NET_ETHERNET_H -DDSNIFF_LIBDIR=\"/usr/share/dsniff/\" -I.  -I./missing 
>  -c ./sshcrypto.c
> ./sshcrypto.c:25: error: field 'key' has incomplete type
> ./sshcrypto.c:30: error: syntax error before 'des_key_schedule'
> ...
> ./sshcrypto.c:192: error: 'DES_ENCRYPT' undeclared (first use in this 
> function)
> ./sshcrypto.c:193: error: dereferencing pointer to incomplete type
> ./sshcrypto.c:193: error: dereferencing pointer to incomplete type
> make[1]: *** [sshcrypto.o] Error 1
> make[1]: Leaving directory `/tmp/buildd/dsniff-2.4b1'
> make: *** [build-stamp] Error 2
The bug is confirmed and is caused by OpenSSL's check-in #9888.
An upload fixing this is on the way.
Meanwhile, you can use the attached patch to fix the build failure.

Thanks,
Faidon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDalo6Vty5d8XpUzMRAuRNAJ9wH0LVP2sZE7D9jugu6jqdpv0JlgCeJVQE
72U1YePYIV8i5pOgd8kZ3Qs=
=DdIM
-END PGP SIGNATURE-
diff -Nur dsniff-2.4b1.orig/sshcrypto.c dsniff-2.4b1/sshcrypto.c
--- dsniff-2.4b1.orig/sshcrypto.c   2001-03-15 10:33:04.0 +0200
+++ dsniff-2.4b1/sshcrypto.c2005-11-03 20:23:12.0 +0200
@@ -14,6 +14,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 

Bug#333835: ctrlproxy: Eats up memory making the system unusable

[Faidon Liambotis]

upstream's SVN log shows several bugfixes, including memory leak fixes.
An update to the latest version will probably fix these problems.

Moreover, I highly doubt that memory leak bugs are justified as severity
"critical".
This looks as severity inflation to me, but I'll leave the maintainer to
judge that.

Regards,
Faidon


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

Bug#326115: need addition to hostap_cs.conf for SMC2532W-B EliteConnect Wireless Adapter

[Faidon Liambotis]

Hi,

Joey Hess wrote:
> The following entry in hostap_cs.conf makes the second card also work:
> 
> card "SMC2532W-B 200mW"
>   version "SMC", "SMC2532W-B EliteConnect Wireless Adapter", "", ""
>   manfid 0xd601, 0x0010
>   bind "hostap_cs" 
> 
> Please add this so the card will work without tweaking.
Thanks, I'll try to fix this on the next upload.

Regards,
Faidon


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

Bug#326893: hostapd: WPA-PSK does not work with recent madwifi

[Faidon Liambotis]

package hostapd
tags 326893 + pending patch
thanks

Hi,

Ivan S. Dubrov wrote:

> This helped, WPA-PSK is now working. 
> 
> So the problem seems to be in the outdated madwifi headers in the
> hostapd package. 

Thanks for the detailed bug report and the fix.
The bug will be fixed along with the new version (0.4.4), which I plan
to upload soon.

Regards,
Faidon


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

Bug#307480: zeroconf: Please make zeroconf IP address secondary

[Faidon Liambotis]

Hi,
Can you try adding "scope link" to ip address add? Also, it might be
worth it to try "label eth0:1" (for example), so one can ifconfig the
(virtual) device.

Note that I'm not a user of zeroconf - in fact I'm not familiar _at all_
with it. Just trying to help.

Regards,
Faidon



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

Bug#226299: lcap: Not all capabilities are shown

[Faidon Liambotis]

The attached patch adds the missing capabilities CAP_MKNOD and 
CAP_LEASE, which are the only missing as of 2.6.10.


Please apply.

Regards,
Faidon
diff -Nur lcap-0.0.6/README lcap-void/README
--- lcap-0.0.6/README   2001-03-06 00:53:57.0 +0200
+++ lcap-void/README2005-08-15 09:04:08.0 +0300
@@ -81,7 +81,9 @@
 24  CAP_SYS_RESOURCE (setting resource limits) --+
 25  CAP_SYS_TIME (setting system time) -+|
 26  CAP_SYS_TTY_CONFIG (tty configuration) +||
-   |||
+27  CAP_MKNOD (mknod()) --+|||
+28  CAP_LEASE (taking leases on files) --+
+ |
 kernel_cap_t  
 
 
diff -Nur lcap-0.0.6/lcap.c lcap-void/lcap.c
--- lcap-0.0.6/lcap.c   2005-08-15 09:04:31.0 +0300
+++ lcap-void/lcap.c2005-08-15 08:59:37.0 +0300
@@ -77,6 +77,8 @@
 "CAP_SYS_RESOURCE", "setting resource limits",
 "CAP_SYS_TIME", "setting system time",
 "CAP_SYS_TTY_CONFIG",   "tty configuration",
+"CAP_MKNOD","mknod()",
+"CAP_LEASE","taking leases on files",
 NULL, NULL,
 };
 

Bug#286996: /proc/sys/lids/lock_init_children: No such file or directory

[Faidon Liambotis]

The way I see it, there are two possible solutions:
a) Completely remove LIDS support by commenting out -DLIDS in the Makefile
b) Comment the (2) perrors() in lcap.c, therefore eliminating the 
warnings in non-LIDS systems.


I believe that (b) could be misleading to systems with an LIDS kernel: 
in case of a failure, they'll not be warned.
Also, LIDS is a kernel patch, missing (ofcourse) from stock Debian 
kernels - add to that that LIDS userland utilities haven't been included 
in a Debian release, ever.
Plus, anyone who can patch his kernel with LIDS can surely recompile 
lcap with this compile-time option.


Therefore, I believe that (a) is a better option but ofcourse it's the 
maintainer's call.


Regards,
Faidon



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

Bug#306196: lcap: should point to capabilities(7)

[Faidon Liambotis]

Attached is patch that removes the upstream's website reference from the 
manpage and adds a pointer to capabilities(7) - please apply.


I've searched for a new upstream website but I couldn't find any 
(although admitedly I haven't tried contacting upstream). If it is 
actually dead upstream, I suggest converting this to a native Debian 
package and taking the role of an upstream author.


Regards,
Faidon
diff -Nur lcap-0.0.6/lcap.8 lcap-void/lcap.8
--- lcap-0.0.6/lcap.8   2001-03-06 00:53:57.0 +0200
+++ lcap-void/lcap.82005-08-15 08:49:42.0 +0300
@@ -48,14 +48,9 @@
 only one \fBcapability\fR may be specified).
 .SH "REPORTING BUGS"
 Report bugs to <[EMAIL PROTECTED]>.
-.SH "SEE ALSO"
-The Linux kernel source code file
-.IP
-.B 
-/usr/include/linux/capability.h
 .SH "AUTHOR"
 spoon <[EMAIL PROTECTED]>
 .SH "COPYRIGHT"
 Copyright (C) 1999-2000 [EMAIL PROTECTED]
-.SH "WEB SITE"
-http://www.netcom.com/~spoon/lcap/
+.SH "SEE ALSO"
+.IR capabilities(7)