Ang: Re: [Wengophone-devel] Cannot run WP
Verified. Manually copying ./build/libs/3rdparty/psiidle/libpsiidle.so to /usr/local/lib/wengophone fixes this. So somethingg seems to be broken with the installation part?! --alec >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 15-11-2007 10:53 >Till: <[EMAIL PROTECTED]> >Kopia: >Ärende: Ang: Re: [Wengophone-devel] Cannot run WP > >Same situation after running cmake. I guess the problem is that >although the library is built (checked, ok) it is not >installed. I run the application from the install directory >/usr/local/... , and the lib is missing in >/usr/local/lib/wengophone after 'make install'. > >>Ursprungligt meddelande >>Från: [EMAIL PROTECTED] >>Datum: 14-11-2007 23:54 >>Till: "Alec leamas"<[EMAIL PROTECTED]> >>Kopia: >>Ärende: Re: [Wengophone-devel] Cannot run WP >> >>Alec leamas a écrit : >>> It looks like this: >>> >>> [build]$ wengophone >>> wengophone: error while loading shared libraries: >libpsiidle. >>> so: cannot open shared object file: No such file or >directory >>> [build]$ svnversion >>> 13200 >>> >>> Build problems? Am i missing something? >> >>This is a new library I included to replace our broken idle >system. It's >>in libs/3rdparty/psiidle. It should get built. Maybe you need >to run >>cmake again? >> >>Aurélien >> > > >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] Cannot run WP
Same situation after running cmake. I guess the problem is that although the library is built (checked, ok) it is not installed. I run the application from the install directory /usr/local/... , and the lib is missing in /usr/local/lib/wengophone after 'make install'. >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 14-11-2007 23:54 >Till: "Alec leamas"<[EMAIL PROTECTED]> >Kopia: >Ärende: Re: [Wengophone-devel] Cannot run WP > >Alec leamas a écrit : >> It looks like this: >> >> [build]$ wengophone >> wengophone: error while loading shared libraries: libpsiidle. >> so: cannot open shared object file: No such file or directory >> [build]$ svnversion >> 13200 >> >> Build problems? Am i missing something? > >This is a new library I included to replace our broken idle system. It's >in libs/3rdparty/psiidle. It should get built. Maybe you need to run >cmake again? > >Aurélien > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Cannot run WP
It looks like this: [build]$ wengophone wengophone: error while loading shared libraries: libpsiidle. so: cannot open shared object file: No such file or directory [build]$ svnversion 13200 Build problems? Am i missing something? --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: Ang: Re: [Wengophone-devel] Logging (revisited, long)
Ah, we got a discussion :-) Summarizing advantages: Aurelien sees the config file and the more fine grained phapi logging, Andreas the console logging and I an established design pattern. And the basic con: That this is a big change, not an incremental path. After reading Dave's article I think I understand this remark a little better. (good one, that article...) Applying the way of work described in the article in this case might be. - To make 2 (possibly 3) minor patches to current log system which will run using the same logging code. These are about printf formatting (refactoring) and creating a facade for the configuration stuff (LogConfig). - After this there would be a major patch with the new backend, but not hooked in - The final patch should just be applied to Logger.h and LogConfig.h, with a clear option (#define) to use either logging system during a transition period. That is, we have current system in place, and it could be used with a #define (not runtime switch, it's really to much work). -At some point in the future, we remove a number of #define and uses just one system... A natural way to work would be that I first commit the minor patches, and then prepares the major patch and attaches it to the #1856 for review. At this point there will also be a sketch for the third patch. The thing with working incremental is that I really need to check in, it's hard to administrate otherwise. OK? --alec [snip] >Your comments (implying that switching a back-end couldn't be split up >into smaller steps) reminded me of a JavaNet article I read some time >ago which might be useful reading for everyone: >http://today.java.net/pub/a/today/2004/04/27/smallchanges. html > >Cheers, [snip] ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] Logging (revisited, long)
Painful? Not really :-) As I said, earlier: you should not apologize for doing our job. And at the moment you are taking a code review personally, you are in deep trouble. I certainly don't :-) With this said, it's really hard for me to see an incremental path leading from today's logging system to something which works along the lines I think we need. After all, it's kind of a refactoring, and such things can't really be done in that many steps. I *have* divided this work into three steps (one completed). OTOH, the nature of this patch is "switch backend". So there will be a quite large window where we can revert this patch if need be, and use the current system instead. I think - That the discussion has shown that the advantages of the patch are significant. - That the nature of remarks below not really justifies to turn the patch down (once they are fixed). - That whatever other alternatives there was to achieve the goals of the patch, they don't exist any more (out of time!). Remark comments below Cheers! Lunch! --alec > >WengoPhone depends on owutil, not the other way. >As a consequence, the log filename should be set in main() as it was >before. Not in owutil. Path::getDefaultResourcesDir() probably needs to >go too, because it ignores the fact that the resources dir can be >changed from the WengoPhone command line. OK, could be fixed. > >In Level.h, the level strings should not be published, since they are >only used by Level.cpp and the Level class provides an "str" method to >access them if needed. Additionally, I think the strings will be created >multiple times in memory: the "static" keyword won't work since it's in >a header file, if I am not mistaken. OK, could be fixed. > >Environment variables: using OW_LOGGER_* for backends and OWLOGGER_* for >logger components is confusing. Haven't checked, is this a typo or documentation error? The actual parsing shares the same code, so they should use the same prefix. Anyway, it should not be like that. > >Why do you hardcode BINARY_NAME in /CMakeLists.txt, it used to be >automatically generated? A mistake, definitely. I still think making this accessible all over the application from top level is a good thing. Move the code from wengophone/src/presentation/qt/CMakeLists.txt to top level, or copy it to owutil/util/CMakeLists.txt? > ># Style issues > >Class members are missing the '_' prefix. > >Namespace should be OWLogger, not owLogger, to be consistent with other >namespaces. > >Indentation is a mix of tabs and spaces (especially class keywords >"public", "protected" and "private"). > >Changing the include guard from OWLOGGER_H to LOG_H is just asking for >troubles. > > Those could, and should, be fixed. BTW, is the preferred way tabs or spaces?. ># Conclusion > >Maybe it's just too big for me to analyze in one shot. I see your point, >but I would prefer a few incremental changes to this massive code dump. >That's why I would like to see this forgotten and the unused files you >committed reverted. > >A better starting point IMO would be to rework the changes you made to >phlog.h so that it integrates with the current logging API. > >I know it's painful to read and that I should have written this before. >Sorry about that. > >Aurélien > I have spent quite some time to keep the (macro) API towards the application. Note also that the patch we are discussing at this very moment does not include the phapi/PhApiWrapper interface or the phapi issues. I have postponed these to a later patch which could and should be evaluated on its own merits. As for the "backend" API, I'm very convinced of the advantages of using the now so well-known lo4j semantics, that it justifies a change. ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] Logging (revisited, long)
> >> - Using the log4j/log4cc model means that the conceptual >> model is a well established design pattern. So things >> tends to fit. This spans from the new patch actually >> implementing the large commentary in our logging >> header, to that the phapi interface fits other frame- >> works using this pattern e. g., python. It fits >> both minds and software, that is. This aspect >> is important for the phapi interface. The option >> to use log4cxx as an backend also opens up for >> whatever future logging needs that might arise. > >As I understand the Logger is C++ but phapi is C. This will a) bloat phapi and >b) will make phapi dependend on owutil. The interface is, today and also after the patch, C function pointers. The difference is that there is two functions instead of one. Phapi is not dependent on C++ or owutil in any case. > >Is it possible to set in addition a debug level? Yep, I have had a TRACE level (below DEBUG) up & running, but removed it to keep the compatibility with log4cxx. So it's a design issue... ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Logging (revisited, long)
I posted a message about logging some days ago. Basically, I've done a patch, and needs a decision on if it should be included or not. There was no remarks on my previous message, question is how to interpret this: that everybody agrees, or that no one cares ? ;-) Aurelien feels that this requires a discussion, so I make a new try... In short, the patch can be described like this: - At source level, compatible with current system. (No changes for files just logging.) - Under the hood, compatible with log4cxx, the C++ log4j implementation. - First step, including new files + some general fixup already checked in.( r13150) - Step two, replaces current Logger::getInstance() semantics with the log4j Logger::getLogger( "logger.id" ) model, + new configuration. - Step three, expands the interface between phapi and C++ to use the new log4j semantics. I've used my own patch for some time now, and I'll try to explain why I think it should be included despite the late date in the partly new light of my experiences. I'm doing this since I believe that the risk with this patch is small. However, using the the patch gives several advantages: - There is once again console logging. Before recent changes, we had debug output at the console, which just isn't acceptable. But now we have no logging at all, which is also bad. New system is typically configured with error messages in the console, this is great information when something happens. It *is* silent during normal use, though. Shipping without any console error logging is a Bad Thing IMHO. - Using the log4j/log4cc model means that the conceptual model is a well established design pattern. So things tends to fit. This spans from the new patch actually implementing the large commentary in our logging header, to that the phapi interface fits other frame- works using this pattern e. g., python. It fits both minds and software, that is. This aspect is important for the phapi interface. The option to use log4cxx as an backend also opens up for whatever future logging needs that might arise. - Configuration/documentation is just so much easier. Today's system with environment variables is not that easy to document, and we have to many environment variables anyway. The new system uses a configuration file, and to modify this is much easier for many users. It is also "self-documenting" to a degree, (see r13149). - Using the new system we can configure all phapi logging in runtime. This should make it easier to catch problems once the sw is used out there. Note that all phapi logging cannot be turned on by default, it just to much, and there is also performance aspects. Overall, the new system gives more information, and is easier to to cope with, for end users. So, this was a long essay. On logging(!). But I really think we should include it. And that it should be shipped with next version. Because better logging tools for the users reporting problems will save time. Or am I wrong? --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: [Wengophone-devel] Fix for #1813, phoneline creation problems
Seems stable for me too. Once I got message below, but I can't reproduce it. Great work! --alec (process:23118): GLib-CRITICAL **: g_source_remove: assertion `tag > 0' failed ** (process:23118): CRITICAL **: gaim_proxy_info_get_type: assertion `info != NULL' failed ** (process:23118): CRITICAL **: gaim_proxy_info_get_type: assertion `info != NULL' failed ** (process:23118): CRITICAL **: gaim_proxy_info_get_type: assertion `info != NULL' failed ** (process:23118): CRITICAL **: gaim_proxy_info_get_type: assertion `info != NULL' failed >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 09-11-2007 09:56 >Till: >Ärende: [Wengophone-devel] Fix for #1813, phoneline creation problems > >Hello, > >I just committed a fix for #1813, which is about WengoPhone failing to >create the phoneline on startup. > >I have been able to log successfully 400 times with it (login then >immediatly logout (yes, I automated this)) while I can't do it more than >10 times without it, but it's nevertheless a random bug, so I would >appreciate if you could give it a try. > >Fix is in r13176. > >Aurélien >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: Ang: Re: [Wengophone-devel] Integrating wengophone
New reply, this time also to the list. Yes, I missed the "reply- all" button ... Seems that we agree on just about everything for this task. I'll create a new enhancement right now. --alec >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 07-11-2007 09:57 >Till: "Alec leamas"<[EMAIL PROTECTED]> >Ärende: Re: Ang: Re: [Wengophone-devel] Integrating wengophone > >Alec leamas a écrit : >> I've already created an issue #1870 for the pasting things, >> this one was rather obvious. Maybe you could put your remarks >> in that issue? > >Will have a look. I am in a hurry right now :-) > >> As for the command line interface, I think it might be worth >> to wrap the current interface into something more intuitive >> along the lines i described in the doc. It shouldn't be so much >> work to decode a more reasonable interface and "convert" it to >> the current. Going this way is also to avoid being pushed to >> keep current interface forever due compatibility with clients, >> configurations etc. We don't want that, do we? > >Yes, the current interface sucks. I agree we need a new one. Something like: >--call sipAddress >--addcontact sipAddress >--chat contact >--sms contact > >> In any case, we need to document what's possible today, and >> how. Calls (yes). SMS? chat? Seems that we agree to create an >> issue also for this, but I'll wait until we agree on using a >> "new" CLI syntax (current could of course still work, but >> without documetation...) > >Agreed. > >Aurélien > >PS: You did not send this message to the list. Is it on purpose? Or did >you just miss the "reply all" button? :-) > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Logging!
Although recent imrovements, I think there is a need to enhance the logging system. Logging is kind of boring, but the importance should not be underestimated. Specifically, working the open source way with users out there doing the testing, we need better logging than we we have had. And possible than we have. I have written some lines which IMHO give some advantages compared with today's system: * No need for environment variables, uses a config file (but the support is still there) * Compatible with log4cxx, uses it if available at configuration time * Uses separate streams for console and logfile, so serious errors messages are still on console. * All compile time logging in phapi can now be configured in runtime. The question is if we should use this code. And if it should be used, if it should be incorporated into 2.2. I have tested it, there are no known errors. No changes are required in source files just logging things. My own feeling is that there are advantages using the code ( I made it!), and that those justifies the possible problems adding some lines. After all, if there is any logging problems, they will show up quickly given the usage pattern. To give end users the best possible support for providing input is a major advantage during the testing. This spans from actually seeing important error messages (not debug!) on the console, to the possibility to enable low-level phapi logging if need be without recompilation. Also, this system is considerably easier to document OTOH, I may just be plain wrong. Such things have happened. --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Integrating wengophone
May God have mercy on my soul, but I have written a document on how to integrate WP with the desktop. It's long, boiling down to three tasks So, if anyone cares to read, it's available on http://hem.bredband.net/miko22/Integrating-wengophone.pdf. And of course, any remarks are more than welcome.. Enjoy :-) --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Logging
I've been thinking about logging for some time, while doing other things. Basically, I see some issues - Far to much output for end users (isn't there a ticket about this?), so - End users are likely to miss important messages. - Developers also suffers from to much output, it's a bit hard to find what your'e looking for. - There is a need to redirect a lot of debugging macros at least in phapi to the common log sink. It should be possible to see these messages without recompilation. However, doing so today simply will create to much output. - The environment variables PH_DEBUG_LEVEL and PH_LOG_FILENAME are not supported (?) First of all. logging is important, a primary tool to find out and handle problems. It's worth some time. Secondly, I think we need to implement the specified ways to limit and route the output. And, this is the complicated thing: I think we need to implement some kind of "log source" semantics, and make it possible to say things like "I want all error and warning messages, and also the debug messages from osip". This means semantics similar to log4j or syslog. This is code enough to try to find a reasonable logging package, there are some out there (log4c?) Or?! --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Re: [Wengophone-devel] New committer
Hey, whats your objective? If it's to make this bunch of developers going to change their mind, face the fact: you have failed. It's doesn't really matter what you say at this point, unless you apologize for all the lack of netiquette you have showed in your messages.. People are angry with you, for very understandable reasons. Angry people doesn't listen, such is life. I'm one of those. So: either stop this meaningless discussion, or start a new thread (another subject line, that is) and try to start from scratch. To apologize would be a reasonable start. To respect the skills and competence of this team (don't count me, I'm just a guest) is another part. And present yourself. Who are you, what's your interest in this, what's your record? And whatever thoughts you have about who is smart or not, keep them for yourself. Nobody is interested. Or, just shut up. --alec aka "The new committer" ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Alsa driver checked in
Alsa-driver major update = I've just checked in the a new version of the alsa driver (phmedia-alsa.c). This is a quiet big rewrite which is likely to affect all use of WP on Linux. The new driver is targeted to work out of the box for the major distributions including Ubuntu, Suse and Fedora. It also has much smaller latency than the former driver, plus a number of bugfixes. OTOH, its a lot of new code, some of which non-trivial i. e., there are most likely some new bugs. Known issues --- - Aurelien has reported that the sound is similar to Mickey Mouse usin certain devices (not the default). More info required, test the driver using different devices! - Playing sounds, including the ring tones, doesn't work in many cases depending on the alsa setup. - As the previous driver, it has problems with some other clients which open the sound devices in a non-cooperative way. The symptom is no sound at all. Look in the terminal log for printouts describing problem to open the device. Use # lsof /dev/snd/* to list processes claiming the sound devices. - Voice get chunked on congested networks. You might try to increase the jitter buffer if this happens. Use the environment variable PH_JITTER_BUFFER_MS, set it to something bigger than the default value of 60 (ms). Reporting bugs -- When reporting bugs, please enclose the two following lines from the terminal log. They are written when the call is closed. (debug) 20:44:56 void phapiLogFunction(OWPL_LOG_LEVEL, const char*): In phmedia-alsa.c, line 1002:Output: (sent,rebuffered, again,soft,hard): 778880 35750 4, 2, 0 (debug) 20:44:56 void phapiLogFunction(OWPL_LOG_LEVEL, const char*): In phmedia-alsa.c, line 1014:Input: received 757120, errors(again, soft,hard) : 1, 2, 1 ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] (no subject)
I've just checked in a patch which adds support for the environment variable PH_JITTER_BUFFER_MS which makes it possible to adjust the jitter buffer. A larger jitter buffer might give better sound on bad network connections. The default value is 60. I guess this should be documented somewhere, but I don't know where. --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] WP playback buffering
Aurelien's problem w the new alsa driver has forced me to try understand not only the buffering which takes place in the alsa driver, but the complete chain from network => sound. Below me thoughts. I'm sending this to the list partly for the records, but I would of course appreciate if anybody had the time to read the thing and comment. I'm still confused, but now on a higher level ;-) For the impatient, there is a "Conclusion" in the end. Eventually, something like this doc might find it's way to some source dir or the wiki? Handling of playback seem to be the critical thing w respect to sound. Recording isn't really hard, take the samples and send them through network. But playback *is* complicated, and all the problems we have had and still have with sound are related to this. Output buffering --- --- --- | network | | jitter |->- audio-->-- | alsa hw |->- sound | |-->-- phapi -->--| buffer |driver | buffer |card --- --- --- The network delivers packets, which phapi stores in it's jitter buffer. The audio driver fetches packets from phapi:s jitter buffer and stores it in the alsa driver's hw buffer. From that point, the alsa driver takes care of moving the data to the soundcard which eventually produces the sound. The tradeoffs. == All buffering introduces delays, a k a latency. For voip applications the general idea is to minimize this latency to something like 50-150 ms. This is an overall constraint on all buffering. The audio driver should ideally move one data packet each 20 ms. Since we cant use static priorities CPU load and scheduling will prevent the audio driver from doing it's task with precise 20ms intervals. The role of the hw buffer is to buffer enough data to be able to play the stream despite these scheduling delays. If the hw buffer is to small there will be an underrun i. e., no data is available in the very moment it should be played. So simply stated it should be as small as possible, but big enough to avoid underruns. A jitter buffer of 40-60 ms seems to be an accepted best practice. The role of the jitter buffer is to buffer enough data to smoothen out the random delays and even ordering of data introduced by the network. If the jitter buffer is to small, no data will be available when the audio driver tries to fetch next packet. How to handle this situation is the audio drivers task, but it has a negative impact on sound quality Generally speaking, the jitter buffer should be as small as possible, but big enough to achieve a descent sound quality. Todays standard jitter buffer setting is 60 ms. This seems to work on some networks, whereas others seems to require more. A sidenote: Streaming audio players don't care about latency and uses jitter buffers of several seconds to create a really good sound... Current driver == This driver does not set the alsa hw buffer size explicitly. The result is a buffer size based on alsa defaults,often a setup for streaming players. In my case the hw buffer is about 500 ms. When the jitter buffer is empty, the driver just makes an empty write to the hw buffer. This means that the large hw buffer is combined with the phapi jitter buffer to a very large buffer, capable of handling large network delays but also introducing a large system latency. Also, if/when the jitter buffer becomes empty despite the large buffer, there is no logic to rebuffer. Unfortunately, current driver has no counters indicating the quality of the stream. New driver. === The new driver explicitly sets the size of the hw buffer to 60 ms. When the jitter buffer is empty, the driver immediately makes a decision to resend previous package. This means the the system doesn't use the hw buffers capacity for jitter mgmt, it relies solely on the phapi jitter buffer. This creates a much better latency 120 ms, but the limited jitter buffer seems to fail on congested networks. (Aurelien...) This driver has counters for e. g. underruns and rebuffered data. What to do? === There seem to be a basic strategic choice: to use today's system with separate jitter and hw buffers, or use the alsa hw buffer as a combined jitter and hw buffer. To use the combined buffer would create a system with a small latency (the need for an extra 40-60 ms hw buffer would disappear.) This is the way twinkle uses. Another solution is to increase the phapi jitter buffer. This is likely to work, but to the price of an quite large overall delay. A 120 ms jitter combined with a 60 ms hw buffer is not that nice, but still better than the current driver. I don't really know how ekiga and skype works, but they both uses small hw buffers, which means that they are using separate jitter buffers. In the long
Ang: Re: [Wengophone-devel] New committer
OK folks, I'm the new committer. And I'm just a little curios about the subject line for this discussion. Something I should know? ;-) --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] [PATCH] Stronger warn against gcc 4.1
Much better for me. GCC 4.2 is just not an option for Fedora at the moment :-) --alec >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 05-10-2007 15:10 >Till: >Ärende: Re: [Wengophone-devel] [PATCH] Stronger warn against gcc 4.1 > >On Friday 05 October 2007 09:43:45 Nikolay Mitev wrote: >> Aurélien Gâteau wrote: >> > Having been bit with the gcc 4.1 bugs again, I figured it would be better >> > to prevent users from building with gcc 4.1 unless they explicitly ask >> > for it. >> > >> > Attached patch does this. It prevents the user from building with gcc 4.1 >> > unless he calls cmake with "-DALLOW_GCC41=ON". Is it ok for you? >> > >> > Aurélien >> >> I thought the problem was not GCC 4.1 but a boost version < 1.33.2 >> compiled with GCC 4.1. Maybe it is best to check for that combination >> and not only for GCC 4.1. > >You are right. Here is an updated version. >- owbuild_findboost_version.diff changes FindBoost.cmake to export a new >variable, BOOST_VERSION. >- wengophone_2.2_gcc41_check.diff checks for a combination of gcc 4.1 and >Boost 1.33.1. I had to move the test to boost/CMakeLists.txt because I >couldn't get BOOST_VERSION in the root CMakeLists.txt file. > >I also changed the variable name to CHECK_BOOST_GCC_BUG. You must set it to >OFF to bypass the test. > >How does it sound? > >Aurélien >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] 2.2 and ALSA
As I see it, if there are many messages like this something is
broken. If I've understood phapi, it's using select(2) to wait
until the device is ready, and then calls
alsa_stream_read/write as appropriate. Given this, there
should be no EAGAIN at all. So I don't think we should remove
these messages until we understand what's happening, given the
risk of a busy loop.
--alec
>Ursprungligt meddelande
>Från: [EMAIL PROTECTED]
>Datum: 27-09-2007 10:02
>Till:
>Ärende: Re: [Wengophone-devel] 2.2 and ALSA
>
>On Wednesday 26 September 2007 18:40:53 Andreas Schneider
wrote:
>> Hi,
>>
>> Alec: I'm running latest 2.2 at the moment. Playing sound
works just fine
>> but as soon as I try to do a test call, I get the following
message:
>>
>> (debug) 18:04:29 void phapiLogFunction(OWPL_LOG_LEVEL,
const char*): must
>> wait: Resource temporarily unavailable
>>
>> I have no time to look at the code at the moment. I this a
message of the
>> phmedia-alsa driver? What resource is temporarily
unavilable?
>
>The code responsible for this message is the following:
>
>res = snd_pcm_readi(ADEV(as)->ain, buf, len / 2);
>if (res < 0)
>{
> if (res == -EAGAIN)
> {
owplLogDebug("must wait: %s", snd_strerror(res));
>if (snd_pcm_wait(ADEV(as)->ain, 1000) < 0)
>{
> owplLogError("snd_pcm_wait failed: %s", snd_strerror
(res));
> return 0;
>}
>continue;
> }
>
>I do not believe it's a real error, we just receive a EAGAIN
code. I suggest
>we just remove it. What do you think?
>
>Aurélien
>___
>Wengophone-devel mailing list
>Wengophone-devel@lists.openwengo.com
>http://dev.openwengo.com/mailman/listinfo/wengophone-devel
>
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] 2.2 and ALSA
As I see it, if there are plenty of these messages something is
broken. As I understand the phapi code, it's using select(2) to
wait until a device is ready and then calls
alsa_stream_read/write as appropriate. Given this, there should
be no EAGAIN at all. I dont think we should remove these
printouts before we understand what's going on, given the risk
of a busy loop.
>Ursprungligt meddelande
>Från: [EMAIL PROTECTED]
>Datum: 27-09-2007 10:02
>Till:
>Ärende: Re: [Wengophone-devel] 2.2 and ALSA
>
>On Wednesday 26 September 2007 18:40:53 Andreas Schneider
wrote:
>> Hi,
>>
>> Alec: I'm running latest 2.2 at the moment. Playing sound
works just fine
>> but as soon as I try to do a test call, I get the following
message:
>>
>> (debug) 18:04:29 void phapiLogFunction(OWPL_LOG_LEVEL,
const char*): must
>> wait: Resource temporarily unavailable
>>
>> I have no time to look at the code at the moment. I this a
message of the
>> phmedia-alsa driver? What resource is temporarily
unavilable?
>
>The code responsible for this message is the following:
>
>res = snd_pcm_readi(ADEV(as)->ain, buf, len / 2);
>if (res < 0)
>{
> if (res == -EAGAIN)
> {
owplLogDebug("must wait: %s", snd_strerror(res));
>if (snd_pcm_wait(ADEV(as)->ain, 1000) < 0)
>{
> owplLogError("snd_pcm_wait failed: %s", snd_strerror
(res));
> return 0;
>}
>continue;
> }
>
>I do not believe it's a real error, we just receive a EAGAIN
code. I suggest
>we just remove it. What do you think?
>
>Aurélien
>___
>Wengophone-devel mailing list
>Wengophone-devel@lists.openwengo.com
>http://dev.openwengo.com/mailman/listinfo/wengophone-devel
>
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: [Wengophone-devel] 2.2 and ALSA
In my case there is problems when the sound playing (alsa_sndfile.cpp) and the regular audio tries to open the same device simultaneously. It works if the device used id a virtual one (e g mixer) but not if it's a physical card. In my case, the "default" device is a physical card, hence these problems. Sooner or later we will have to unify the the things playing sounds and handling the audio the use the same open file. >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 26-09-2007 18:40 >Till: >Ärende: [Wengophone-devel] 2.2 and ALSA > >Hi, > >Alec: I'm running latest 2.2 at the moment. Playing sound works just fine but >as soon as I try to do a test call, I get the following message: > >(debug) 18:04:29 void phapiLogFunction(OWPL_LOG_LEVEL, const char*): must >wait: Resource temporarily unavailable > >I have no time to look at the code at the moment. I this a message of the >phmedia-alsa driver? What resource is temporarily unavilable? > > > -- andreas > >-- >http://www.cynapses.org/ - cybernetic synapses > > >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] JItter buffer and Alsa buffer
Looking for wisdom, I found this in the twinkle alsa driver:
// The number of periods determines the ALSA application
buffer size.
// This size must be larger than the jitter buffer.
// TODO: use some more sophisticated algorithm here: read
back the period
// size and calculate the number of periods needed
(only in the
// short latency case)?
if (buffersize <= 64) {
periods *= 8;
} else if (buffersize <= 256) {
periods *= 4;
}
Anybody out there who understands what this means? I think Dan
Sandberg mentioned a jitter buffer somewhere, but I lost his
address.
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: [Wengophone-devel] Speex Jitter Buffer
This might be related to that the current alsa driver does not limit the hardware buffer. Other drivers (Skype, Ekiga) limits this to 3-4 periods ( ~50 ms) whereas the WP ALSA drivers uses whatever defaults the card has - my case it was 32 periods or roughly 500ms. I can see the hardware buffers with cat /proc/asound/card0/pcm0p/sub0/hw_params. You should be able to do something similar. >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 23-09-2007 10:34 >Till: >Ärende: [Wengophone-devel] Speex Jitter Buffer > >I've noticed that the audio under the Speex codec has a big ( ~ 3 second >) delay, even when both ends of the conference are on the same local subnet. > >I'm guessing this is caused by a static jitter buffer. > >Would decreasing this #define fix this? > >./wifo/phapi/speex/include/speex/speex.h:#define SPEEX_GET_FRAME_SIZE 3 > >Or is this caused by something else? > >Thanks! > >-Dan > > >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] [Fwd: [opensuse-packaging] GCC 4.3 transition and fallout in your packages]
No surprise, Fedora user the same compiler, and has the same problem [snip] > >Andreas Schneider wrote: >> For your interest. Phapi will be a problem or better most of the wifo tree. > >... > >> 1) Missing includes. > >Weird - implicit function prototypes aren't a standard breach by any >means... is there a compiler flag to turn this error off? > > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] Getting rid of PortAudio support?
The mono/stereo issues is still a problem for me. It's fixed in the code which handles sounds, but not in the code handling the speech. I have some sketches under way to fix also the speech, but I don't know if I have the resources (time, skills) to convert them to usable sw. Basically, if we remove portaudio this means that we will not be able to cope with a "default" device pointing to a physical card which, at least in my case, Fedora seems to do. I'm not saying this is wrong, I see the advantages, but there are drawbacks as well. OTOH, I have never had any success using portaudio either. But I just don't like this path, because this will put WP behind at least Skype, which works "out of the box" w Fedora. Somehow I guess Ekiga is the same, since it's part of the Fedora install. All of those seems to be able to handle the Fedora setup. So what we need, is alsa drivers working out of the box for any type of "default" device. I guess this is what the former Prime Minister of Sweden described as "The policy of the only road" (One year later, the voters wanted another road, he lost the elections, resigned and went to Bosnia. Shit happens. ) I still think it the only way. --alec >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 24-09-2007 17:07 >Till: "Aurélien Gâteau"<[EMAIL PROTECTED]> >Kopia: >Ärende: Re: [Wengophone-devel] Getting rid of PortAudio support? > > >Hi, > >Aurélien Gâteau wrote: >> After a brief check, it's ok. There were some mono-stereo issues, but if I am >> not mistakenn they are fixed now that we use the plughw and dmix devices (Or >> am I wrong?) > >It'd be nice to hear from Alec before committing. > >> It builds and runs ok on my Mac, Linux and Windows boxes. If noone objects, >> I'll commit this tomorrow. > >Looks OK to me. > >Cheers, >Dave. > >-- >Dave Neary >OpenWengo Community Development Manager >Email: [EMAIL PROTECTED] >Tel: +33 9 51 13 46 45 >Mob: +33 6 28 09 73 11 >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Open tickets for 2.2
I put a vote for my own ticket #1758, "Provide packaging support". This ticket covers the missing files required by the packaging people (README, manpage etc). It's missing among the 19, perhaps by purpose, perhaps because silly me classified it as a 'task'. ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Desktop file: minor problem.
The desktop file wengophone.desktop includes s set of categories (keyed "Categories: ") which includes VideoConference. This category is not valid on neither Fedora nor Suse, and must thus be removed by the installation programs. Ergo: it just causes problems, remove it from the source file, could someone pls make the line be: Categories=Qt;Network;Telephony; If someone really needs a missing category. it's easier to add it at installation time. --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] desktop file regression
I have to do this in the install process, but I don't wont to ;- ) Maybe someone could check in a fix... sed -i 's|qtwengophone|wengophone|' wengophone.desktop ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] 2.2 nightly packages...
Yes, the web server was down for a while. Now it's there again. --alec >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 27-08-2007 11:57 >Till: "Pollock, Chase"<[EMAIL PROTECTED]>, "Alec leamas" <[EMAIL PROTECTED]> >Ärende: Re: [Wengophone-devel] 2.2 nightly packages... > > >Hi Chase, > >Ask him yourself ;) > >Cheers, >Dave. > >Pollock, Chase wrote: >> Hey >> >> I can't get the link to load for the download, I'm emailing you because >> Alec's email isn't in the email. Any ideas? :) Thanks >> >> >> Respectfully, >> >> Chase Pollock >> Research Assistant >> Information Resources Management College >> National Defense University >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Dave >> Neary >> Sent: Friday, August 24, 2007 10:57 AM >> To: Alec leamas >> Cc: wengophone-devel@lists.openwengo.com >> Subject: Re: [Wengophone-devel] 2.2 nightly packages... >> >> Thank you Alec! >> >> If you built a revision from yesterday or today, you have beaten the >> official binaries for 2.2 alpha 1 to release - congratulations! >> >> Cheers, >> Dave. >> >> Alec leamas wrote: >>> ...for for fedora 7 (32/64), opensuse 10.2 (32/64) and ubuntu are >>> available for some time at http://mumin.dnsalias.net: >>> /wengophone. >>> >>> The build env still need some time to stabilize, but the packages are >>> there. I definitely need some help with configuration flags etc in >>> order to refine the packages. But they are there! >>> >>> Enjoy, >>> >>> -- alec >>> ___ >>> Wengophone-devel mailing list >>> Wengophone-devel@lists.openwengo.com >>> http://dev.openwengo.com/mailman/listinfo/wengophone-devel >>> >> >> -- >> Dave Neary >> OpenWengo Community Development Manager >> Email: [EMAIL PROTECTED] >> Tel: +33 9 51 13 46 45 >> Mob: +33 6 28 09 73 11 >> ___ >> Wengophone-devel mailing list >> Wengophone-devel@lists.openwengo.com >> http://dev.openwengo.com/mailman/listinfo/wengophone-devel >> > >-- >Dave Neary >OpenWengo Community Development Manager >Email: [EMAIL PROTECTED] >Tel: +33 9 51 13 46 45 >Mob: +33 6 28 09 73 11 > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: Ang: Re: [Wengophone-devel] 2.2 nightly packages...
Basically, the alfa does not seem to be that stable. I've had other basic problems on Fedora/386 (no sound, crashes) both with the "official" binary version and the packaged one. I guess this is the time to file bugs and/or communicate with the developers here or on IRC. (I've filed two bugs, and a bogus one about permissions). During the weekend I've updated the build process, I now think it's using the same flags as the official build process. I've also fixed the Fedora ldconfig issue. New versions will be available every morning. Hopefully they'll become better over time. cheers, -alec >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 25-08-2007 17:37 >Till: >Ärende: Re: Ang: Re: [Wengophone-devel] 2.2 nightly packages... > > > >> Date: Saturday 25 Aug 2007 >> From: JP Renaud <[EMAIL PROTECTED]> >> > Date: Saturday 25 Aug 2007 >> > From: Alec leamas <[EMAIL PROTECTED]> >> > Thanks for trying... :-) >> > >> > Actually, what's missing is not the library (it's there), but >> > some ldconfig to do while installing. I'll fix this a s a p >> > (i. e., during the weekend). >> > >> > In the meantime, you can use '$ export >> > LD_LIBRARY_PATH=/usr/lib/wengophone' as a workaround before >> > invoking wengophone from the command line. >> >> Indeed. It's working now! > >I spoke too quickly. It does not let me login. It worked initially but now >refuses to let me in. I have deleted the .wengophone folder to no avail. > >Could that be a problem with the openwengo server? > >JP > > >> Two remarks: >> >> 1. it's in /usr/lib64 on x86_64 >> >> 2. don't overwrite LD_LIBRARY_PATH (I had other entries in there) but add >> to it: >> >> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /usr/lib64/wengophone >> >> Let me know when you want me to try again. >> >> JP >> >> > Cheers, >> > --alec >> > >> > >Ursprungligt meddelande >> > >Från: [EMAIL PROTECTED] >> > >Datum: 25-08-2007 01:11 >> > >Till: >> > >Ärende: Re: [Wengophone-devel] 2.2 nightly packages... >> > > >> > >> Date: Friday 24 Aug 2007 >> > >> From: Alec leamas <[EMAIL PROTECTED]> >> > >> ...for for fedora 7 (32/64), opensuse 10.2 (32/64) and >> > >> > ubuntu >> > >> > >> are available for some time at http://mumin.dnsalias. net: >> > >> /wengophone. >> > >> >> > >> The build env still need some time to stabilize, but the >> > >> packages are there. I definitely need some help with >> > >> configuration flags etc in order to refine the packages. >> > >> > But >> > >> > >> they are there! >> > > >> > >Thanks! >> > > >> > >I tried your package on Fedora 7 (x86_64) but it is missing >> > >> > things: >> > >$ wengophone >> > >wengophone: error while loading shared libraries: libphapi. >> > >> > so: cannot open >> > >> > >shared object file: No such file or directory >> > > >> > >Any idea where I should get libphapi.so from on Fedora 7? >> > > >> > >JP >> > > >> > >> Enjoy, >> > >> >> > >> -- alec >> > >> ___ >> > >> Wengophone-devel mailing list >> > >> Wengophone-devel@lists.openwengo.com >> > >> http://dev.openwengo.com/mailman/listinfo/wengophone- devel >> > > >> > >-- >> > >JP Renaud >> > > >> > >http://www.jprenaud.info >> > >___ >> > >Wengophone-devel mailing list >> > >Wengophone-devel@lists.openwengo.com >> > >http://dev.openwengo.com/mailman/listinfo/wengophone- devel > > > >-- >JP Renaud > >http://www.jprenaud.info >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
Ang: Re: [Wengophone-devel] 2.2 nightly packages...
Thanks for trying... :-) Actually, what's missing is not the library (it's there), but some ldconfig to do while installing. I'll fix this a s a p (i. e., during the weekend). In the meantime, you can use '$ export LD_LIBRARY_PATH=/usr/lib/wengophone' as a workaround before invoking wengophone from the command line. Cheers, --alec >Ursprungligt meddelande >Från: [EMAIL PROTECTED] >Datum: 25-08-2007 01:11 >Till: >Ärende: Re: [Wengophone-devel] 2.2 nightly packages... > > > >> Date: Friday 24 Aug 2007 >> From: Alec leamas <[EMAIL PROTECTED]> >> ...for for fedora 7 (32/64), opensuse 10.2 (32/64) and ubuntu >> are available for some time at http://mumin.dnsalias.net: >> /wengophone. >> >> The build env still need some time to stabilize, but the >> packages are there. I definitely need some help with >> configuration flags etc in order to refine the packages. But >> they are there! > >Thanks! > >I tried your package on Fedora 7 (x86_64) but it is missing things: > >$ wengophone >wengophone: error while loading shared libraries: libphapi. so: cannot open >shared object file: No such file or directory > >Any idea where I should get libphapi.so from on Fedora 7? > >JP > >> Enjoy, >> >> -- alec >> ___ >> Wengophone-devel mailing list >> Wengophone-devel@lists.openwengo.com >> http://dev.openwengo.com/mailman/listinfo/wengophone-devel > > > >-- >JP Renaud > >http://www.jprenaud.info >___ >Wengophone-devel mailing list >Wengophone-devel@lists.openwengo.com >http://dev.openwengo.com/mailman/listinfo/wengophone-devel > ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] 2.2 nightly packages...
...for for fedora 7 (32/64), opensuse 10.2 (32/64) and ubuntu are available for some time at http://mumin.dnsalias.net: /wengophone. The build env still need some time to stabilize, but the packages are there. I definitely need some help with configuration flags etc in order to refine the packages. But they are there! Enjoy, -- alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] fedora 7/64: no sound (revisited)
Some more bits & pieces related to my previous posting: Trying the daily snapshot for debian (still on Fedora 7/64) I get the following, far from identical terminal output. (long lines!): $unset PH_FORCE_AUDIO_DEVICE [EMAIL PROTECTED] WengoPhone-2.2-minsizerel]$ ./wengophone.sh (info) 14:58:52 Wenbox::Wenbox(): Wenbox dll not loaded (info) 14:58:53 void QtLanguage::loadLanguageFromConfig(): no Qt translation available for locale '' (info) 14:58:53 void QtLanguage::loadLanguageFromConfig(): no application translation available for locale '' ALSA lib control.c:910:(snd_ctl_open_noupdate) Invalid CTL hw: 0 (warn) 14:58:54 snd_mixer_t* open_mixer(const char*): failed to attach mixer to card hw:0 No such file or directory ALSA lib control.c:910:(snd_ctl_open_noupdate) Invalid CTL hw: 0 (warn) 14:58:54 snd_mixer_t* open_mixer(const char*): failed to attach mixer to card hw:0 No such file or directory [Previous message repeated several times] This output is very different from what I get for the fedora builds. Also, the GUI pops up in s small time, on Fedora I have wait a looong time before it pops up. Which raises another question: which are the build options used for the daily, alsa snapshots? Still this overall question: any clues out there? --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] fedora 7/64: no sound (revisited)
Since I don't give up that easy, I've compiled the current 2.2 head without portaudio (-DOWSOUND_PORTAUDIO_SUPPORT=OFF), with default values for the other options. Compilation and linking seems to be OK without significant error messages. However, the binary seems to be both deaf and mute. I trust my os and hw, since other applications e. g. Skype seems to be OK. My feeling for this is that this is something related to what/how alsa devices are used. In the terminal window I can see (long lines!): (debug) 14:22:51 void alsa_play_file(const char*, const char*, int*): playing /usr/share/wengophone/sounds/callclosed.wav (warn) 14:22:51 snd_pcm_t* alsa_open(const char*, int, unsigned int, int): cannot set sample format: Invalid argument (warn) 14:22:51 void alsa_play_file(const char*, const char*, int*): can't open alsa device (debug which doesn't look so good. I've tried the PH_FORCE_AUDIO_DEVICE tricks described in the wiki with no success (but some coredumps instead...) Any clues out there?! --alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Linix: portaudio link problems
I'm running into problems with the current head of 2.1 when trying to build with the libportaudio option enabled. The problems are invariably unsatisfied references to the ffmpeg av* libraries. On 32-bit suse the problems disappears if I enable the internal ffmpeg library. If I try to use the external libraries (which are installed) I get link errors in the final link step with the unsatisfied references above. On 64-bit Fedora I get the same link error when trying to use external libraries. Trying to use the internal ffmpeg I get make[2]: *** No rule to make target `.. /libs/3rdparty/ffmpeg/libavcodec/libavcodec.a', needed by `libs/owwebcam/libowwebcam.so'. I am able to build without the portaudioption. However, no sound on Fedora ;-) So I thought I should give libportaudio a chance... Is this known bugs, is it like it's intended to be, or am I just doing something stupid? Any clues out there? --Alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
[Wengophone-devel] Linux cmake build error
The build instructions for linux does not work. More specific: svn co http://dev.openwengo.org/svn/openwengo/wengophone- ng/branches/wengophone-2.1 cd build cmake -DCMAKE_BUILD_TYPE=Debug .. given a cmake error, something that cmake requires a separate build directory and that I should create one. The real problem is the file CMakeCache.txt in the root dir which svn places there. When this file is removed, cmake runs fine. IMHO either the compilation docs should be updated or, probably better, this generated file should be removed from the svn repository. --Alec ___ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
