Re: [Ekiga-devel-list] dump audio & video at real time
Hi Carlos, On Tue, Oct 09, 2007 at 03:50:26AM -0400, Carlos Hernandez wrote: > is it posible to send the video and the audio to separated file using > ekiga?, (may be opal). > > I mean, what I want is to save raw video and audio to the hard drive while a > call is established. using wireshark and the rtpplay module from OPAL samples should do the trick at least for audio, not sure it can playback video. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Useless shared linked libs in Ekiga 2.0.11
Hi Julien, On Sun, Oct 07, 2007 at 11:34:48AM +0200, Julien Puydt wrote: > Kilian Krause a écrit : > > At a first glance this is due to configure demanding these to be added > > to LDFLAGS. If someone finds the time to go through these and strip it > > down to only the required ones before me, please feel free to do so. > > Isn't it pkg-config adding them? In that case, we can hardly do anything... sadly it looks like this is a pkg-config issue of those packs. The question is whether we should work around this locally for now or just start feedking them the information.. I'll try to compile a list which of the packs does report which of those libs incorrectly. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Useless shared linked libs in Ekiga 2.0.11
Hi guys, as the new dpkg does chatter a bit more about useful and not so useful depends declared by linking libraries that in fact aren't used, I can herewith present you with the output of the latest 2.0.11 release build: full build uselessly linked with: libaudiofile.so.0 (it uses none of its symbols). libSM.so.6 (it uses none of its symbols). libICE.so.6 (it uses none of its symbols). libbonoboui-2.so.0 (it uses none of its symbols). libgnomevfs-2.so.0 (it uses none of its symbols). libgnomecanvas-2.so.0 (it uses none of its symbols). libart_lgpl_2.so.2 (it uses none of its symbols). libatk-1.0.so.0 (it uses none of its symbols). libpangocairo-1.0.so.0 (it uses none of its symbols). libfontconfig.so.1 (it uses none of its symbols). libXext.so.6 (it uses none of its symbols). libXrender.so.1 (it uses none of its symbols). libXinerama.so.1 (it uses none of its symbols). libXi.so.6 (it uses none of its symbols). libXrandr.so.2 (it uses none of its symbols). libXcursor.so.1 (it uses none of its symbols). libXcomposite.so.1 (it uses none of its symbols). libXdamage.so.1 (it uses none of its symbols). libcairo.so.2 (it uses none of its symbols). libXfixes.so.3 (it uses none of its symbols). libpopt.so.0 (it uses none of its symbols). libxml2.so.2 (it uses none of its symbols). libgmodule-2.0.so.0 (it uses none of its symbols). librt.so.1 (it uses none of its symbols). libdl.so.2 (it uses none of its symbols). libpthread.so.0 (it uses none of its symbols). libgcc_s.so.1 (it uses none of its symbols). --disable-gnome variant uselessly linked with: libatk-1.0.so.0 (it uses none of its symbols). libpangocairo-1.0.so.0 (it uses none of its symbols). libfontconfig.so.1 (it uses none of its symbols). libXext.so.6 (it uses none of its symbols). libXrender.so.1 (it uses none of its symbols). libXinerama.so.1 (it uses none of its symbols). libXi.so.6 (it uses none of its symbols). libXrandr.so.2 (it uses none of its symbols). libXcursor.so.1 (it uses none of its symbols). libXcomposite.so.1 (it uses none of its symbols). libXdamage.so.1 (it uses none of its symbols). libcairo.so.2 (it uses none of its symbols). libXfixes.so.3 (it uses none of its symbols). libgmodule-2.0.so.0 (it uses none of its symbols). librt.so.1 (it uses none of its symbols). libxml2.so.2 (it uses none of its symbols). libdl.so.2 (it uses none of its symbols). libpthread.so.0 (it uses none of its symbols). libgcc_s.so.1 (it uses none of its symbols). At a first glance this is due to configure demanding these to be added to LDFLAGS. If someone finds the time to go through these and strip it down to only the required ones before me, please feel free to do so. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] *.dll entry in Makefile
Hi Swen, On Mon, Sep 24, 2007 at 07:57:18AM +0200, Swen Walkowski wrote: > many thanks to you Kilian for your help, but > after a long night, it does not work. > So my CFLAGS and CXXFLAGS in the win32/ekiga/Makefile are: > > CFLAGS = -I/home/pfefferkeks/win32/include > -L/home/pfefferkeks/win32/lib -lVideo_Conference_AR.dll.a > -march=pentium-mmx -DPTRACING > > CXXFLAGS = -I/home/pfefferkeks/win32/include > -L/home/pfefferkeks/win32/lib -lVideo_Conference_AR.dll.a > -march=pentium-mmx -DPTRACING > > Somebody else any ideas? for the -l you won't need the .dll or .dll.a suffix.. Most probably that will even break as "lib" is auto-prefixed and *.$SHAREDLIBEXT is auto-suffixed. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] *.dll entry in Makefile
Hi Swen, On Sun, Sep 23, 2007 at 10:21:15PM +0200, Swen Walkowski wrote: > Hi Kilian, > > Kilian Krause schrieb: > > you can try tweaking the line > > $(MAKE) $(MAKEOPTS) -C $(EKIGA_DIR) > > in win32/Makefile and put CFLAGS or CXXFLAGS there. Otherwise you'll > > need to fiddle the -lVideoAR into the CFLAGS or CXXFLAGS into the ekiga > > Makefiles themselves. > > I have tried in the ekiga Makefile (win32/ekiga/Makefile): > CFLAGS = -I/home/pfefferkeks/win32/include -lVideo_Conference_AR > -march=pentium-mmx -DPTRACING > > and the same for CXXFLAGS, but with out any success. > Also I have tried to use CFLAGS and/or CXXFLAGS in the line > $(MAKE) $(MAKEOPTS) -C $(EKIGA_DIR) > > Always the same result: > videoinput.o: In function `_ZN14GMVideoGrabber4MainEv': > /home/pfefferkeks/win32/ekiga/src/devices/videoinput.cpp:125: undefined > reference to `Transport_Ekiga_AR::getInstance()' > /home/pfefferkeks/win32/ekiga/src/devices/videoinput.cpp:125: undefined > reference to `Transport_Ekiga_AR::extendImageAR(unsigned char const*, > unsigned int, unsigned int)' > > The library lies under 'win32/lib' with the name > 'libVideo_Conference_AR.dll' (I have had to change the name from > libVideoAR). Also I have tired 'libVideo_Conference_AR.dll.a' > > By the way the *.dll file is done with VS2008, is that an problem? Nope, shouldn't be a problem. You may need -L/home/pfefferkeks/win32/lib additionally to -lVideo_Conference_AR ... -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] *.dll entry in Makefile
Hi Swen, On Sun, Sep 23, 2007 at 07:40:23PM +0200, Swen Walkowski wrote: > Sorry to interrupt you again, but I need your help again. > > I have written a *.dll for my functionality witch I will try to do with > the image. That I don't have to recompile Ekiga all the time, I want to > use a library. I have done a littel change in the 'videoinput.cpp'. > > After that I have copied my libVideoAR.dll to the Linux PC, in the > folder 'win32/lib/'. I need the library functionality in the > 'videoinput'. So where I have to do the changes in the Makefile? > > I have tried the changes in the Makefile in the directory > 'win32/eliga/src/Makefile'. In the line 767 and the following, from the > current 'trunk'. But the reference is doesn't found. > Error: > videoinput.o: In function `_ZN14GMVideoGrabber4MainEv': > /home/pfefferkeks/win32/ekiga/src/devices/videoinput.cpp:125: undefined > reference to `Transport_Ekiga_AR::getInstance()' you can try tweaking the line $(MAKE) $(MAKEOPTS) -C $(EKIGA_DIR) in win32/Makefile and put CFLAGS or CXXFLAGS there. Otherwise you'll need to fiddle the -lVideoAR into the CFLAGS or CXXFLAGS into the ekiga Makefiles themselves. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compile gnome-2-20 (last stable) for Win32
Hi Swen, > [EMAIL PROTECTED]:~/win32$ make > /bin/sh: line 0: cd: > /home/pfefferkeks/win32/ekiga-/home/pfefferkeks/win32: No such file or > directory what you obviously see is "ekiga-" which is entirely lacking the version but instead suffixing the entire local path. That apparently is an issue with BUILDROOT. As said, the old idea was to run make in the toplevel dir to ekiga itself. This was changed and the makefile from the SVN branch tries to find ekiga-X.Y.Z in the path and poke around. Just move the gnome-2-20 dir to be named ekiga-2.0.x and it'll work.o You'll need to manually create include/, lib/ and src/ at the same level as ekiga-* .. That'll mean you have: win32/ - lib/ - src/ - include/ - ekiga-2.0.x/ - win32/ ... and in that win32/ dir you just type "make". -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga-snapshot Debian package
Ciao Luca, > Kilian, I think that libopal-cvs should now also suggests libx264-54! yes. Added. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga-snapshot Debian package
Ciao Luca, On Thu, Aug 30, 2007 at 01:49:33PM +0200, Luca Capello wrote: > Ciao Kilian! > > On Thu, 30 Aug 2007 08:08:30 +0200, Kilian Krause wrote: > > On Wed, Aug 29, 2007 at 11:06:17PM +0200, Luca Capello wrote: > [...] > >>>> dpkg-shlibdeps: warning: could not find any packages for libopal.so.2.3 > [...] > >> This *is* a problem. > > > > Right. And even having looked to it, I don't (yet) see why this > > happens and thus how to fix it. I'm open to suggestions, but this > > will need further debuging why this happens to get it sorted out. > > FWIW, I'm trying to debug it myself, too. Good. If you find something, just point me to it. Especially I don't understand why this doesn't happen with the opal in Debian. IF you have some time on your hands, try diffing and maybe tracing the debhelper moudles to track this down. It kinda bothers me, because the behavious is plain *wrong* as is. ;) > >> Perfectly understandable. Kilian, IMHO libopal-cvs should at least > >> Suggests: libavcodec1d, maybe even Recommends:. > > > > Yes, the problem however is the multitude of Packages providing it. > > I need to make a list and add that unless you have one. > > Mmm, I'd say that we should stick with Debian official packages as > much as we can. Since etch still have libavcodec0d while lenny and > sid libavcodec1d [1], wouldn't "libavcodec0d | libavcodec1d" do the > trick? Sounds good enough. Sarge: - (would need backporting) Etch: libavcodec0d Lenny/Sid: libavcodec1d Dapper: - (would need backporting) Edgy: libavcodec0d Feisty: libavcodec0d Gutsy: libavcodec1d Thus, added as you proposed. > >> I didn't look into the code (most of which I cannot understand), > >> but I'm a bit surprised: shouldn't x264 acts the same as > >> libavcodec? > [...] > > That's something with the way the linking is done right now. If the > > plugin does depend on it (instead of fully dynamically load it when > > provided and needed), it'll show up in the Depends. > > I guessed that and that's way I specifically asked why libx264 isn't > fully dynamically loaded (as libavcodec). Maybe Matthias can provide a "fix" to this. Then the Depends will also move to Suggests. > > The *-cvs variant is not intended for Debian. It's an external > > repository. > > I'm aware of that, but since you're also the maintainer for the > official Debian version, I guess you base your work on the *-cvs > variant. Anyway, nevermind. Yes, they're kept as "identical as possible" for exactly that reason. Yet I have some limits in Debian that I "extended" for the -cvs snaps to make some developers a bit more happy. ;) > > The official Debian version will not have X.264 (and just for the > > record, doesn't have iLBC either for the obvious same DFSG-reason). > > I wasn't aware of iLBC, thank you for the info. The whole of Debian isn't shipping iLBC - i.e. you'll also not find it in asterisk. And well, maybe I will split out the ilbc plugin to make it "pluginable" to a regular Debian install. (well, when I have the time to do that, or so.) -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga-snapshot Debian package
Ciao Luca, On Wed, Aug 29, 2007 at 11:06:17PM +0200, Luca Capello wrote: > Hi Matthias! > > On Wed, 29 Aug 2007 08:04:30 +0200, Matthias Schneider wrote: > > --- Luca Capello <[EMAIL PROTECTED]> schrieb: > >> First of all, I started to investigate because on a clean and > >> up-to-date sid (created as described at [1]) ekiga-snapshot doesn't > >> depend on libopal-cvs and indeed: > [...] > >> [EMAIL PROTECTED]:/# su luca > >> [EMAIL PROTECTED]:/$ ekiga-snapshot > >> ekiga-snapshot: error while loading shared libraries: libopal.so.2.3: \ > >> cannot open shared object file: No such file or directory > >> [EMAIL PROTECTED]:/[EMAIL PROTECTED]:/# > >> = > >> > >> What's strange is the following: > >> = > >> [EMAIL PROTECTED]:~$ dpkg-shlibdeps /usr/bin/ekiga-snapshot > >> dpkg-shlibdeps: warning: could not find any packages for libopal.so.2.3 > >> dpkg-shlibdeps: warning: unable to find dependency information for \ > >> shared library libopal (soname 2.3, path libopal.so.2.3, dependency \ > >> field Depends) > >> dpkg-shlibdeps: failure: open new substvars file \ > >> debian/substvars.new': No such file or directory > >> [EMAIL PROTECTED]:~$ > > This *is* a problem. Right. And even having looked to it, I don't (yet) see why this happens and thus how to fix it. I'm open to suggestions, but this will need further debuging why this happens to get it sorted out. > >> I'd say that libopal-cvs is definitively broken. > > > > No, it is not. Actually a desired behaviour, libavcodec.so is > > loaded dynamically on runtime, and if it is not found, some of > > ekiga's codecs (i.e. MPEG4 P 2, H.264, H.263+) will simply be > > deactivated (like you wrote in your first email), but ekiga will br > > completely functional. > > As I said, I'm not a library expert, so thank you for the > explanation. > > > So I would say points 1) and 2) of your original email is normal > > behavior. The debug output just tells you where it looks for > > libavcodec.so and if it finds it. > > Perfectly understandable. Kilian, IMHO libopal-cvs should at least > Suggests: libavcodec1d, maybe even Recommends:. Yes, the problem however is the multitude of Packages providing it. I need to make a list and add that unless you have one. > > The same should be true for x264, ekiga/opal executes a helper > > process that is dynamically linked to x264. In case that execution > > fails, H.264 should simply be deactivated, and ekiga should start up > > anyway... > > I didn't look into the code (most of which I cannot understand), but > I'm a bit surprised: shouldn't x264 acts the same as libavcodec? I > mean, without libavcodec the H.264 codec is deactivated, thus I don't > see the point in having libx264 installed while it's not used. So, > I'd like libopal-cvs to not depends on, but only suggests or > recommends, all the libraries/codecs which need libavcodec. That's something with the way the linking is done right now. If the plugin does depend on it (instead of fully dynamically load it when provided and needed), it'll show up in the Depends. > Please pay attention that if libopal-cvs depends on libx264, this > creates a big problem for Debian, since libx264 has patent issues (and > thus ATM cannot be redistributed in Debian, maybe in non-free [1]). > This causes libopal-cvs (or any other official libopal depending on > libx264) to be put in contrib, according to [2]. The *-cvs variant is not intended for Debian. It's an external repository. The official Debian version will not have X.264 (and just for the record, doesn't have iLBC either for the obvious same DFSG-reason). -(snip)- > [1] it seems quite strangely, however, that the package has been > removed if it could have been available in non-free it could not: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423250 -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga-snapshot crashes (Debian package 20070827-02-sid.1)
Ciao Luca, On Mon, Aug 27, 2007 at 11:24:36PM +0200, Luca Capello wrote: > 1) it tries to load libavcodec.so instead of libavcodec.so.1d (which >is in lenny/sid) or the one in the ekiga repository >(0.cvs20070307-7~sid.838 [1]) and as soon as the GUI appears it >crashes (first attachment) > [1] is there any particular reason for a non-official libavcodec1d > snapshot? that's from the ffmpeg-free source, isn't it? Well, actually there is not. I just haven't come round to removing it everywhere and re-adding only to the dists where it's required. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] cvs voxgratia snapshot stale
Hi Anand, On Thu, Aug 16, 2007 at 10:28:21AM -0500, Anand R. Setlur wrote: > The voxgratia cvs snapshot does not look as current as the buildserver.net > cvs snapshot. Any reason why they are not mirroring each other? fixed. Thanks for spotting this. -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] VoIP IPv6 projects for presentation at ECAI6?
Hi all, as you may already have spotted I'll be doing a 45min talk at ECAI6 (European Conference on Applied IPv6 - http://www.guug.de/veranstaltungen/ecai6-2007/) about how to use VoIP over IPv6. Surely some of you have very interesting projects in this area, so please feel free to drop me a note with a heads up what you've been doing. The final presentation is due August 12, thus it'd be great if I had your feedback before then. Of course I hope to have a working IPv6-ready Ekiga by then to not need to present GnomeMeeting for IPv6-capable VoIP. If there's anything I can help with it, please let me know! -- Cheers! Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Improving the GNOME experience : request for help
Hi David, first, sorry for the delay. I thought I should take my time to get the answers more comprehensible, but I guess before this will not get answered at all, I'll just jumpstart and whoever thinks it's not clear enough, please bug me with questions. ;) > > > > > 5) Build a repository > > > > > > > > What are the issues with the existing repositories? > > > > > > The existing repositories will be built from the repository the release > > > maintainer will build. Currently, each time I receive a package, I need > > > to scp it to ekiga.org. That is time consuming for me. Every release, I > > > loose a few hours on that instead of coding. > > > > Could a release manager extend the script that builds the nightly > > snapshots to also make release packages? Does the build script > > automatically slurp the library tarballs or CVS down from Sourceforge? > > I don't really know, Kilian is handling that script, he is in CC. > Notice you will have to use specific branches and tags, so the script > should be made generic. You do not need to build on all distributions, > you just need to create the tarballs and test. Well, the problem with release packs is not really with packaging, but with Craig and the official tarballs on voxgratia.org. These tarballs should be well tested (as is the case with CVS snaps already), so we might want to introduce an extra snapshots part for the other branches. For this, my current script doesn't scale too well, but I'm willing to put it onto public webspace for review. As the generation of package sources is done outside in an extra script anyway, this will scale pretty nicely once the checkout script can do more than one branch. The main problem with this is that the config should reside in the SVN/CVS of the project, so that upstream maintainers can choose the mappings. For this we'd need to put up a map like: HEAD => ekiga-snapshots gnome-2-18 => ekiga-2-18 etc. From there the question is how to handle the library dependencies with these snapshots. For example HEAD can be built with HEAD libs, but gnome-2-18 should be built with Phobos or some other branch. If you can come up with a scheme that can do this kind of mapping in a flexible and scalable config (so that my script will be able to read it and make packs non-interactively), I'll be happy to include it. > > Finally, do you think the package maintainers could be persuaded to > > upload packages (or package definition files) to a stable location? > > Or do they do this already? > > We could do that if somebody setups the server. That kind of archive should be possible on archive.buildserver.net. In that case the RPMs would mingle just nicely in between the deb-structure. For now we don't export the urpmi and ap4rpm style lists, but this could be added to the dak if someone stands up to doing this. The ideas are all there. ;) -- Best regards, Kilian signature.asc Description: Digital signature ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] HELP !!! (Was Re: [VALVE] Ubuntu Edgy)
Tom, > > Not from you Kilian, Jan, Julien, Yannick. You are already doing a lot > > for Ekiga. We need fresh air, from new people. > > Why exclude Kilian? He's a senior and CM for many packages and distros and > leading member > of distro QA teams and provides valuable You ignore sometimes for reasons > that indicate > P-CMM issues (not only from the rumors). > > Any taker ? > > If Kilian is out, I'm out, too. you misread Damien. He said that he's excluding me from the blame. He's not excluding me from the project. ;) So, no worries, I'm still there and I will be (as will my packs). -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga source snapshots includes svn history
Stefan, On Sun, Jan 21, 2007 at 02:46:56PM +0100, Stefan Bruens wrote: > just noticed that the ekiga source snapshots include the .svn directories > since the cvs/svn switch, leading to +6.5MB mostly useless data in the > packages. right you are. Fixed in checkout script (will ship to webspaces in ~15mins or so). -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compiling Problem
Gustavo, On Fri, Jan 19, 2007 at 04:44:50PM -0600, Gustavo Valdes wrote: > Hello. > I have tried to compile the application but I get the following errors. > > $ make > make: dpkg-architecture: Command not found > Checking prerequisites... > /bin/sh.exe: hash: i586-mingw32msvc-gcc: not found > /bin/sh.exe: hash: i586-mingw32msvc-g++: not found > /bin/sh.exe: hash: i586-mingw32msvc-ld: not found > /bin/sh.exe: hash: i586-mingw32msvc-nm: not found > /bin/sh.exe: hash: i586-mingw32msvc-ar: not found > /bin/sh.exe: hash: i586-mingw32msvc-ranlib: not found > /bin/sh.exe: hash: i586-mingw32msvc-dlltool: not found > /bin/sh.exe: hash: i586-mingw32msvc-dllwrap: not found > /bin/sh.exe: hash: i586-mingw32msvc-objdump: not found > /bin/sh.exe: hash: i586-mingw32msvc-windres: not found > /bin/sh.exe: hash: i586-mingw32msvc-as: not found > You need to install mingw32 > make: *** [binaries] Error 1 > > I have installed MinGW 5.0, MinGW32-make and MSys. > In the downloads list of MinGW site I can find gcc and g++, but I can't find > the other programs or modules. > > Would you please let me know what modules do I have to install? well, the makefile is tailored to work on a Debian GNU/Linux system to do cross-compile builds. Right now we've not put together the same thing for native win32 builds, as cross-compilation works just much more convenient together with the other Linux builds. I guess you can more or less run "touch binaries" to get past that stage. -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compiling Problem
Gustavo, On Mon, Jan 15, 2007 at 04:23:25PM -0600, Gustavo Valdes wrote: > I'm trying to add some libraries to make the UI skinnable, this libraries > belong to a project named SLIK and I'd also want to remove or hide some > tabs. for SILK, just copy a target like libxml2 or libogg (3 targets overall). Add the last lib/libsilk.a to the depends of ekiga/config.status. Then go ahead and update the tarball or hack away with the ekiga/ directory. Touch ekiga/autogen.sh will cause "make all" to refresh all subsequent targets. Hth. -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compiling Problem
Gustavo, On Mon, Jan 15, 2007 at 03:47:10PM -0600, Gustavo Valdes wrote: > What if I need to change or add some features to the program and I need to > compile against that new code? basically add it to [the build-depends of] the target you need it compiled (that new code). It's all in the make syntax and dependency chains. If you can bring a more straightforward question what kind of code you need to add and where to I can give you more direct instructions. -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compiling Problem
Gustavo, On Mon, Jan 15, 2007 at 10:11:50AM -0600, Gustavo Valdes wrote: > I've downloaded the CVS versions and the Ekiga Build file to check it, > unfotunatelly my experience with .make files is quite short. So, reading the > file, I'm not sure if it's going to connect to CVS and get the source from > there, or if I have the option to specify the directory where I've placed my > downloaded versions? the Makefile does rely on the sources being available through our CVS/SVN webspace at http://snapshots.ekiga.net/cvs/ (or voxgratia.org). No need to get CVS sources or anything yourself, the script has all the source-retrievals built-in. -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compiling Problem
Gustavo, On Mon, Dec 18, 2006 at 01:22:17PM -0600, Gustavo Valdes wrote: > I plan to distribute it within a company but I'd like to share the code, > once made. > > About compiling on windows ... any clue to get rid of config.h dependency??? > > I'm checking the windows version you've made an in the account screen the > account type combo (to choose from SIP or H323) does not appear as it does > in the manual screenshots. what about the scripts that are on the webpage, namely: http://snapshots.ekiga.net/win32/ekiga_build.tgz ? Does that answer your question how we actually get rid of all the problems? -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Blacklisting
Jan, > What did you have in mind for greylists? greylisting would be responding with a "busy" upon first call and letting everything through after a given timeout. The idea is that you erase all the "one-shot-only" SPAMmers (SPITers here). For obvious reasons this is not really a good idea with VoIP. I'd rather say a timeout to complete before Ekiga starts ringing in the GUI would be much better. -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] problems compiling v4l2
Hi again, whoever has tried searching a fix for this, the Ubuntu packs are building again and the V4L2 detection now works perfect. Thanks goes to Luc Saillard! -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] problems compiling v4l2
Hi guys, as some of you may already have noticed, there are no really current Ubuntu snapshots from CVS since some time (for all architectures). For some reason the v4l2 test fails on Ubuntu due to the other headers that are pulled in by autoconf. The result from configure (taken from plugins/config.log on ppc dapper) is as follows: -(snip)- configure:3979: checking for linux/videodev2.h configure:4000: gcc -c -g -O2 conftest.c >&5 In file included from conftest.c:25: /usr/include/linux/time.h:9: error: redefinition of 'struct timespec' /usr/include/linux/time.h:15: error: redefinition of 'struct timeval' In file included from /usr/include/linux/videodev2.h:16, from conftest.c:29: /usr/include/sys/time.h:57: error: redefinition of 'struct timezone' /usr/include/sys/time.h:94: error: syntax error before numeric constant /usr/include/sys/time.h:108: error: redefinition of 'struct itimerval' configure:4006: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #ifdef __cplusplus | extern "C" void std::exit (int) throw (); using std::exit; | #endif | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | /* end confdefs.h. */ | | #ifdef __linux__ | #include | #include | #endif | | | #include configure:4030: result: no configure:4037: checking for V4L2 video support configure:4045: result: no -(snip)- Someone got any idea how to cleanly fix this and can bring forth a proper patch to apply upstream? -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga cross compilation
Dcak, On Thu, Nov 23, 2006 at 11:56:03AM +0530, Dheepan A.P wrote: > please help me how to cross compile ekiga(specially pwlib directory) on > montovista.At present it is compiled in gcc try reading http://snapshots.ekiga.net/win32.php ... Especially the part at the bottom where it reads "these are the scripts we use for cross-compilation". -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Patch to remove some code
On Sun, Nov 05, 2006 at 06:47:29PM +0100, Damien Sandras wrote: > Le dimanche 05 novembre 2006 à 17:57 +0100, Julien Puydt a écrit : > > Damien Sandras a écrit : > > > If you are 100% sure it doesn't break anything, yes. > > > > This function is only used in gmconf-glib.c, and as far as I know, the > > win32 port is compiled against glib 2.12 now (and probably a newer > > version when we'll move to gtk+ 2.10). > > > > Well, Windows Millenium only has GTK+ 2.6 available. Well, WinME has no security support anymore. Thus, whoever is running this OS shouldn't be doing it networked. Obviously non-networked workstations are not really best choice for running a VoIP softphone. IMHO, Snark's patch is ok, as at some point we need to move. I haven't checked Sarge and RHEL9 though. As neither of which does build for other reasons (without proper backports) AFAIK, we can plain proceed. Just my 2 €-ct. -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] compiling on Win32
Damien, Am Freitag, den 27.10.2006, 16:05 +0200 schrieb Damien Sandras: > Le vendredi 27 octobre 2006 à 15:46 +0200, Dario Busso a écrit : > > I'm just subcribed on this mailing list, so be patient. > > I'm interested to know if there is any planning to port ekiga project to > > win32 platform. > > There's any one how know if it exist a project or planning about it? > > Thanks in advance. > > http://snapshots.seconix.com/win32/ almost right. It's http://snapshots.ekiga.net/win32.php as the frontpage. ;) Yet, the win32 port is currently under active resync with the CVS upstream changes. This means the above version is rather old. The current CVS HEAD builds are available for demonstration purposes, yet not to be regarded as working. Therefore they are not yet updated to the above webpage. As soon as Julien reckons that we've reached a level of usability that we can roll out again, the updates will be included on the above URL. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Ekiga/win32 links again
Hi guys, ok, after some long trial and error hours of compilation Julien helped me to finally get the compilation scripting up to the current codebase. Right now, we can link Ekiga (untested, plain CompilesForMe(TM)), but it ships no codec plugins whatsoever. Thus, someone(tm) or anyone(tm) needs to take the diff/opal_Makefile.am and check what's still missing to complete the migration towards plugins. Most probably PWLib plugins also need to be added. In short: we're searching for skilled betatesters listing what's missing and what they can identify (most preferably with patches). The latest version of our work is right now temporarily hosted at http://trinity.buildserver.net/~kk/ where you'll find the scripts under ekiga_win32_build and results under dist/. Feel free to test all of this, same rules as are on http://snapshots.ekiga.net/win32.php apply. Once we get past this final step, win32 snapshots will be done live and updated again and next to come would be putting the autotools efforts into CVS to merge all of this upstream of course (after thorough testing of course). -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Where I get the source??
Wolf, Am Samstag, den 21.10.2006, 05:44 +0200 schrieb Wolf St. Kappesser: > call me stupid (i m from windows world ;)) but i couldn t find the source > there is only the binary (which run on my system "well") on the bottom > links. Would be thankfull for some explanating words. I guess the most convenient until the "CVS problem" is solved is to use the checkout tarball from: http://snapshots.ekiga.net/cvs/ekiga-cvs.tar.gz That one is constantly updated, so it should give you about the same versions as a fresh CVS checkout. Latency may be up to an hour, but you'll manage to sustain that, eh? ;) For the win32 building, that script which was already mentioned is updated already and I'm through till getting ekiga compile at last. If anyone is interested, the updated version is at: http://archive.buildserver.net/win32/ekiga_win32_build_20061023.tbz That one should at least get you pretty well started in case you own a linux shell to run this script set on. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Where I get the source??
Hi Wolf, > my name is Wolf and I wish to develop with you the Windows version of > Ekiga...but I couldn t find the source files. > Where I can get them to see what you done. the most convenient is to use http://snapshots.ekiga.net/cvs/ where we have updated tarball checkouts from developer CVS. This at least for a once-in-a-while processing does spare you all the problems of dealing with the CVS and seeing the annoying delay from developer to anonymous CVS from time to time. For the Win32 build, I've had working scripts, yet right now they don't really are up to date with latest CVS HEAD. Feel free to grab the copy off http://snapshots.ekiga.net/win32.php and compare this with what Michael Rickmann sent to this mailinglist. From there, we should seek to include all remaining patches into the CVS HEAD and getting someone to prepare this list and split out relevant patches as individual chunks would probably help best. Thanks. -- Best regards, Kilian ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Status of http://snapshots.seconix.com
Hi again, regarding sarge backports the story was longer than just the easy fix I and start to remember why I hadn't done it back then already. Problem is with intltool updated to a recent version, that configure still stalls at: configure: error: Package requirements (gtk+-2.0 >= 2.4.0 gthread-2.0 >= 2.4.0 esound >= 0.2.28 gconf-2.0 >= 2.2.0 libgnome-2.0 >= 2.14.0 libgnomeui-2.0 >= 2.14.0) were not met. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. That means, we'd need to backport half of gnome effectively which is more than I'm willing to maintain over a longer time. If someone really wants to step up for it and *will* maintain it, please do send me a mail to ask for instructions. Integration with the buildd is not the problem, but I guess this will become ugly over time. So, right now, as sad as it renders me, there will not be any sarge backports of Ekiga and Ekiga-cvs until this is fixed. (and right now apt-get.org tells me there is no such archive) -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Status of http://snapshots.seconix.com
Hi Tom, Am Sonntag, den 08.10.2006, 07:48 +0200 schrieb thomas schorpp: > > patches at me is herewith warmly asked to do so(*). Logs for Sarge build > > problems would be along [2] and can be found in the log database for > > checking for intltool >= 0.33.0... ./configure: line 1: ./intltool-update.in: > No such file or directory > ./configure: line 1: ./intltool-update.in: No such file or directory > ./configure: line 2262: test: : integer expression expected > found. Your intltool is too old. You need intltool 0.33.0 or later. > make: *** [config.status] Error 1 > ** > Build finished at 20061007-1430 > FAILED [dpkg-buildpackage died] > Purging > chroot-i386_voip-snapshots-debian-sarge//build/buildd///ekiga-cvs-20061007-02 > > i know this. whether package-config is broken or we need the links in the > source packages. > what to do? provide links? As the intltool is probably required in that version (someone please verify and correct if not), the best would be to either make this requirement optional or to backport. I guess adding backports.org to the sarge voip-snapshots sources.list is something that wouldn't hurt too many users if the list of installed packages is cut down to intltool*, but yet I dislike to jeopardize the purity of build env for reproducibility and compatibility. Yet, I guess I can try doing that later today and see if it gets us any further than this. > and reportbug intltool-debian < intltool on sarge? Sarge is closed in terms of versions and long released like that. There is no point in filing bugs to update packages in a Debian release. -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Status of http://snapshots.seconix.com
Hi Damien, Am Sonntag, den 17.09.2006, 18:11 +0200 schrieb Damien Sandras: > Can you make a public announcement about the current status of the > builds at http://snapshots.seconix.com ? > > (Debian, Sources, Fedora, ...) short summary: we're back online with fresh Debian and Ubuntu snaps! ;) The little longer story for those interested: http://snapshots.ekiga.net/ (EU-Mirror) and http://snapshots.voxgratia.org/ (US-Mirror) should now both be alive and updated hourly again. The problem was that due to the lack of snapshots.gnomemeeting.net in DNS the sync script didn't find the host no more and thus was not able to sync. Further, Dapper updates had been queued till today due to the propagation script was not able to resolve the dependency from within dapper main as dapper-updates had shipped a newer libpango. This is also fixed now. Remains the problem with edgy and compilation of pwlib-cvs[1]. This one is something the MOTU will solve sooner or later I guess. Quite similarly building right now completes on neither sarge nor win32 in the snapshot buildd. Whoever feels like throwing decent patches at me is herewith warmly asked to do so(*). Logs for Sarge build problems would be along [2] and can be found in the log database for quite some versions already. The win32 build issues may already be discussed on the mailinglist and eventually I'll come round to catching up there too. Hope everybody with Sid, Etch and Dapper is now happily supported by new snapshots so that the testing can go on! -- Best regards, Kilian (*) preferred would be a debian-package of flavour "all" that does the cross-compiling by perusing a regular buildd environment. Yes, I know it's ugly, so spare us the flames. This mechanism would just ease the "packaging" really a lot. ;) [1]: http://stats.buildserver.net/fetch.php?&pkg=pwlib-cvs&ver=20061006-02-edgy.1&arch=i386&stamp=1160142571&file=log&as=raw [2]: http://stats.buildserver.net/fetch.php?&pkg=ekiga-cvs&ver=20061007-02-sarge.1&arch=i386&stamp=1160224262&file=log&as=raw signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Debian/Kanotix:Ekiga didn't find any usable audio codec.
Hi guys, Am Dienstag, den 12.09.2006, 09:22 +0200 schrieb Damien Sandras: > Kilian will answer. That is the second report of this kind. For some > reason, perhaps codecs plugins are not installed. > > Le lundi 11 septembre 2006 à 22:57 +0200, Conrad Beckert a écrit : > > Today I installed Ekiga Snapshot 20060509 (SID) via apt-get on my Kanotix > > 2005/04 System. Everything went through but when I start Ekiga it pops > > up "Ekiga didn't find any usable audio codec. Make sure that your > > installation is correct." and exits. > > > > What's wrong? Thank you in advance for your help according to Julien this is due to a bad directory name used to install the opal codecs. It's known and being worked on. Should be fixed "really soon now". ;) -- Best regards, Kilian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
