Re: [Ekiga-devel-list] [VALVE] Ubuntu Edgy
Hi Jan, Guess who documents those broken stuffs? https://help.ubuntu.com/community/Ekiga#head-8a1ff4f72f1c76533d456a91223854f2c772d7ca I fully agree with you. Edgy was release in 4 months introducing lots of new technos. What a mess in ubuntu forums... I personnaly only trust LTS releases (dapper for instance). When moving to ubuntu, I was hoping something more recent than stable Debian with a faster upgrade cycle. Finaly, I stick with Dapper for production... IMO Ubuntu has a release cycle during 1 year and a half for stable version. btw, today is a great day: https://launchpad.net/ubuntu/+source/gnome-vfs2/+bug/76301 update uploaded now No more comments... Regards, Yannick On mer, 2007-02-07 at 06:35 +0100, Jan Schampera wrote: Folks, http://bugzilla.gnome.org/show_bug.cgi?id=400590 http://bugzilla.gnome.org/show_bug.cgi?id=401351 http://bugzilla.gnome.org/show_bug.cgi?id=404157 http://bugzilla.gnome.org/show_bug.cgi?id=404612 http://bugzilla.gnome.org/show_bug.cgi?id=405193 (and masses of similar stuff I didn't find yet, plus masses of similar stuff from other programs than Ekiga) I talk to other developers (not Ekiga) from time to time, most of them tend to ignore Ubuntu Edgy reports, as usually Edgy itself is broken, not the program that is reported (broken libraries, insane installations, well, we know it from http://bugzilla.gnome.org/show_bug.cgi?id=359655). This entirely broken distribution seems to crash some applications randomly and totally without deeper logic. Not only applications, they also refuse to ship fixed kernel modules, instead they ignore these floods of reports from their users. To make it clear, I don't say it's always Ubuntu Edgy that crashes Ekiga, but 90% of the bugreports we get out of this area point to a broken installation, broken libraries, incorrrect dependencies etc... That's something I would not wonder about on a self-made installation like LFS, but not on a professional, commercial, up to date variant of Debian. Testing is not an excuse here, as it means something really different, and Debian testing (just as example) proofs that QA mechanisms also work for unstable software. For Ubuntu Edgy it seems, it's not related to technical reasons, it's related to politics. Sorry for the noise, I just needed a valve J. -- Me joindre en téléphonie IP / vidéoconférence ? sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] XV Patch
Hello Damien, first of all sorry about having caused some uneccessary work by not respecting the coding convetions, I think I got confused between varios projects.. Yes, you are right, Xlib calls are not threadsafe and thus have to be protected by XLockDisplay and XUnlockdisplay in a MT application. I did not notice that until about a week ago because all applications that I was looking at to get some XVideo knowledge are singlethreaded - and decent documentation about XVideo is very sparse... However I have located a possible issue: in case of using Xlib calls in an MT app, a XInitThreads() has to be executed before the first Xlib call, i.e. in this case before gtk_init(). In case the respective Xlib does not support MT XInitThreads return 0 and in this case I simply do an exit(1), however to be 100% correct this should just be used as an indication to directly fall back to gdk output - however I have no idea how likely that is and how to pass on this information to videooutput_ekiga... I have attached a patch containing the difference between the last patch I sent you (please check that you have been using xvideo3.patch, in case you are based on one of the earlier patch I can make you another diff). In this patch I tried to filter out the changes in the corresponding files due to the update of the original ekiga SVN. This patch fixes the following issues: - Xlib calls should be threadsafe now - fixed HAS_XV warning - fixed compiler warings - FS menu entry now depends on SDL, XV and XV fallback - 0x0 frame size fix if remote image was not available - solves issue of flickering PiP - PiP in window mode similar to PiP in encrusted mode - solves moving windows when going to FS and returning - additional XSync possibly against a third black XV window in the background Concerning the rework on GDK, please tell me if I can be of any help - in my opinion the following functions should be in videooutput_gdk.cpp instead of main.cpp (perhaps we can kick out all the ifdef HAS_SDL and leave only the if defined HAS_XV || defined HAS_SDL): void gm_main_window_update_video (GtkWidget *main_window,... gboolean gm_mw_init_fullscreen_video_window (gpointer data) gboolean gm_mw_poll_fullscreen_video_window (GtkWidget *main_window) gboolean gm_mw_destroy_fullscreen_video_window (gpointer data) In case with the reworked xv support you are still getting crashes I would like to have a look at a backtrace if possible... Thanks in advance, Matthias ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de xvp3deltato27.patch.gz Description: 2285838136-xvp3deltato27.patch.gz ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] HELP !!! (Was Re: [VALVE] Ubuntu Edgy)
Hi, Le mercredi 07 février 2007 à 06:35 +0100, Jan Schampera a écrit : Folks, http://bugzilla.gnome.org/show_bug.cgi?id=400590 http://bugzilla.gnome.org/show_bug.cgi?id=401351 http://bugzilla.gnome.org/show_bug.cgi?id=404157 http://bugzilla.gnome.org/show_bug.cgi?id=404612 http://bugzilla.gnome.org/show_bug.cgi?id=405193 (and masses of similar stuff I didn't find yet, plus masses of similar stuff from other programs than Ekiga) We would really need a few persons interested in Ekiga, and who could take in charge the role of triaging bugs. We sometimes receive interesting bug reports, often not. I am loosing much time triaging them. I am loosing much time trying to reproduce them. I am loosing much time trying to get information from users to reproduce the problem. Most of the time, people send me privately -d 4 outputs. I am forced to ignore them. Very often, people send me private e-mails to cancel their Ekiga account, or to ask a question. I am also forced to ignore them. I would really need help. Not from you Kilian, Jan, Julien, Yannick. You are already doing a lot for Ekiga. We need fresh air, from new people. Any taker ? -- _ Damien Sandras (o- //\Ekiga Softphone : http://www.ekiga.org/ v_/_ NOVACOM : http://www.novacom.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:[EMAIL PROTECTED] ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] XV Patch
On Wed, 7 Feb 2007 22:59:30 +0100 (CET) Matthias Schneider [EMAIL PROTECTED] wrote: Concerning the rework on GDK, please tell me if I can be of any help - in my opinion the following functions should be in videooutput_gdk.cpp instead of main.cpp (perhaps we can kick out all the ifdef HAS_SDL and leave only the if defined HAS_XV || defined HAS_SDL): void gm_main_window_update_video (GtkWidget *main_window,... gboolean gm_mw_init_fullscreen_video_window (gpointer data) gboolean gm_mw_poll_fullscreen_video_window (GtkWidget *main_window) gboolean gm_mw_destroy_fullscreen_video_window (gpointer data) In case with the reworked xv support you are still getting crashes I would like to have a look at a backtrace if possible... Thanks in advance, Matthias IMHO They shouldn't really go out IMHO, just the hard working part (the functionality) should be moved out. Flow control and general control for the functionality should stay in main. J. -- I know life sometimes can get tough! and I know life sometimes can be a drag! But people, we have been given a gift, we have been given a road And that roads name is... rock and roll! KISS in God gave Rock'n'Roll to you ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
