Re: [libgadu-devel] 1.12.0 nie buduje się bez certyfikatów
Dnia 2014-06-21, sob o godzinie 17:37 +0200, Tomasz Wasilczyk pisze: W takim przypadku zostaje użyty /etc/ssl/ca-bundle.pem. Nie widzę powodu, dla którego w przypadku nie znalezienia tego pliku (ani żadnego innego) libgadu miało by jednak używać tej nieistniejącej ścieżki. Jeśli ca-certificates to jedyny w tej dystrybucji pakiet dostarczający certyfikaty, to nie widzę powodu, dla którego ta ścieżka nie miałaby być użyta. Jest pakiet, to libgadu zweryfikuje certyfikaty. Nie ma pakietu, nie zrobi tego. Jak ktoś nie chce instalować openssl, może ten plik sobie skopiować. Jeśli alternatywą ma być brak możliwości weryfikacji certyfikatów w ogóle, to wolałbym jednak rozwiązanie, które przy minimalnych nakładach mi na to pozwoli. Moim zdaniem configure powinien wyrzucać warning jeżeli nie ma skonfigurowanej tej ścieżki - w takim przypadku również paczkę bedzie mógł zainstalować każdy oraz zostanie odpowiednio poinformowany w przypadku problemów. Użytkownik końcowy, który instaluje paczkę libgadu tego nie zobaczy. Nawet jeśli klienty zaczną wyświetlać odpowiedni komunikat, to nadal wydaje mi się, że doinstalowanie jednej paczki lub skopiowanie pliku jest łatwiejsze do przełknięcia. A dopiero jeśli komuś nie pasuje domyślna ścieżka narzucona w specu, zajdzie konieczność przekompilowania libgadu. Ale to tylko moja skromna opinia. Co do #warning, to chcesz go dorzucić do źródeł czy nagłówków? Jeśli źródeł, to IMHO lepszy będzie komunikat z ./configure. Jeśli nagłówków, to głupio by było zepsuć kompilację poprawnie napisanej aplikacji (patrz gg_debug i __attribute__((format))), która domyślnie w CFLAGS ma -Werror. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.12.0
Dobry wieczór, Wszyscy czekają, więc wypada już wydać 1.12.0. Nie ma co owijać w bawełnę. Lista ważniejszych zmian: * Obsługa protokołu Gadu-Gadu 11. * Możliwość weryfikacji certyfikatu serwera. * Możliwość użycia własnych funkcji do połączeń TCP/TLS. * Możliwość podania nazwy serwera, nie tylko adresu. * Poprawki drobnych błędów zgłoszonych przez projekt Pidgin w ramach audytu Coverity. * Poprawki przesyłania obrazków. * Poprawki niezawodności testów automatycznych. * Poprawki niezawodności pod Windows. Ponieważ brak weryfikacji certyfikatu serwera był zgłaszany jako błąd bezpieczeństwa, proszę traktować tę wersję jako krytyczną aktualizację, jeśli faktycznie używano szyfrowanej transmisji. Osobom, które nie śledziły rozwoju gałęzi 1.11, przypominam, że ostatnie wersje zawierały poprawki bezpieczeństwa, które znalazły się również w 1.12.0. Szczegóły pod adresem http://libgadu.net/releases/1.12.0.html Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.12.0 - kiedy?
Dnia 2014-06-11, śro o godzinie 10:54 +0200, Tomasz Wasilczyk pisze: 2014-06-11 6:09 GMT+02:00 Rafał Malinowski rafal.przemyslaw.malinow...@gmail.com: Skoro jest tylko w teście to można by to zignorować/przesunąć do 1.12.1? Albo tymczasowo całkiem wyłączyć możliwość anulowania (PTHREAD_CANCEL_DISABLE) wątków resolvera. Nie wiem co jest gorsze. Kończą mi się pomysły, a nie chciałbym z powodu Fedory opóźniać wydania, na którym zależy paru projektom. Nie chciałbym też psuć funkcjonalności, która poza Fedorą jakoś działa. Dlatego wypuśćmy w końcu 1.12.0 tak jak jest teraz, a gdy Dominik będzie miał więcej czasu możemy do tego problemu wrócić i wydać 1.12.1. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
Dnia 2014-06-01, nie o godzinie 23:01 +0200, Wojtek Kaniewski pisze: Dodanie volatile pomaga (gcc 4.8.2). Jak patrzę na wygenerowany kod asemblerowy, to nie mam najmniejszego pojęcia, co się tam dzieje. Myślałem, że jak spojrzę na implementację pthread_cleanup_push() i _pop() to czegoś się dowiem, ale teraz wiem jeszcze mniej ;) Jeszcze prostsze jest usunięcie static z funkcji gg_resolver_cleaner(), bo najwyraźniej wtedy nie próbuje inline'ować. Wrzuciłem coś takiego do repo. Niestety nie znalazłem w Bugzilli GCC niczego podobnego w kontekście pthread_cleanup_push/pop, więc to raczej my coś robimy nie tak jak powinniśmy :( Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
Dnia 2014-05-27, wto o godzinie 23:01 +0200, Tomasz Wasilczyk pisze: Wolałbym nie stosować takiej armaty na tego buga, a raczej zdiagnozować go dokładniej. Jeżeli byśmy tak zrobili, to nie będzie się dało anulować rozpoznawania nazw (nie jest to jednak tragedia). Chodzi o to, że w krytycznych miejscach i tak powinien być ustawiany PTHREAD_CANCEL_DISABLE, więc albo gdzieś to przeoczyliśmy, albo się jednak nie ustawia (może zmienna pthread jest gdzieś NULLem). Jeżeli masz nadal cierpliwość do tego, to prosiłbym o sprawdzenie, w której dokładnie linii to się wysypuje: najpierw wstawiaj PTHREAD_CANCEL_DISABLE w funkcjach gg_resolver_run i gg_gethostbyname_real (od końca i coraz wyżej), a jak pomoże to po danym bloku przywracaj (patrz linijki pthread_setcancelstate(old_state, NULL);). No i najpierw mógłbyś sprawdzić, czy ta zmienna pthread nie jest nullem, to by wiele wyjaśniało. Zaczynam się zastanawiać, czy te wszystkie pthread_setcancelstate() są w ogóle potrzebne. Szukałem, szukałem i nigdzie nie znalazłem informacji o tym, żeby malloc() i free() były cancellation points. A jeśli nie są, to nie musimy się zabezpieczać przed pthread_cancel() alokując lub dealokując pamięć. Co do samego błędu, na który trafił Dominik, to zmieniłem test resolvera tak, żeby w kółko tworzył wątek i po losowym czasie (rzędu milisekund) go ubijał. Segfaulty zdarzały się co kilkanaście tysiące wywołań i wyglądały zawsze tak: Program terminated with signal SIGSEGV, Segmentation fault. #0 __GI___inet_aton (cp=cp@entry=0x0, addr=addr@entry=0xb4bff2fc) at inet_addr.c:138 138 inet_addr.c: Nie ma takiego pliku ani katalogu. (gdb) bt #0 __GI___inet_aton (cp=cp@entry=0x0, addr=addr@entry=0xb4bff2fc) at inet_addr.c:138 #1 0xb764d0c7 in inet_addr (cp=cp@entry=0x0) at inet_addr.c:96 #2 0xb774dffd in gg_resolver_run (fd=4, hostname=0x0) at resolver.c:264 #3 0xb774e0ec in gg_resolver_pthread_thread (arg=0x901e120) at resolver.c:485 #4 0xb76f9f70 in start_thread (arg=0xb4bffb40) at pthread_create.c:312 #5 0xb762f70e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129 Problem widać w #2, gdzie hostname jest równe NULL.Nie znalazłem nigdzie czyszczenia tej zmiennej, więc to raczej nie jest jakiś oczywisty wyścig z ubijaniem wątku. Niestety po przekompilowaniu libgadu nową wersję gcc przestało się reprodukować :( Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
Dnia 2014-05-27, wto o godzinie 18:50 +0200, Dominik 'Rathann' Mierzejewski pisze: Niestety, nie pomaga. Nadal mam segfaulty. Natomiast tak, jak pisałem, dodanie pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); w linii 535 src/resolver.c pomaga. Mógłbyś spróbować zamiast tego dodać na początku funkcji gg_resolver_pthread_thread() coś takiego? pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL); Teraz już wróżę z fusów, ale różnice w dokumentacji pthread między wersjami Fedory są tak duże, że nie zdziwiłbym się, gdyby domyślne parametry wątków się zmieniły. Co więcej, po przestawieniu na PTHREAD_CANCEL_ASYNCHRONOUS na moim Ubuntu pojawiają się deadlocki w malloc(). Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
Dnia 2014-06-01, nie o godzinie 21:08 +0200, Jakub Zawadzki pisze: Próbowałeś może uruchomić swój test pod valgrindem? Puszczałem z memcheckiem i helgrindem, żeby wykryć jakiś głupi dostęp do pamięci, ale nie patrzyłem na wycieki pamięci. Faktycznie coś jest. Wygląda że moje gcc-4.6 optymalizuję wywołanie gg_resolver_cleaner(), (skoro buf == NULL, to *(buf) też będzie NULL), co generuje memleaka: ==4697== 2,234,368 bytes in 2,182 blocks are definitely lost in loss record 10 of 10 ==4697==at 0x4C2C730: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==4697==by 0x4E4BF08: gg_gethostbyname_real (resolver.c:119) ## buf = malloc(buf_len) ==4697==by 0x4E4C2E0: gg_resolver_run.constprop.0 (resolver.c:294) ==4697==by 0x4E4C38F: gg_resolver_pthread_thread (resolver.c:537) ==4697==by 0x58E4EB6: start_thread (in /lib64/libpthread-2.17.so) Kompilowanie libgadu z -fno-inline albo dodanie volatile do buf łata tego memleaka. Dodanie volatile pomaga (gcc 4.8.2). Jak patrzę na wygenerowany kod asemblerowy, to nie mam najmniejszego pojęcia, co się tam dzieje. Myślałem, że jak spojrzę na implementację pthread_cleanup_push() i _pop() to czegoś się dowiem, ale teraz wiem jeszcze mniej ;) Porównałem wynik kompilacji wersji oryginalnej i z volatile. To co piszesz o optymalizacji ma sens. Z punktu widzenia kompilatora gg_resolver_cleaner() będzie wołane w pthread_cleanup_pop() zaraz po ustawieniu buf na NULL, więc faktycznie może to wyciąć. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.11.4
Dobry wieczór, Nowa wersja zawiera poprawkę bezpieczeństwa związaną z nieprawidłowym sprawdzaniem zakresu zmiennej przy alokacji pamięci. Błąd może zostać wywołany przez odpowiednio spreparowaną odpowiedź serwera przy przesyłaniu plików, więc prawdopodobnie będzie wymagał interakcji ze strony użytkownika. Szczegóły pod adresem http://libgadu.net/releases/1.11.4.html Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Segfault w testach na architekturze sparc
Dnia 2014-04-26, sob o godzinie 13:34 +0200, Wojtek Kaniewski pisze: Dnia 2014-04-25, pią o godzinie 21:39 +0200, Tomasz Wasilczyk pisze: Przydało by się już wydać finalne libgadu 1.12.0 i ten raport trochę psuje szyki ;). Wyciągnąłem z szafy starego Suna, żeby spróbować odpalić testy, ale okazało się, że bateria w NVRAM-ie padła. Może uda mi się jakoś odpalić w weekend, to spróbuję pomieszać w testach. I jednak nic z tego, bo nowsze wydania nie obsługują już 32-bitowych SPARCów. W każdym razie, podobnie jak Tomek popatrzyłem w kod libgadu, patrzyłem w kod GnuTLS i nie widzę za bardzo powodu, dla którego miałoby się podwójne zwalnianie zdarzyć. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Segfault w testach na architekturze sparc
Dnia 2014-04-25, pią o godzinie 21:39 +0200, Tomasz Wasilczyk pisze: Przydało by się już wydać finalne libgadu 1.12.0 i ten raport trochę psuje szyki ;). Wyciągnąłem z szafy starego Suna, żeby spróbować odpalić testy, ale okazało się, że bateria w NVRAM-ie padła. Może uda mi się jakoś odpalić w weekend, to spróbuję pomieszać w testach. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.12.0-rc2
Dnia 2014-02-06, czw o godzinie 23:41 +0100, Tomasz Wasilczyk pisze: Najlepiej gdzieś w kodzie inicjującym wywołać funkcję gg_is_gpl_compliant() i sprawa załatwiona. Wywołanie podczas inicjalizacji jest kluczowe, bo zwykła referencja gdzieś w nieużywanym kodzie może trafić na LTO albo lazy binding. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.12.0-rc2
Dobry wieczór, Nowa wersja rc2 względem rc1 zawiera głównie poprawki bezpieczeństwa. Po pierwsze, zabezpieczamy się przed fałszywym hubem, który mógłby zwrócić adres serwera w dowolnej domenie, co pozwala na ataki man-in-the-middle nawet przy weryfikowanych certyfikatach serwera. Po drugie, wersja zawiera poprawkę błędu bezpieczeństwa tak jak wersja 1.11.3, której opis pozwolę sobie zacytować: Niestety znaleziono błąd bezpieczeństwa w libgadu, który przy pomocy odpowiednio spreparowanej odpowiedzi serwera pozwala nadpisać pamięć i wykonać dowolny kod. Nawet jeśli założmy, że serwer nie będzie chciał nam zrobić krzywy, jest wiele sposobów, żeby się pod niego podszyć, zwłaszcza mając dostęp do sieci lokalnej klienta. Aktualizacja jest wysoce zalecana. Szczegóły dotyczące błędu można znaleźć na stronie http://vrt-blog.snort.org/2014/01/vrt-2013-1001-cve-2013-6487-buffer.html Poprawka pochodzi z repozytorium Pidgina, gdzie błąd został pierwotnie znaleziony. Przy okazji, do tej wersji zostały wrzucone poprawki drobnych, nieszkodliwych błędów znalezionych przez Coverity, też w Pidginie. Kwiaty, bombonierki i podziękowania można (w zasadzie należy) słać do Tomka Wasilczyka. Szczegóły pod adresem http://libgadu.net/releases/1.12.0-rc2.html Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.12.0-rc1
Dnia 2014-01-31, pią o godzinie 21:02 +0100, Rafał Malinowski pisze: Hej, jest jakaś szansa na 1.12.0 stabilne niedługo? Właśnie zaczęliśmy wymagać tej wersji :) Jeszcze będzie 1.12.0-rc2 ze względu na poprawkę bezpieczeństwa i jeśli nic strasznego się nie stanie, to szybko wyjdzie 1.12.0. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.11.3
Dobry wieczór, Niestety znaleziono błąd bezpieczeństwa w libgadu, który przy pomocy odpowiednio spreparowanej odpowiedzi serwera pozwala nadpisać pamięć i wykonać dowolny kod. Nawet jeśli założmy, że serwer nie będzie chciał nam zrobić krzywy, jest wiele sposobów, żeby się pod niego podszyć, zwłaszcza mając dostęp do sieci lokalnej klienta. Aktualizacja jest wysoce zalecana. Szczegóły dotyczące błędu można znaleźć na stronie http://vrt-blog.snort.org/2014/01/vrt-2013-1001-cve-2013-6487-buffer.html Poprawka pochodzi z repozytorium Pidgina, gdzie błąd został pierwotnie znaleziony. Przy okazji, do tej wersji zostały wrzucone poprawki drobnych, nieszkodliwych błędów znalezionych przez Coverity, też w Pidginie. Kwiaty, bombonierki i podziękowania można (w zasadzie należy) słać do Tomka Wasilczyka. Szczegóły pod adresem http://libgadu.net/releases/1.11.3.html Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-09-19, czw o godzinie 19:40 +0530, Radhesh Krishnan K pisze: I couldn't follow up with this for long time. Is this bug fixed ? libgadu now rejects connection when certificate verification fails and gg_login_params.tls is set to GG_SSL_REQUIRED. When .tls is set to GG_SSL_ENABLED it just issues a warning, since then it allows even plain-text connections. CRL is supported only when the library handles it automatically (GnuTLS = 3.0), which is documented in README. New release is a matter of days. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-15, sob o godzinie 23:20 +0200, Bartosz Brachaczek pisze: Does this function also verify the host name? It seems that it doesn't but I'd like to be sure before I start looking into it. Yeah, you're right. It doesn't. So I did implement commonName verification with rudimentary support for wildcard domains. I did not dive into the subjectAltName verification though. Should we care? And BTW, do you know if OpenSSL and GnuTLS handle CRL automatically or should we provide and/or load some CRL file manually? Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-07, pią o godzinie 01:55 +0200, Bartosz Brachaczek pisze: So the functions of interest are: a) for OpenSSL: -- SSL_CTX_set_default_verify_paths() to use CA cert store configured during OpenSSL's build Does this function also verify the host name? It seems that it doesn't but I'd like to be sure before I start looking into it. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
2013/6/13 Bartosz Brachaczek b.brachac...@gmail.com 2013/6/12 Wojtek Kaniewski wojte...@toxygen.net: As Bartosz wrote the code for GnuTLS will be more complicated, so it may take some time. Do you have any plan for it? (...) I plan to copy and paste a part of GnuTLS' configure.ac. Take a look at https://gitorious.org/gnutls/gnutls/blobs/c59329a089a9ed108692066de95f533f482b5422/configure.acline 377. And if we detect GnuTLS 3.x we'll use appropriate function. Are you okay with such solution? Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-12, śro o godzinie 12:42 +0530, Radhesh Krishnan K pisze: I was wondering if there is any update on this ? I commited the verification code for OpenSSL version. As Bartosz wrote the code for GnuTLS will be more complicated, so it may take some time. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] How to Report a Security Bug in libgadu
Dnia 2013-06-02, nie o godzinie 19:02 +0530, Radhesh Krishnan K pisze: I would like to report a security bug in libgadu. libgadu is using openSSL library for creating secure connections. (...) So the product using libgadu will be vulnerable to man-in-the-middle attack. It was rather a conscious decision. Since libgadu is a reverse-engineered implementation of a proprietary protocol, we have no control over the certificates used for SSL connections. We don't know which certificates will be accepted or rejected by the original client, so there is no reliable way to verify their validity in libgadu. But since you mentioned it, I guess we should at least add a note to the documentation. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu oddam w dobre ręce
Dobry, Jak od dłuższego czasu widać, coraz trudniej mi się zajmować libgadu. Może nie tyle rozwojem, a utrzymywaniem, bo od jeszcze dłuższego czasu nowy kod pochodzi głównie od bohaterów innych projektów jak Kadu czy Pidgin. I jeśli będę te zmiany integrował w takim tempie jak ostatnio, wkrótce forkowanie będzie dla nich łatwiejsze niż wysyłanie łat. Dlatego chętnie oddam projekt w dobre ręce. Ja stąd nie zniknę i czasem pomogę, czasem pomarudzę, ale nie chcę już dłużej powstrzymywać rozwoju. Jeśli chodzi o kwestie organizacyjne, nowy utrzymywacz może dostać uprawnienia do strony i repozytorium, ale może też przenieść projekt w inne miejsce, jeśli tak będzie mu wygodniej. Wszystko jest do dogadania. Ja wiem, że to żaden lans w CV, ale może ktoś od dawna o tym marzył? ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] Protokół GG11 i nowe pakiety
Dobry, Dopiero co zintegrowałem do trunka zmiany Tomka Wasilczyka (to takie zawoalowane ogłoszenie), a już szykuje się spora reorganizacja, bo okazuje się, że te nowe pakiety to nic innego jak Protocol Buffers od Google: https://developers.google.com/protocol-buffers/docs/encoding Niestety ich kompilator nie umie generować kodu C, więc musimy sobie poradzić inaczej. Macie może jakieś pomysły jak zgrabnie opisać strukturę pakietu, żeby móc łatwo ją serializować i deserializować? Coś w stylu perlowo-pythonowych pack() i unpack(), które dostaną wskaźnik na strukturę. A może wskaźniki na poszczególne pola? Coś w stylu formatu printf/scanf, żeby kompilator mógł sprawdzać poprawność typów? Czy może dla każdego pola wołać funkcję, która wepchnie/wyciągnie wartość (obiektowość a'la GLib) i nie bawić się w przedwczesną optymalizację? Idealnie byłoby, gdyby dało się opisać strukturę w kodzie, a potem zastosować takie samo rozwiązanie do starych, zwykłych pakietów. Nie wymagam za dużo? Pomożecie? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Nowe poziomy debugowania
Dnia 2012-11-14, śro o godzinie 19:32 +0100, Tomasz Wasilczyk pisze: tak sobie walczę z tym GG11 i stwierdzam, że strasznie ciężko zauważyć w debug logu błędy wypluwane przez libgadu - są one oznaczane tak samo, jak komunikaty o powodzeniu operacji. Dało by się wprowadzić nowe flagi, powiedzmy GG_DEBUG_WARNING i GG_DEBUG_ERROR? To by mi bardzo ułatwiło zauważanie bugów. Na razie wystarczy tylko dodanie tego do API, niekoniecznie od razu poprawne oznaczenie wszystkich istniejących komunikatów. Jako że poziom debugowania jest maską, nie widzę problemu. I tak pewnie wszystkie aplikacje jako gg_debug_level dają 0 albo 0x :) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Nowe poziomy debugowania
Dnia 2012-11-15, czw o godzinie 22:44 +0100, Tomasz Wasilczyk pisze: Rozumiem, że mogę wprowadzić sugerowaną zmianę do swojego repo dotyczącego GG11 i poleci do libgadu przy okazji scalania? Jasne, śmiało. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Funkcja do nawiązywania połączeń
Dnia 2012-07-02, pon o godzinie 23:31 +0200, Tomasz Wasilczyk pisze: Zrobiłem bardzo wstępną implementację [1], którą podpiąłem na sztywno do połączeń http - na razie bez żadnej konfiguracji, taki proof-of-concept. Działa ona w ten sposób, że najpierw zlecamy nawiązanie połączenia za pomocą gg_proxy_default_connect (docelowo będzie to jeden z możliwych rodzajów funkcji nawiązującej połączenia), następnie obserwujemy uzyskany file descriptor i sprawdzamy stan za pomocą gg_proxy_default_watch. Jeżeli ta ostatnia funkcja zwróci coś innego niż GG_PROXY_RESULT_CONNECTING, to już mamy rezultat (sukces lub powodzenie). Proszę o komentarze. Część tego kodu jest bardzo tymczasowa, ale oddaje możliwy sposób na takie nawiązywanie połączeń. Nie podoba mi się dodawanie kolejnej maszyny stanów. Być może nie do końca rozumiem, co jest tymczasowe, co docelowe, ale zakładam, że to, co wrzuciłeś do libgadu.h tymczasowe nie jest. To, co proponowałeś wcześniej, wydawało się w zupełności wystarczające -- jeśli ktoś chce proxy, podaje wskaźnik na funkcje łączącą się, a my czekamy na wynik. Monitorowanie deskryptorów własnej funkcji łączącej mocno komplikuje. Podobnie są zrobione własne resolvery -- nie dajemy dostępu do naszej pętli zdarzeń, czekamy tylko na wynik. Nawet gdyby ktoś chciał użyć własnego resolvera opartego na adns, i tak musiałby stworzyć nowy wątek. Nie powinno być to problemem nawet w jednowątkowych aplikacjach typu ekg -- wystarczyłoby we własnej pętli zdarzeń monitorować co tylko się chce. I przepraszam, że tak późno, ale mam teraz tyle na głowie, że gdy już na chwilę siadam do komputera, to nie pamiętam, jak się nazywam. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Testy zawodzą na GNU/kFreeBSD
Dnia 2012-06-25, pon o godzinie 09:10 +0100, Marcin Owsiany pisze: r1301 się zbudowało na autobuilderze hurd-i386, ale dla odmiany pojawił się błąd na kfreebsd-amd64, które było OK. Chyba jest jeszcze jakiś wyścig: https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=kfreebsd-amd64ver=1%3A1.12.0~pre%2Br1301-1stamp=1340581139 Mógłbyś spróbować teraz? Najlepiej kilka razy, jeśli to możliwe. Gdy z jakiegoś powodu informacja o timeoucie z poprzedniego testu nie została odebrana (i wyczyszczona), w kolejnym mogły się dziać cuda. I przy okazji, robiąc `apt-get build-dep libgadu` na obrazie Debiana 6.0 dla AMD64 nie dostałem pkg-config, więc configure nie wykrył GnuTLS. Tak ma być? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Funkcja do nawiązywania połączeń
Dnia 2012-06-25, pon o godzinie 17:31 +0200, Tomasz Wasilczyk pisze: Mozna tez przekazac tam nowa strukture, zawierajaca konfiguracje proxy (lub NULL, aby uzyc globalnej konfiguracji). Sesja by tez mogla ja przechowywac. To chyba najlepsze rozwiazanie? Zrobiłem szkic prototypów nowej funkcji i struktur nawiązujących połączenia [1]. Trzeba by było w bibliotece możliwie wszędzie zmienić użycie gg_connect na gg_connect_proxy, przekazując gdzie się da konfigurację dotyczącą sesji (gg_proxy_configuration). Tam, gdzie się nie da, używana była by konfiguracja globalna. Co o tym myślicie? Mogę to powoli zaczynać implementować, czy trzeba szukać innego rozwiązania? Być może jeszcze coś przeoczyłem, proszę o komentarze. Wydaje mi się, że SOCKS5, tak jak HTTP, może dostać nazwę hosta, nie tylko adres, co sprawia, że mechanizm resolvera z libgadu można pominąć. Dlatego fajnie by było pozwolić adresu lub nazwy. Łatwo mi sobie wyobrazić jakąś korporacyjną sieć, w której DNS jest filtrowany i cały ruch ma iść przez proxy. Acha, do enumów i struktur rób typedefy zakończone _t. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Testy zawodzą na GNU/kFreeBSD
Dnia 2012-06-23, sob o godzinie 10:40 +0100, Marcin Owsiany pisze: Niestetyż wygląda na to że na hurdzie nadal się zacina: https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=hurd-i386ver=1%3A1.12.0~pre%2Br1298-1stamp=1340426273 Spróbuję wyczaić czy inactivity faktycznie znaczy to co podejrzewam. Dziwne. Nie wiesz, czy można skądś ściągnąć gotowy obraz systemu dla QEMU, VirtualBox albo innego emulatora? Może tak będzie łatwiej? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Testy zawodzą na GNU/kFreeBSD
Dnia 2012-06-18, pon o godzinie 21:00 +0100, Marcin Owsiany pisze: Timeouty w tym teście są zmniejszone do minimum, żeby nie osiwieć czekając na wyniki, co przy słabym sprzęcie i/lub dużym loadzie może niestety mieć negatywny wpływ. Plus to, że wywalił się test 433, a te od 324 w górę lecą po SSL-u. Gdyby dało się timeouty podbić jakąś opcją konfiguracji albo zmienną środowiskową, to mógłbym spróbować zwiększyć na tej architekturze albo przynajmniej przetestować czy pomaga. Możesz spróbować dodać cokolwiek, co zawiera valgrind do LD_PRELOAD, o ile bzdurna wartość tej zmiennej nie szkodzi Hurdowi. Gdyby tak było, daj znać, dodam coś innego. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Ostrzeżenia
Dnia 2012-06-17, nie o godzinie 17:57 +0100, Marcin Owsiany pisze: W czasie kompilacji r1289 na Debianie sid amd64 dostaję następujące ostrzeżenia. Gdyby tak poprawić przynajmniej wszystkie od GCC to mógłbym się pokusić o użycie -Werror, co dałoby wgląd w stan kodu na wszystkich architekturach Debiana. Co sądzicie? Możesz sprawdzić teraz? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Testy zawodzą na GNU/kFreeBSD
Dnia 2012-06-17, nie o godzinie 13:15 +0100, Marcin Owsiany pisze: Dzięki, sprawdzę (nawiasem ten log to był trunk). Spróbuję też zobaczyć czy da się jakoś usdostępniać report.html na przyszłość. Od dawna nosiłem się z tym, żeby pozbyć się generowania HTML-a przez testy, bo wartość dodana jest niewielka. Aktualna wersja po prostu wyrzuci na konsolę logi każdego nieudanego testu i tyle. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r1262 - in trunk: . pkgconfig
Dnia 2012-06-13, śro o godzinie 20:13 +0200, Bartosz Brachaczek pisze: W dniu 13 czerwca 2012 19:55 użytkownik Wojtek Kaniewski wojte...@toxygen.net napisał: libgadu.h zawiera #include openssl/ssl.h. Jesteś pewny, że powinno iść do .private? Tak, pkgconfig doda ścieżki do inkludów tak czy inaczej. Polecam przeczytać Guide to pkg-config[1], w szczególności dwa ostatnie punkty FAQ. Kilka minut czytania i wie się więcej o pkgconfig, niż zdecydowana większość programistów. :) No dobra, sprawdziłem empirycznie dodając coś do openssl.pc i faktycznie `pkg-config --cflags libgadu` zwróciło to samo. Całe to pkg-config jest mało intuicyjne. Może i wiem już, jak się powinno robić, ale nie mam najmniejszego pojęcia dlaczego ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r1277 - trunk/src
Dnia 2012-06-13, śro o godzinie 23:05 +0200, Bartosz Brachaczek pisze: Niezbyt rozumiem, jak do..while mogłoby znieść konieczność użycia czegoś w stylu MIN. No ale faktycznie do..while trochę skróciłoby kod. I powinienem był to makro nazwać jakoś mniej ogólnie, np. GG_MIN. W każdym razie chyba możesz śmiało wrzucać to, co masz na myśli. :) Znosi konieczność użycia makra, bo nie musisz wszystkiego pchać do jednego wyrażenia (warunek while), tylko na spokojnie przypisać, porównać, podmienić itd. Tak czy inaczej, uprościłem jeszcze bardziej kod, wyciągając wspólny kawałek dla 10MB i 10MB na zewnątrz funkcji. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Testy zawodzą na GNU/kFreeBSD
Dnia 2012-06-16, sob o godzinie 22:47 +0200, Wojtek Kaniewski pisze: Jesteś w stanie zgarnąć plik tests/automatic/report.html z maszyny budującej? Eee, to nie ten test wyleciał. Niestety `protocol` średnio się nadaje do testowania na nielinuksowej maszynie z wieloma użytkownikami, bo adres i port ma wpisane na stałe. Poprawiłem to w r1287. Możesz zerknąć, czy ma to sens, ewentualnie ręcznie puścić test na maszynie z KFreeBSD? Jeśli tak, dorzucę od razu do kolejnego 1.11.x. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r1262 - in trunk: . pkgconfig
Dnia 2012-06-13, śro o godzinie 01:31 +0200, Libgadu commit list pisze: Author: beevvy Date: 2012-06-13 01:31:45 +0200 (Wed, 13 Jun 2012) New Revision: 1262 Modified: trunk/configure.ac trunk/pkgconfig/libgadu.pc.in Log: Umieszczaj zależność od openssl tam gdzie należy, czyli w Requires.private libgadu.h zawiera #include openssl/ssl.h. Jesteś pewny, że powinno iść do .private? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r1266 - trunk/src
Dnia 2012-06-13, śro o godzinie 01:33 +0200, Libgadu commit list pisze: Zatem musimy koniecznie użyć pthread_join(), aby być pewnym, że wątek nie spróbuje użyć zwolnionych już danych. Niesie to też ze sobą konieczność zrezygowania z pthread_detach(). Plus dla Ciebie. Ten kod tam siedział od 2004. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r1277 - trunk/src
Dnia 2012-06-13, śro o godzinie 14:40 +0200, Libgadu commit list pisze:
for (i = 0; i 9; i++) {
unsigned int left = 1048576;
+ off_t current_pos = (len - 1048576) / 9 * i;
- if (lseek(fd, (len - 1048576) / 9 * i, SEEK_SET) ==
(off_t) - 1)
- return -1;
+ if (lseek(fd, current_pos, SEEK_SET) == (off_t) - 1) {
+ res = -1;
+ break;
+ }
#define MIN(a, b) (((a) (b)) ? (a) : (b))
while ((res = read(fd, buf, MIN(sizeof(buf), left)))
0 || (res == -1 errno == EINTR)) {
if (res != -1) {
SHA1_Update(ctx, buf, res);
+ current_pos += res;
left -= res;
if (left == 0)
break;
+ } else {
+ /* Dokumentacja read(2) mówi, że nie
wiadomo, co się dzieje z pozycją po błędzie. */
+ if (lseek(fd, current_pos, SEEK_SET) ==
(off_t) -1) {
+ res = -1;
+ break;
+ }
}
}
#undef MIN
Nie lepiej by tutaj było zrobić pętlę do/while z lseek() na początku? Po
pierwsze, kod dotyczący lseek() występowałby tylko raz. Po drugie, nie
byłoby potrzebne makro MIN(), które na jakichś platformach i/lub
środowiskach może być już zdefiniowane, wystarczyłoby normalne
porównanie.
Pozdr,
Wojtek
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r1269 - trunk/src
Dnia 2012-06-13, śro o godzinie 01:34 +0200, Libgadu commit list pisze: Author: beevvy Date: 2012-06-13 01:34:58 +0200 (Wed, 13 Jun 2012) New Revision: 1269 Modified: trunk/src/dcc7.c trunk/src/http.c Log: Obsługuj EAGAIN i EINTR również przy gg_resolver_recv() Tak się zastanawiam... Jest jakiś konkretny powód, dla którego mielibyśmy obsługiwać EAGAIN? Kręcenie się w kółko zżerając 100% procesora, gdy aplikacja zrobi coś głupiego, to na pewno najlepsze wyjście? :) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.11.1
Dobry wieczór, Parę ważnych zmian się uzbierało na gałęzi 1.11, więc najwyższy czas wydać wersję z poprawkami. Tym razem będą to: * Poprawiona obsługa SSL za pomocą biblioteki GnuTLS * Poprawione określanie bibliotek dla pkg-config * Poprawione rozwiązywanie nazw dla systemów bez funkcji gethostbyname_r, np. rodziny BSD * Poprawiona konwersja nieprawidłowych sekwencji UTF-8 Szczegóły pod adresem http://toxygen.net/libgadu/releases/1.11.1.html Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Niedziałająca obsługa OpenSSL
Dnia 2011-12-28, śro o godzinie 00:50 +0100, Bartosz Brachaczek pisze: W obecnym trunku obsługa OpenSSL jest zepsuta. Mianowicie w gg_session_init_ssl() wywoływane jest SSL_CTX_new() pod warunkiem, że gs-ssl_ctx != NULL, podczas gdy powinno być wywoływane pod przeciwnym warunkiem. Sam nie wrzucam poprawki, bo nie wiem, czy dla przypadku gs-ssl_ctx != NULL ma być SSL_CTX_free() i stworzenie nowego obiektu, tak jak jest z gs-ssl, czy też nie mamy wtedy nic z tym robić. Masz rację. Widać, że mimo nowych testów kodu SSL, nie puszczałem ich z OpenSSL, bo wyszłoby od razu. Niepokoi mnie tylko, że testy nie do końca poprawnie działają z OpenSSL. Możliwe, że to tylko problem testów, nie biblioteki, ale muszę na to zerknąć. Co do zwalniania SSL_CTX, to wydaje mi się, że nie ma takiej potrzeby. Jeden kontekst może być użyty w wielu sesjach, więc żyje tak długo jak gg_session. Podobnie jak gnutls_certificate_credentials_t w przypadku GnuTLS. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] gg_send_packet() a EAGAIN
Dnia 2011-12-28, śro o godzinie 13:30 +0100, Jakub Zawadzki pisze: On Wed, Dec 28, 2011 at 01:28:12PM +0100, Jakub Zawadzki wrote: Spróbuj z r1240 (...) Oczywiście chodziło mi o r1242, zły dzień ;| Gdyby chodziło Ci o r1243, to bym powiedział, że świetna robota ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Problem z budowaniem libgadu z gnutls na Opensuse Factory
Dnia 2011-12-19, pon o godzinie 16:18 +0100, Marcin Owsiany pisze: On Fri, Dec 16, 2011 at 11:21:26PM +0100, Rafał Malinowski wrote: Dostaję: -lgnutls Wersja to 3.0.3-8.1 Podeślesz swój plik /usr/lib/pkgconfig/gnutls.pc ? Przydałby się też wycinek komunikatów z kompilacji która zawodzi przed Twoją zmianą. To raczej kwestia tego, że src/sha1.c korzysta bezpośrednio z funkcji libgcrypt, mimo że libgadu się z nią explicite nie linkuje. Niestety biblioteka nie używa pkg-config, więc chyba skończy się na skopiowaniu do repozytorium libgcrypt.m4. Tak przy okazji, znacie może jakiś sposób, żeby mieć w drzewie projektu pliki m4 na wypadek, gdyby ktoś nie miał w swoim /usr/share/aclocal odpowiednich makr, ale mimo to brać systemowe, jeśli są nowsze? Bo mimo wszystko wolałbym nie wymagać libgcrypt-dev albo podobnego pakietu po to, żeby zbudować libgadu z repozytorium. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] HAVE_STRTOULL i HAVE_UINT64_T a dcc7
Dnia 2011-11-02, śro o godzinie 19:04 +0100, Bartosz Brachaczek pisze: Cześć, Kawałek kodu w src/dcc7.c (a także kod na usługach dcc7 w include/internal.h i src/endian.c) zależy od zdefiniowanych makr HAVE_STRTOULL i HAVE_UINT64_T.. Tak się jednak składa, że te makra są jedynie definiowane w config.h (include/libgadu.h.in nic o nich nie wie), a żaden ze wspomnianych plików config.h nie includuje, więc i kod zależny od istnienia tych makr nigdy nie jest kompilowany. Ten kod nie jest jakoś niesamowicie istotny dla działania połączeń bezpośredni, ale i tak niezły obciach ;) Co do HAVE_STRTOULL, wydaje mi się, że można je zastąpić GG_CONFIG_HAVE_STRTOULL (a także GG_CONFIG_HAVE__STRTOUI64 na potrzeby MSVC). GG_CONFIG_HAVE_STRTOULL nie jest potrzebne w żaden sposób aplikacji, więc nie pchałem tego do libgadu.h, tylko zostawiłem w config.h. GG_CONFIG_HAVE_UINT64_T też nie będzie potrzebne, dopóki nigdzie w API nie pojawi się 64-bitowa wartość. Natomiast istnienie HAVE_UINT64_T jest dla mnie trochę dziwne, bo przecież jest już GG_CONFIG_HAVE_LONG_LONG. Co z tym zrobić? Typ long long jest używany do operowania na liczbach, ale ze względu na różne endiany, powstała nowa funkcja gg_fix64(), która podobnie jak inne gg_fixX() operuje na typach uintX_t. Biorąc pod uwagę, że uint64_t nie musi być wcale tożsamy unsigned long long, robi się to trochę skomplikowane i nagle windowsowe API ze swoim strtoui64() zaczyna mieć więcej sensu. Sam nie wiem, co z tym zrobić na dłuższą metę, ale póki co dodałem config.h gdzie trzeba i poprawiłem #ifdef wokół funkcji gg_fix64. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libpurple'owy fork - synchronizacja z upstream
Dnia 2011-10-29, sob o godzinie 03:11 +0200, Bartosz Brachaczek pisze: To ja może podsumuję tutaj znane mi problemy pod MSVC i Win32 ogólnie: To ja się ustosunkuję do paru, bo okazało się, że jednak mam już zainstalowane Visual Studio Express i udało mi się pogrzebać tak w kodzie, żeby się skompilowało. - Na Win32 gniazda trzeba zamykać za pomocą closesocket(), ale pliki nadal za pomocą close() (właściwie _close(), ale close() też działa). Ja mam na to łatę w postaci funkcji gg_closesocket() opakowującej odpowiednią funkcję systemową. Jedyne, co mi tu się troszkę nie podoba, to ta nazwa wskazująca na gniazdo, a muszę jej używać również w przypadku deskryptorów resolvera. Technicznie oczywiście nie ma tu problemu, bo na Win32 one muszą być gniazdami, a gdzie indziej i tak to się sprowadza do zwykłego close(). Wolałbym w drugą stronę, tj. zostawić 99% wywołań close() w spokoju i zrobić #define close(a) closesocket(a) dla Win32, a te dwa w kodzie DCC oifdefować. W końcu mamy do czynienia głównie z siecią. - MSVC odmawia kompilacji pustej struktury gg_dcc7_dunno1. Jak dla mnie można by ją spokojnie usunąć lub zakomentować. Chętnie bym to usunął, ale wtedy Debian powie, że zmieniło się API (cześć Marcin!). - MSVC nie posiada nagłówków unistd.h i inttypes.h. Ten drugi jest używany w message.h nie patrząc się na config.h, co chyba można by jakoś zmienić. Już nie używa. Ten include był zupełnie niepotrzebny. Nie dość, że message.h nie korzysta z żadnego typu uintX_t, to libgadu.h zajmuje się ich dostarczeniem. - Pliki dcc.c, dcc7.c i sha1.c w katalogu src pod MSVC potrzebują nagłówka io.h, który definiuje część rzeczy znanych z unistd.h w GCC. - MSVC nie definiuje S_IWUSR, natomiast definiuje jego przedposixowy synonim S_IWRITE. To może kolejny plik nagłówkowy do zachowania kompatybilności, tym razem operacji na plikach? Zacząłem pisać takowy, ale niestety inne obowiązki wyciągnęły mnie z Windows. - MSVC nie posiada funkcji snprintf, posiada natomiast _snprintf, która jest co prawda niezgodna z C99, ale na potrzebny libgadu powinna wystarczyć. Może użyć _snprintf_s()? Jeśli za parametr count dać _TRUNCATE, to będzie się zachowywać snprintf() sprzed C99, tj. zwracać -1 jeśli bufor jest za krótki, ale przynajmniej będzie kończyć \0. - MSVC nie akceptuje arg... jako argument makra. Wydaje mi się, że mam na to proste rozwiązanie, ale muszę je przetestować. Jeśli będzie z tym problem, to można z gg_debug_dcc() zrobić po prostu funkcję i zrobić to normalnie. Powrzucałbym skończone łatki, jakie mam, do repozytorium libgadu, ale nie mam do końca wyczucia, które z kilku możliwych rozwiązań każdego problemu jest najbardziej pożądane. Chyba wrzucę to wszystko do jakiegoś zewnętrznego repozytorium, tak jak zresztą już wcześniej planowałem. Jeśli coś można zrobić na dwa sposoby, z których jeden będzie wymagał mniej zmian w istniejącym kodzie (patrz close() vs closesocket()), wybierz właśnie ten i tyle. Jeśli coś będzie nie tak, to posprzątam ja albo ktoś inny. Nie po to dostałeś dostęp do repozytorium, żeby zmiany trzymać gdzie indziej :) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Wyciek pliku w dcc (dcc6)
Dnia 2011-10-28, pią o godzinie 00:59 +0200, Bartosz Brachaczek pisze: W ramach prac nad portem Win32 przeglądałem użycia funkcji close() w libgadu i stwierdziłem, że wszystkie jej wywołania w pliku dcc.c dotyczą gniazd. W związku z czym wydaje mi się, że brakuje close(d-file_fd) w gg_dcc_free(). Też to zauważyłem wczoraj. Nawet przejrzałem wzorcową implementację pt. ekg i nie ma tam zamykania tego deskryptora, więc jak najbardziej. Dodasz przy okazji zmian dla Win32 czy mam od razu to poprawić? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libpurple'owy fork - synchronizacja z upstream
Dnia 2011-10-25, wto o godzinie 01:03 +0200, Bartosz Brachaczek pisze: Mam nadzieję, że w środę napiszę te wszystkie errno-wrappery i przetestuję całość pod MSVC (paru dodatkowych łatek jeszcze będę musiał pewnie użyć). Przetestuję również w szczególności tego resolvera Win32. Ale powinien działać dobrze - porównałem go wreszcie z tym z libpurple. Wnioski wyciągnąłem takie, że wygląda czyściej i nie powinno mu niczego brakować. Jak jeden z czytelników zasugerował poza listą, niestety kod resolvera miał błędy związane z usuwaniem wątku. Nie jestem ekspertem od WINAPI, ale MSDN zdaje się to potwierdzać. A przy okazji poprawki doprowadziłem kod do kompilacji pod mingw32. Nawet examples/send.exe działa. Co prawda połączenie jest synchroniczne i nie używa nowego resolvera, ale to już coś. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libpurple'owy fork - synchronizacja z upstream
Dnia 2011-10-24, pon o godzinie 13:49 +0200, Bartosz Brachaczek pisze: W dniu 24 października 2011 07:28 użytkownik Wojtek Kaniewski wojte...@toxygen.net napisał: No tak, API. To trzeba będzie zrobić warunek, że ustawienie GG_RESOLVER_CUSTOM powoduje użycie read(), a wbudowane recv(), mimo że w praktyce pewnie nikt nigdy nie korzystał z oryginalnego libgadu na Win32. Wówczas GG_RESOLVER_CUSTOM i tak nie będzie działać na Win32. Zdaje mi się, że jedyny sposób na zachowanie kompatybilności pod Unix-like to jednak ifdefy dla Win32 w tych dwóch, trzech miejscach w obsłudze resolvera w libgadu. Słuszna uwaga. Zrobiłem funkcję do czytania wyniku resolvera, żeby nie zaśmiecać kodu ifdefami. Teraz jest tylko w jednym miejscu. Może tak być? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libpurple'owy fork - synchronizacja z upstream
Dnia 2011-10-23, nie o godzinie 03:11 +0200, Bartosz Brachaczek pisze: Właściwie żeby móc polegać na errno, to trzeba by coś takiego zrobić dla wszystkich funkcji socketowych, tj. także socket(), bind(), accept() itd. Tak czy inaczej jest to mniej inwazyjna metoda niż gg_socket_errno() + gg_socket_strerror(). Jeśli nie masz czasu/ochoty, mogę się zmusić do zainstalowania cygwina i/lub Visual Studio Express. Ponadto z read()/write() vs recv()/send() jest jeszcze jeden problem. Mianowicie pipe'y w resolverze w forkach libpurple oraz Kadu są zrealizowane za pomocą socketów, a nie windowsowych pipe'ów. Nie sprawdzałem, czy to faktycznie konieczne, ale zgodnie z komentarzem do funkcji socket_pipe(), powodem jest niemożliwość wywołania select() na windowsowych pipe'ach. Jeśli tak ma zostać, to konieczna byłaby załączona łatka. Wolę dodać implementację socketpair() dla Win32 i mieć mniej #ifdefów, patrz r1192. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libpurple'owy fork - synchronizacja z upstream
Dnia 2011-10-21, pią o godzinie 01:31 +0200, Tomasz Wasilczyk pisze: W dniu 20 października 2011 23:16 użytkownik Wojtek Kaniewski wojte...@toxygen.net napisał: Bardzo dobrze, że usunąłeś ioctl(), bo ta funkcja zawierała kod zupełnie niezwiązany z libgadu. Nie wiem, do czego ona służy, ale libgadu ją wykorzystuje (src/common.c:267), a cygwin nie dostarcza. Jeśli jest FIONBIO, a nie ma ioctl() to prawdopodobnie powinniśmy użyć ioctlsocket(). Mógłbyś sprawdzić, czy dodanie #define ioctl ioctlsocket do network.h pomoże? Przeoczyłeś dwie zmiany, a brak ioctl rzuca błędem. Ponadto getsockopt jest pod windowsem chyba trochę inne (patrz pierwszy patch z gg_win32_getsockopt) i rzuca warningami o złym typie parametrów. Ostatni commit z send/recv też dodaje mnóstwo warningów o typowaniu. O ile cygwin sobie z tym poradzi, to pewnie MSVC++ będzie już miał z typami problem. Faktycznie, makra rzutujące się przydadzą. Dzięki za włączenie zmian, w tej chwili pidginowy fork na poziomie kodu źródłowego już praktycznie niczym się nie różni od wersji pierwotnej. Praktycznie, tzn. nazwy plików nagłówkowych internal.h, debug.h i config.h są zmienione, bo konfliktowały z tak samo nazwanymi plikami w Pidginie. Dziwne. libgadu jest kompilowane razem z pluginem, jako biblioteka statyczna czy może inaczej? Prawdopodobnie w libgadu mógł by się przydać resolver dla win32, który udało mi się wyciągnąć poza źródła libgadu dzięki dodaniu gg_global_set_custom_resolver. Bo w tej chwili windowsowe buildy będą bez żadnego. Ale to już nie jest istotne z punktu widzenia libpurple. Za to by się pewnie mogło przydać w Kadu. Ten resolver z Kadu wygląda sensownie, więc postaram się go dorzucić. - ktoś wspominał (nie pamiętam kto, rozmawiałem o tym parę miesięcy temu), żebym lepiej (wtedy) nie próbował implementować obsługi Mozilla NSS (obok GnuTLS i OpenSSL), bo będzie mocno przebudowywany kod z tym związany. Czy dobrze widzę, że to się już stało i mogę w jakiejś tam przyszłości do tego zacząć zaglądać? Pamiętam, że ktoś chciał się za to zabrać, ale jak zwykle nie mogę znaleźć maila. Przy trzeciej bibliotece SSL faktycznie dobrze by było jakoś to wydzielić, żeby kod nie był pocięty #ifdefami, ale jeśli chcesz się za to zabrać, to nie krępuj się. - ludzie od libpurple wspominali, że fajnie by było, jakby libgadu pozwalało przekazać obsługę połączeń aplikacji, żeby można było np. skorzystać z SOCKS proxy. Np. w taki sposób, jak to się udało z gg_global_set_custom_resolver. Domyślam się, że to jest związane z send/recv? Nie zagłębiałem się w temat, więc być może popełniłem w tym punkcie jakąś głupotę. Jesteś w stanie pokazać jakąś dokumentację libpurple dotyczącą obsługi SOCKS? Nie wiedząc czego oczekują, ciężko mi się wypowiedzieć :) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libpurple'owy fork - synchronizacja z upstream
Dnia 2011-10-20, czw o godzinie 22:10 +0200, Tomasz Wasilczyk pisze: (ciach) Odpowiem hurtowo. Bardzo dobrze, że usunąłeś ioctl(), bo ta funkcja zawierała kod zupełnie niezwiązany z libgadu. GG_CONFIG_HAVE_FORK jest wykrywane przez configure.ac. Zamieniłem compat.h na network.h, bo mimo ogólnej nazwy zawiera jedynie sieciowe rzeczy. Dodałem wykrywanie _Exit() w configure.ac. socklen_t, ssize_t +1. #pragma pack() była w __cplusplus, bo prawdopodobnie wcześniejsze próby kompilacji pod Win32 były przeprowadzane pod Visual C++. Jeśli chodzi o cygwinowy #ifdef, to prawdopodobnie chodziło o deklarację typów intX_t w sys/types.h, mimo że nie ma żadnego standardowego pliku nagłówkowego z intX_t. Ale skoro nie używamy intX_t, to można wyrzucić, bo to pochodziło z jakiegoś autoconfowego gotowca. Trochę poprawiłem Twoje zmiany i wrzuciłem w r1187. Będę wdzięczny za sprawdzenie, czy teraz trunk się kompiluje pod cygwinem. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Nieprawidłowe działanie gg_vsaprintf w niektórych konfiguracjach
Dnia 2011-10-12, śro o godzinie 01:41 +0200, Tomasz Wasilczyk pisze: Jeśli dobrze pamiętam, to na jakimś PowerPC można było użyć typu va_list tylko raz, dlatego jedna kopia była używana do określenia rozmiaru bufora, druga do właściwego vsnprintf(). Nie wiem, czy jest sens nadal utrzymywać taki kod. Zgaduję, że kombinacja PowerPC + non-C99 jest mieszanką wybuchową? ;) Wczoraj Jakub pozakonkursowo pokazał, że na x86_64 występuje ten sam problem, więc możliwe, że ta zmiana była ze względu na ppc64. To i informacja o Bartosza pokazuje, że utrzymywanie tego kodu ma jak najbardziej sens :) W każdym razie libgadu chyba już w ogóle nie działa pod PowerPC - szczegóły w tickecie z Adium: libgadu działa pod PowerPC, bo sam mam taką maszynę, z której dość często korzystam. Zgaduję, że występuje taki sam problem jak u Ciebie, tj. libpurple nie przeprowadza testów z oryginalnego configure.ac i nie wie, że dana maszyna jest big-endian. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [PATCH v2 04/13] Dla wiadomości przychodzących zawsze ustawiamy pole xhtml_message
Dnia 2011-09-01, czw o godzinie 02:58 +0200, Bartosz Brachaczek pisze: e-type = GG_EVENT_MSG; + memset(e-event, 0, sizeof(e-event)); e-type = (type != GG_RECV_OWN_MSG) ? GG_EVENT_MSG : GG_EVENT_MULTILOGON_MSG; + memset(e-event, 0, sizeof(e-event)); Pozwoliłem sobie te dwie linie usunąć. Struktura zdarzenia jest czyszczona w gg_watch_fd() zaraz po alokacji, więc wydaje mi się to niepotrzebne. Przeoczyłem coś? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [PATCH v2 00/13] Zmiany w obsłudze formatowanych wiadomości
Dnia 2011-09-04, nie o godzinie 17:52 +0200, Bartosz Brachaczek pisze: Hm, dziwne. Specjalnie wysyłałem serię za pomocą git send-email, żeby nie zepsuć formatowania. Zresztą wydaje mi się, że mailman pokazuje, że w łatkach są tabulacje[1]. Gdyby w przyszłości były jeszcze jakieś problemy z moimi łatkami, wysłanie poprawionych wersji nie stanowi dla mnie oczywiście żadnego problemu. W każdym razie dzięki za ich nałożenie :). Sprawdziłem dokładnie i faktycznie w mailach są tabulacje. Widocznie Evolution sknocił. Przy okazji przypominam, że ode mnie czeka jeszcze jedna mała łatka[2]. Racja, poprawiłem się. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Compile problem with libgadu 1.11.0 on Solaris
Dnia 2011-07-10, nie o godzinie 20:06 +0200, Dagobert Michelsen pisze: I am trying to compile libgadu 1.11.0 on Solaris 9 Sparc with Sun Studio 12 and there are some issues: - Binding 10 127.0.67.67 does not work on Solaris as the IP adress is usually no bound on the local machine. Using 127.0.0.1 works. Is there a specific reason why 127.0.67.67 is used in favor of the standard IP? The attached patch 0001 reverts this and is needed on Solaris. It could be shielded by a #if defined(__sun) if necessary. A different address was chosen because we bind to specific ports that may be already used on 127.0.0.1 and on Linux (well, at least in the distro I use) the whole 127.0.0.0/8 class is available on loopback interface. But I guess this doesn't justify the tests failing on Solaris. Especially that in trunk we bind to any available port. - The Makefile in tests/automatic unconditionally sets some gcc specific flags which confuse the (non-gcc) Sun Studio compiler. The flags could either be detected during autoconf time or probably dropped completely so the standard CFLAGS from the main autoconf is inherited. Patch 0002 removes it for Solaris for now. If you mean the -ggdb (I can't see any patches attached to your e-mail) then we can throw it away. Anyone who wants to debug the tests probably know how to add this. - There are tests failing which are probably due to wrong detected sizes of data types. However, I don't have enough insight to easily spot the point where this happens. The comparison looks like this: (...) Any advice on a fix would be nice. I guess that structures aren't packed. Look for #pragma pack and __attribute__((packed)) in include/libgadu.h.in. If either of these solutions can be used with Sun's C compiler, then you could add checking for __sun define. Or maybe there is some other way to enable structure packing? If needed I can provide you with an upstream account to our Solaris buildfarm: https://www.opencsw.org/extend-it/signup/to-upstream-maintainers/ Maybe we can do without it yet, but I'll keep that in mind, thanks. Regards, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Wątpliwość związana z SSL/TLS, wsparcie dla starych wersji GnuTLS
Dnia 2011-07-04, pon o godzinie 01:46 +0200, Tomasz Wasilczyk pisze: Czy to zamierzone, że libgadu nie wspiera starszych wersji GnuTLS (tzn nie posiadających funkcji gnutls_priority_set_direct)? W powyższym tickecie pojawił się prosty patch, który rozwiązuje problem, ale wymaga dodania do konfiguracji jednej stałej (w libpurple nazwanej HAVE_GNUTLS_PRIORITY_FUNCS). Nie było to zamierzone. Kod obsługi GnuTLS powstawał na bazie przykładów, które korzystały z dobrodziejstw najświeższego API, a potem był dostosowywany do serwerów Gadu-Gadu. Teraz już wiem, że wystarczy użyć gnutls_set_default_priority(). Poprawiłem, ale zanim wrzucę do repo chcę jeszcze przyjrzeć się kodowi GnuTLS, bo mam wrażenie, że Valgrind nigdy go jeszcze nie widział ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Neverending test...
Dnia 2011-06-19, nie o godzinie 17:19 +0200, Jakub Zawadzki pisze: Valgrind pokazuje jedynie parę ostrzeżeń - patrz załącznik. Poprawiłem, swoją drogą nieinicjowanie addr_count mogło prowadzić do SIGSEGVów? Raczej tak. Zaraz potem jest czytanie addr_count * sizeof() bajtów, więc może być nieciekawie. Ale jak to zwykle bywa z moimi odpowiedziami koło północy, mogłem nie doczytać i kompletnie się mylić ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Neverending test...
Dnia 2011-06-15, śro o godzinie 09:14 +0200, Marcin Owsiany pisze:
Są więc następujące pytania:
0) jak to cudo właściwie działa? :)
Forkuje się i w tle działa proces udający oryginalny serwer, a na
pierwszym planie działa proces testujący ponad sto scenariuszy łączenia
się z serwerem.
1) co spowodowało to akurat niepowodzenie testu?
Też chciałbym wiedzieć :) Jeśli masz możliwość odpalenia tego testu
ręcznie pod kontrolą gdb albo valgrinda, to byłbym wdzięczny za
backtrace. Przyznaję, że na 64-bitowym systemie testów nie puszczam.
2) jak zrobić żeby zrzut stosu dostawał się do logu?
To już kwestia glibc, nie wiem.
3) jak zrobić żeby przy podobnych błędach build nie zwisał w nieskończoność?
Zobacz, czy łata w załączniku pomoże.
Pozdr,
Wojtek
--- connect.c.orig 2011-06-15 23:25:21.0 +0200
+++ connect.c 2011-06-15 23:25:59.0 +0200
@@ -661,6 +661,7 @@
signal(SIGTERM, cleanup);
signal(SIGINT, cleanup);
signal(SIGQUIT, cleanup);
+ signal(SIGSEGV, cleanup);
signal(SIGALRM, sigalrm);
if (!server_pid) {
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Spostrzeżenia po porównaniu z libpurple'owym forkiem
Dnia 2011-06-05, nie o godzinie 12:44 +0200, Tomasz Wasilczyk pisze: Plik dcc.c:421 - zmienna uint16_t port jest przyrównywana do -1 (sypie warningiem w libpurple). Można by chociaż rzutować tą -1 na uint16_t. Ten kod i tak nie jest już pewnie przez nikogo używany do niczego sensownego, więc czego byśmy nie zrobili, nie będzie źle. Ale skoro zachęcaliśmy do podawania wartości -1, która zostanie automagicznie rzutowana na uint16_t, to rzutowanie przy porównaniu ma chyba najwięcej sensu. Dorzuciłem też komentarz o wynikającym z tego problemie z portem 65535, zgodnie z tym co napisał Jaku. Zamiast typu unsigned int można by było używać typów socklen_t i size_t (szczegóły w załączniku). To dotyczy prawdopodobnie większej ilości zmiennych. Jasne. Skoro i tak już używamy socklen_t w dcc7.c, to czemu nie. Commitnięte. Kompilacja pod Windows - libpurple wycina ifdefami część include-ów, aby całość ładnie się kompilowała pod tym systemem. Wiem, że libgadu nie ma oficjalnego wsparcia pod okienkami, ale parę ifdefów dużo nie popsuje ;]. Szczegóły w linku do dużego diffa z różnicami. Jeśli już, to wolałbym wpakować wszystkie sieciowe #include'y do nowego pliku network.h i tam zrobić #ifdefy tylko jeden raz. Plus zawartość compat.h, bo idealnie do sieciowych zależności by pasowało. Co Ty na to? Kompilacja pod SunOS i HPUX - jeden ifdef - szczegóły w załączniku. Nie lepiej naprawić to jakoś w configure? Wyjątku dla cygwina też bym się chętnie pozbył, ale nawet nie pamiętam dlaczego się tam pojawił. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.11.0
Dużo zmian API się nazbierało w repozytorium, więc tym razem podbijamy środkową liczbę i dedykujemy wydanie ekipie Kadu. * Import i eksport listy kontaktów zgodnej z Gadu-Gadu 10 (dodaje zależność od zlib) * Poprawione zarządzanie adresami i portami przy połączeniach bezpośrednich. * Nowa funkcja do sprawdzania czy biblioteka obsługuje daną funkcjonalność. * Dokładniejsze raportowanie powodu nieudanego połączenia. * Poprawione potwierdzenie otrzymania wiadomości. * Poprawiona konwersja wiadomości HTML na czysty tekst. Szczegóły pod adresem http://toxygen.net/libgadu/releases/1.11.0.html Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Bug w komunikacji z hubem
Dnia 2011-05-12, czw o godzinie 15:29 +0200, Tomasz Wasilczyk pisze: znalazłem małego buga w kodzie odpowiadającym za pobranie adresu serwera z huba. Mianowicie, jeżeli wystąpi błąd w połączeniu, libgadu zinterpretuje to, co dostanie jako adres serwera. Jeżeli więc nic nie dostanie, będzie próbował szukać adresu hosta , lub łączyć się z 255.255.255.255. Łatę zmieniłem odrobinę, żeby zwracała błąd niedostępnego serwera (czyli błąd wynika z tego, co serwer wysłał) zamiast błędu połączenia z nim. Inny problem związany z tym ticketem: gg_read_line() otrzymało z funkcji read() odpowiedź 11, czyli EAGAIN. W związku z tym powinien próbować dalej, a nie wchodzić do ifa error on read. Ktoś mi może to wytłumaczyć? Gdzieś wyczytałem, że prawdziwe wartości błędów są przeciwnego znaku, ale w tym logu kod błędu był przecież dodatni. Tutaj już Jakub wyjaśnił. Rozwiązanie z ignorowaniem EAGAIN jest głupie, bo aplikacja niepotrzebnie się kręci w pętli, ale póki co, działa. I jeszcze jedna uwaga: z tego, co widzę, to libgadu nie pozwala odróżnić problemów z hubem od problemów z połączaniem z serwerem docelowym. Można by było wtedy w razie problemów z hubem łączyć się np. z ostatnim zapamiętanym przez aplikację serwerem. A może coś takiego już jest, tylko ja tego nie widzę? Dodatkowy kod błędu GG_FAILURE_COŚTAM_HUB by Ci wystarczył? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Wiadomości przychodzące i zamiana HTML-a na czysty tekst
Dnia 2011-05-11, śro o godzinie 14:57 +0200, Bartosz Brachaczek pisze: (...) Trudno mi sobie wyobrazić, jak w rozsądny sposób można by dostosować do takiego przypadku funkcję gg_message_html_to_text(), więc moje pytanie brzmi, dlaczego właściwie libgadu dokonuje konwersji HTML-a do czystego tekstu, zamiast wziąć to, co wysłał rozmówca? Dlatego, że w HTML-u jest unikod, w czystym tekście CP1250. Idea była taka, żeby dowolny klient mógł się posługiwać unikodem bez konieczności parsowania HTML-a, ustawiając jedynie odpowiednie kodowanie. Jedyne wyjście to chyba parsowanie HTML-a na tyle, na ile jest to potrzebne do zapewnienia zgodności ze starym parsowaniem, tj. b, u, i, img i atrybut color w span. Myślicie, że wystarczy parsowanie jedynie tych tagów, żeby tylko zapewnić zgodność z Gadu-Gadu 10 i samym libgadu? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Propozycja zmian w obsłudze przesyłania formatowanych wiadomości HTML
Dnia 2011-05-11, śro o godzinie 16:05 +0200, Bartosz Brachaczek pisze: 1. Stripować nieprzewidzanie przez protokół znaczniki HTML w odebranych wiadomościach (np. script zamieniać na lt;scriptgt;). Nie rozumiem dlaczego w ogóle mielibyśmy w cokolwiek ingerować. Jeśli ktoś będzie chciał napisać dwa boty, które przesyłają między sobą MathML-a albo tunelować XMPP to nie powinniśmy mu przeszkadzać. 2. Jeśli otrzymujemy tylko wiadomość czystym tekstem, konwertować ją do HTML-a. Tutaj widzę, że jest właściwie gotowa funkcja do tego celu. Jak najbardziej. Do zrobienia w parę minut. Trzeba tylko pamiętać o tym, żeby to samo zaimplementować w gg_session_handle_recv_msg(). 3. Dodać możliwość wysyłania wiadomości poprzez podanie tylko HTML-a - libgadu zajęło by się przekonwertowaniem go do czystego tekstu z atrybutami formatowania. Pytanie tylko, jak takie funkcje mogłoby się nazywać? Patrz wcześniejszy wątek. Trzeba rozszerzyć funkcję gg_message_html_to_text() tak, żeby zwracała też atrybuty. Jeśli chcesz zaimplementować powyższe, to daj znać, żebym niepotrzebnie się za to nie zabierał. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Brak spójności w obsłudze błędów połączenia szyfrowanego
Dnia 2011-04-30, sob o godzinie 16:24 +0200, Tomasz Wasilczyk pisze: Może być tak, że ustawienie gg_login_params.tls na 1 (GG_SSL_ENABLED) będzie się zachowywać jak do tej pory, a ustawienie na 2 (GG_SSL_REQUIRED) będzie zwracało błąd, jeśli nie ma wkompilowanej obsługi SSL? Brzmi nawet rozsądnie, ale fajnie by było, gdyby dało się odróżnić taki błąd związany z ssl od innych - Pidgin ma osobny komunikat w przypadku braku ssl. Można to zrobić (tak sugerowano na kanale Pidgina) dodając do API funkcję np. gg_is_ssl_supported(), która by zwracała wartość (GG_CONFIG_HAVE_GNUTLS || GG_CONFIG_HAVE_OPENSSL). Zwracany błąd to ENOSYS, który łatwo odróżnić od reszty, ale skoro dodawałem funkcję do sprawdzania czy mamy zlib, wrzuciłem to wszystko do jednego worka o nazwie gg_libgadu_check_feature(). No i w przypadku, w którym obsługa ssl jest wkompilowana, ale coś jest nie tak z biblioteką gnutls lub systemem (np. mi teraz cały czas sypie błędami internal error), to po nieudanej próbie połączenia przez ssl, mógłby (oczywiście w trybie GG_SSL_ENABLED) próbować połączyć się jeszcze raz bez szyfrowania. Można zrobić coś takiego, ale za jakiś czas, jak już nowy kod obsługi łączenia się z serwerem zostanie zmergowany, bo nie chcę rozgrzebywać aktualnego, który i tak wyleci za jakiś bliżej nieokreślony czas. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [PATCH 0/5] Obsługa eksportu i importu listy kontaktów Nowego Gadu-Gadu
Dnia 2011-05-05, czw o godzinie 23:08 +0200, Bartosz Brachaczek pisze: Mały update dokumentacji protokołu był od początku częścią tej serii łatek i, jak widzę, również został dzisiaj wrzucony. :) Wrzuciłem Twoje poprawki do repo. Pozwoliłem sobie przenieść funkcje kompresji do osobnego pliku, żeby nie dokładać do common.c kolejnych gratów. Dodałem wykrywanie zlib do configure.ac. Z tego względu, że kolejne wydanie będzie jeszcze ,,minorem'' i nie możemy nagle zacząć _wymagać_ zlib, biblioteka skompiluje się bez zlib w systemie, ale funkcje związane z listą kontaktów będą zwracać błędy. Żeby ustrzec się przed czymś takim można zawołać nową funkcję gg_libgadu_check_feature(GG_LIBGADU_FEATURE_USERLIST100). Jeśli są uwagi co do nazewnictwa, najlepiej zgłaszać je zanim Kadu zacznie używać nowych symboli ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Funkcja gg_read_line()
Dnia 2011-04-23, sob o godzinie 01:16 +0200, Bartosz Brachaczek pisze: Przeglądając kod libgadu, natrafiłem na niezgodny z faktycznym działaniem opis funkcji gg_read_line(). Dokumentacja mówi, że w przypadku powodzenia zwraca ona buf, podczas gdy w rzeczywistości zwraca ona miejsce w buf wskazujące na Null-a. Jednak libgadu nigdzie w kodzie nie polega na znaczeniu wskaźnika zwracanego przez tę funkcję, więc jest to sprawa raczej kosmetyczna. Ta funkcja i tak prędzej czy później zniknie (na gałęzi new-api nie jest używana), więc nie ma sensu jej naprawiać, a co najwyżej poprawić dokumentację. I tak też zrobiłem. Natomiast drugą rzeczą, jaka rzuciła mi się w oczy co do tej funkcji, jest zwracanie NULL w przypadku gdy ret == 0, czyli gdy read() napotka na EOF. Wydaje mi się, że EOF w tym przypadku nie jest błędem i można spokojnie zwrócić buf. Ta funkcja jest używana do nagłówków HTTP, a tam zamknięcie połączenia zwykle nie jest niczym dobrym ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Łatka dodająca wsparcie dla GG_USERLIST100_VERSION
Dnia 2011-04-16, sob o godzinie 13:24 +0200, Rafał Malinowski pisze: Nowa wersją łatki w załączniku. Już w repo, dzięki. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] DCC7 - implementacja wysyłania plików przez serwer.
Dnia 2011-04-15, pią o godzinie 13:55 +0200, Rafał Malinowski pisze: Mam pewien problem z opisem protokołu :) Konkretnie z tym działem: http://toxygen.net/libgadu/protocol/#ch3.4 i z opisem przeplatanki GG_DCC7_INFO z pobieraniem adresu serwera pośredniczącego. Jeżeli dobrze rozumiem, to w tym momencie libgadu powinno wykonywać równocześnie 2 połączenia: - na głównym sockecie wysłać informacje na temat GG_DCC7_INFO - na nowo otwarytym sockecie DCC łaczyć się z relayem i odebrać adres serwera? Próbowałem wczoraj to zaimplementować, jednak nie rozumiem jeszcze zbyt dobrze kodu libgadu i nie wiem jak otworzyć równocześnie drugie połączenie. Być może należałoby to rozwiązać w ten sposób, że po wysłaniu GG_DCC7_INFO powinienem otworzyć nowy socket DCC i odebrać relaya i przekazać go jako DCC_PENDING do klienta (Kadu), żeby on już sobie na nim gg_dcc7_watch_fd robił? Niestety obsługa DCC7 w oryginalnym kliencie się trochę skomplikowała. Kiedyś wyglądało to mniej więcej tak, że jedna strona najpierw otwierała gniazdo, wysyłała GG_DCC7_INFO i czekała na połączenie. Druga strona po otrzymaniu adresu i portu próbowała się połączyć, ale jeśli się nie udało, to sama otwierała gniazdo i wysyłała do inicjującego. Dopiero jeśli to się nie udało, zaczynało się połączenie przez serwer. Z tego co widzę, teraz obie strony od razu otwierają gniazda, wysyłają GG_DCC7_INFO _oraz_ zaczynają gadanie z serwerem pośredniczącym. Nie pasuje to w ogóle do architektury libgadu, gdzie jedno połączenie rządzi jednym deskryptorem. Powoduje to problemy w komunikacji libgadu z GG10, gdy libgadu najpierw wysyła GG_DCC7_INFO z namiarami na otwarty port, ale gdy otrzyma te informacje od drugiej strony, zamyka swoje gniazdo i łączy się z podanym. GG10 czasami pokazuje, że połączenie anulowano, co wygląda na wyścig związany z zamykaniem gniazda, z którym GG10 zdążyło się już połączyć. Jeśli do tego jeszcze dodać połączenie przez serwer... robi się trochę skomplikowanie. Macie może jakieś pomysły jak to rozwiązać w inny sposób niż dodanie pól .fd2 i .fd3 w strukturze gg_dcc7? ;) Wcześnie myślałem o tym, żeby po otrzymaniu GG_DCC7_INFO nie zamykać lokalnego gniazda, ale do .fd wrzucić deskryptor połączenia do drugiej strony z timeout = 1 i soft_timeout = 1, co pozwoliłoby nam z sekundowym opóźnieniem obsłużyć połączenia przychodzące. Tyle, że trzymanie się API na siłę takim kosztem chyba nie ma sensu. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Pole client_name
W dniu 01.03.2011 00:28, Rafał Malinowski pisze: Załączam patch, który działa, ale pewnie łamie jakieś zasady wstecznej kompatybilności ;) Proszę o wskazówki, jak ich nie łamać. Myślałem o tym wcześniej i mam mieszane uczucia. Z jednej strony moglibyśmy sprawdzać, czy client_version zaczyna się od cyfry. Jeśli tak, to zachowujemy się tak jak do tej pory i doklejamy Gadu-Gadu Client Build . Jeśli nie, to przekazujemy całość, ale bawimy się w parsowanie, żeby przesłać wersję do huba. Z drugiej strony nie jest to najbardziej intuicyjne. Ktoś za, ktoś przeciw? Tak czy inaczej, w Twoim patchu brakuje katalogu include. I lepiej IMHO by było, gdyby biblioteka sama doklejała spację między client_name i client_version, bo to, że trzeba dodać spację, nie jest zbyt oczywiste. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Protokół GG- gg_notify i tyl ko dwie odpowiedzi
W dniu 28.12.2010 19:11, Michał Nykiel pisze: Ile tych struktur bym nie wysłał, w odpowiedzi tylko dwie. Natomiast dostaję powiadomienia o zmianach statusu każdego z numerów jakie wysłałem. Dlaczego tak się dzieje? Sprawdź, czy Twój kompilator nie wyrównuje rozmiaru struktury gg_notify do ośmiu bajtów. Gdyby tak się działo, pierwsza struktura pewnie byłaby poprawna, ale kolejne już by się rozjechały. Najprościej zmienić sizeof(not) na 5 i zobaczyć, czy będzie lepiej. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Resend: [ekg-users] statycz na analiza kodu libgadu/ekg z użyciem clang
W dniu 30.11.2010 21:56, Piotr Galiszewski pisze: Dzisiaj w Kadu otrzymaliśmy pierwsze zgłoszenie [1], o dziwnym wysypie programu po aktualizacji libgadu to wersji 1.9.1. Problem ten dotyczy zarówno najnowszych wersji testowych kadu, jak i starszych wersji stabilnych. Otrzymaliśmy również potwierdzenie, że patch o którym jest tutaj mowa rozwiązuje to zagadnienie. Niestety ten patch nie powinien mieć najmniejszego wpływu na wysypywanie się w gg_event_free() tam, gdzie zwalniane jest pole xhtml_message. Wydaje mi się, że to zbieg okoliczności i/lub inne zachowanie kodu po ręcznej kompilacji. Czy jest możliwość złapania wiadomości, która wywala Kadu? Najlepiej w postaci zrzutu pakietu, który wyrzuca libgadu, ale może też być czysty tekst plus HTML. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0
W dniu 10.05.2010 16:12, Marcin Owsiany pisze: Ponad pół roku powinno wystarczyć na ustabilizowanie nowego wydania, więc najwyższy czas na oficjalną wersję 1.9.0. Zmiany względem gałęzi 1.8 już dawno przestały być nowościami, ale i tak wypada podać: Hm, czy nie powinna być podbita wersja API? Np. ze względu na dodanie gg_typing_notification(). 1.9.0 ma wersję o jeden większą względem 1.8.2, ale dzięki za przypomnienie :) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r958 - in trunk: docs include src test/protocol/tests
Marcin Owsiany pisze: +sess-status_flags = 0x0081; Może by to wyrazić jako sumę symbolicznych flag? Jasne, tak powinno być od początku :) w. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] linkowanie z openssl
Dominik 'Rathann' Mierzejewski pisze: Fakt, że libgadu linkuje openssl sprawia kłopoty licencyjne aplikacjom, które używają libgadu i są na licencji GPL (pidgin, ekg2, gg2). Czy dałoby się dodać obsługę np. gnutls? Mam to ma mojej liście TODO, ale póki co, to nie ma sensu. O ile mi wiadomo, w chwili obecnej serwery i tak nie obsługują SSL/TLS, więc ten kod nie jest nikomu do niczego potrzebny. Po prostu w specu nie włączaj (albo wyłączaj) obsługę OpenSSL, o ile już tego nie robisz. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.9.0-rc2
Lista zmian względem 1.9.0-rc1: * Poprawiona obsługa UTF-8: wysyłanie i odbieranie wiadomości powinno już zawierać coś więcej niż CP1250. * Operacje na katalogu publicznym działają poprawnie w UTF-8. * Uaktualnione skrypty testowe. * Uaktualnione przykładowe aplikacje. Szczegóły pod adresem http://toxygen.net/libgadu/releases/1.9.0-rc2.html Pozdrawiam, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [mar...@owsiany.pl: Re: [libgadu-commit] r870 - branches/1.9/docs]
Marcin Owsiany pisze: -# Only try to generate documentation if it is not already there. # Do not fail if doxygen is not available. -html: ../include/libgadu.h -test -d html || if doxygen --version /dev/null; then doxygen; fi +html-stamp: ../include/libgadu.h $(wildcard ../src/*.c) $(wildcard *.dox) +if doxygen --version /dev/null; then if doxygen; then touch html-stamp; fi; fi Teraz jeśli doxygen się przewróci przy generowaniu dokumentacji, to make nie zauważy. :-/ Racja. W r871 powinno być lepiej. Tak może być? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [mar...@owsiany.pl: Re: [libgadu-commit] r870 - branches/1.9/docs]
Marcin Owsiany pisze: Elegancko, ale bije po oczach ta kombinacja no-op + touch html-stamp :) Poprawiłem @DOXYGEN@ na $(DOXYGEN). Nawet jeśli go nie ma, będzie wiadomo o co chodzi. Może zamiast ustawiać DOXYGEN na : zrobić żeby make nie wchodził w ogóle do podkatalogu docs? Mówisz, masz. Też o tym myślałem, ale jakoś nie miałem motywacji ;) Czy ten html-stamp jest do czegoś potrzebny w innym miejscu? Tylko do porównania czy pliki źródłowe dokumentacji się nie zmieniły od czasu ostatniej rundy doxygena. Niestety make nie za bardzo chce porównywać timestampy katalogów. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0 SVN a obsługa GG8
Krzysztof Klinikowski pisze: Okej. Zaraz sprawdzę czy wszystko działa i w razie błędów napisze tutaj. Mam jeszcze pytanie dotyczące tego UTF8. Czy UTF jest tylko dla wiadomości i statusów czy wyszukiwanie użytkowników i rejestracja konta też już używa UTF8? Poprawiłem obsługę katalogu publicznego, żeby przyjmowała i zwracała UTF-8, jeśli tak jest ustawione. Svn up. Jeśli chodzi o rejestrację, to ani w adresach e-mail, ani w hasłach nie spotyka się polskich krzaczków zbyt często, więc ciężko mi odpowiedzieć. W każdym razie zarówno funkcje rejestracji, jak i liczące hash hasła mają w nosie kodowanie. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0 SVN a obsługa GG8
Krzysztof Klinikowski pisze: Okej. Wydaje mi się, że to działa ale problem powstaje teraz inny. Mam coś takiego do przy odbieraniu statusów innych użytkowników: (...) Kiedyś używając tego kodu dostawałem jako statusy liczby rzędu 0 - 5 z tego co pamiętam lecz teraz są one bardzo duże: (14:31:46) *gg:* status60: (13643147) status=16389; version=0; descr=I od dzisiaj wynajęty morderca ma pilnować drogi do mojego serca Czy to normalne? Być może to ja zrobiłem coś żle a może to błąd w libgadu? W każdym razie w login params dodałem: glp-protocol_features = (GG_FEATURE_STATUS80|GG_FEATURE_DND_FFC); I od tego czasu statusy osiągają właśnie aż tak duże liczy. Czy to normalne? Poprawiłem to. Makro GG_FEATURE_DND_FFC oprócz nowych statusów włączało też opsy graficzne, które przy okazji zmieniają sposób przesyłania informacji o tym, że jest status z opisem. Powinno być już lepiej. Oczywiście jeśli ktoś sobie życzy flagi 0x4000, powinien dodać do .protocol_features wartość GG_FEATURE_IMAGE_DESCR. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [libgadu-commit] r845 - in branches/new-api/test: automatic manual
Marcin Owsiany pisze: Czy mógłbyś napisać parę słów na temat tego jak odpalać te testy? Jeśli są jakieś które mogą działać automatycznie bez dostępu do sieci, to chętnie włączyłbym wykonywanie ich przy kompilacji pakietu (w Debianie jest 16 architektur, więc byłyby odpalane na każdej z nich). Co prawda wspomniany commit dotyczył gałęzi new-api, ale w 1.9 można automatycznie odpalać: - connect - sprawdza logikę łączenia się z serwerem w zależności od konfurację, weryfikuje reakcję biblioteki na błędy itd. - protocol - sprawdza czy biblioteka wysyła poprawne dane po wywołaniu poszczególnych funkcji i czy dla różnych danych wejściowych zgłasza poprawne zdarzenia, - resolver - sprawdza czy dla różnych konfiguracji resolvera wszystko działa jak trzeba. Testy connect i resolver opierają się na przesłanianiu libcowych funkcji i oryginały wołają za pomocą funkcji z przedrostkiem __, co działa na Linuksie, ale nie wiem czy zadziała w Debian/FreeBSD. Connect działa dłuuugo ze względu na to, że testuje m.in. reakcję libgadu na timeouty połączeń. Resolver zakłada, że pthread jest dostępne. Protocol nie jest jeszcze uaktualniony do zmian w bibliotece, więc na pewno się wywala. Zostanie poprawiony przed wydaniem 1.9.0. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Parę łatek dot. autostuff i wywoływania doxygen
Dnia 2009-10-03, sob o godzinie 15:42 +0100, Marcin Owsiany pisze: Przesyłam kilka łatek jak w temacie. Jeśli nie będzie sprzeciwu to commitnę dziś wieczorem lub jutro. Nie krępuj się :) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0-rc1
Dnia 2009-10-03, sob o godzinie 14:37 +0200, Jakub Zawadzki pisze: O, dobrze wiedzieć bo na moim laptopie (gdzie mam stripnięte symbole): nm: /bin/cat: no symbols nm -D Swoją drogą po coś takiego chyba wymyślono wersjonowanie symboli? (nie wiem jak to się fachowo nazywa, chodzi mi o np. time@@GLIBC_2.2.5) Już chyba łatwiej zachować poprzedni wariant funkcji niż się w to bawić ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0-rc1
Dnia 2009-10-01, czw o godzinie 09:05 +0100, Marcin Owsiany pisze: gg_gethostbyname() zostało przeniesione do resolver.h, więc zniknęło z API. Niby symbol został, ale ABI się zmieniło, bo zmieniła się sygnatura funkcji. (zwracany typ danych pointer-int, dodane parametry) Patch Jakuba trafił do repozytorium. Poza tym, dodałem -export-symbols dla biblioteki dzielonej, żeby nowe funkcji, jak np. ten workaround z gg_gethostbyname() nie wydostawały się na zewnątrz i nie wymuszały tworzenia stubów nikomu niepotrzebnych, ale figuruących w ABI funkcji. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0-rc1
Dnia 2009-10-01, czw o godzinie 12:33 +0100, Marcin Owsiany pisze: Przy okazji dodałem GG_OBSOLETE (w gcc __attribute__ ((deprecated)) ) O, to jest dobre choćby dzięki temu że wiadomo będzie co wyleci w przyszłości. A jaki to ma wpływ na binarkę? Żaden. ZTCW to daje tylko ostrzeżenie kompilatora. Acha, jeśli merge-ujecie zmiany pomiędzy trunk/1.9 to wygodnie byłoby, gdyby w commit message pojawiło się coś poza numerem zmiany źródłowej. Postaram się. Pewnie łatwiej by było z subversion 1.5 i jego rejestracją merge'y, ale póki jestem fizycznie ~500km od serwera, brakuje mi odwagi na upgrade do Lenny'ego. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0-rc1
Marcin Owsiany pisze: Zakładając, że funkcje T gg_resolve T gg_resolve_pthread T gg_resolve_pthread_cleanup nie były w publicznym API, to nie. O, usunięcia tych funkcji nawet nie zauważyłem. Jeśli zostały by usunięte z API, to powinno to pociągnąć za sobą podbicie numeru _ABI_. Funkcje są opisane jako wewnętrzne (doxygenowy tag \internal), więc jeśli ktoś z nich korzystał, to musi się liczyć z problemami. Ale na wszelki wypadek dodam stuby. Dominik, dzięki za zwrócenie uwagi :) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] libgadu 1.9.0-rc1
Marcin Owsiany pisze: Czy powyższe nie powinno spowodować podbicia numeru API? Możliwe, że nadal nie rozumiem numeracji bibliotek dzielonych a'la libtool, ale czy zmiana z 3.9.0 do 3.10.0 to za mało? w. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Problem z połączeniem (libg adu 1.8.2)
Mietek Bąk pisze: Od pewnego czasu mój program (bramka GG/XMPP) przestał się łączyć z serwerami GG. Kod błędu to GG_FAILURE_CONNECTING, ale zupełnie nie rozumiem przyczyny. Czy mógłbym prosić o pomoc? Załączam wyciąg z informacji odpluskwiania: // gg_read_line() error on read (errno=11, Resource temporarily unavailable) Mógłbyś pobrać najświeższą wersję z głównej gałęzi repozytorium i sprawdzić, czy będzie się zachowywać lepiej? Jeśli tak będzie, dorzucę to do 1.9.0-rcX. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] libgadu 1.9.0-rc1
Sporo czasu minęło, sporo zmian w świecie Gadu-Gadu zaszło, więc wypada w końcu coś z tym zrobić. Lista zmian: * Podstawowa obsługa protokołu Nowego Gadu-Gadu, a co za tym idzie, wiadomości i opisy kodowane w UTF-8. Domyślnie biblioteka nadal przekazuje do aplikacji i spodziewa się od niej tekstów w CP1250, ale pole encoding struktury gg_login_params pozwala zmienić kodowanie na UTF-8. Uwaga! Kodowanie danych innych niż wiadomości i opisy pozostaje w CP1250. * Ponieważ nowy klient przekazuje wiadomości w dwóch formatach — czysty tekst plus atrybuty i HTML, dodano pole xhtml_message do struktury gg_event_msg. Niestety, nie można jeszcze wysyłać wiadomości w tym formacie. * Razem z nowym protokołem przyszły nowe statusy: GG_STATUS_FFC, GG_STATUS_FFC_DESCR, GG_STATUS_DND i GG_STATUS_DND_DESCR. * Aplikacja może sama wybrać sposób rozwiązywania nazw serwerów — przy użyciu procesu, wątku lub we własny sposób. Można to zrobić za pomocą pola resolver_type struktury gg_login_params dla procesów i wątków, lub globalnie za pomocą funkcji gg_global_set_resolver czy gg_global_set_custom_resolver. * Dokumentacja i programy testowe trafiły do dystrybucji. Szczegóły pod adresem http://toxygen.net/libgadu/releases/1.9.0-rc1.html Ponieważ to wersja Release Candidate, jest bardzo prawdopodobne, że znajdą się głupie/paskudne/wstydliwe błędy. Możliwe, że na systemach nie-linuksowych pojawią się problemy z testami. Bardzo proszę takie informacje zgłaszać. Pozdrawiam, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [ekg-users] błąd kompilac ji (Solaris)
Szymon Zygmunt pisze: Pociągniemy ten temat dalej? Chętnie pomogę znaleźć przyczynę tego błędu. Dodatkowo od pewnego czasu na tym Solarisie mam problem z automatycznym połączeniem się z serwerem - muszę ustawiać zmienną protocol (http://lists.ziew.org/pipermail/ekg-users/2009-June/007793.html). Dzięki uprzejmości Gophiego próbowałem skompilować libgadu na Solarisie i wszystko poszło bez problemu. Możliwe, że to kwestia shella, bo tutaj domyślnym był bash. Jeśli masz jeszcze cierpliwość, spróbujmy zacząć od początku. Napisz jakie zmiany wprowadzasz (CONFIG_SHELL itd.) i podeślij logi z błędami, które u Ciebie występują. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [ekg-users] błąd kompilac ji (Solaris)
Adam Wysocki pisze: [go...@sloneczko ~]$ uname -a SunOS sloneczko 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-5_10 Taka może być? Nie pogardzę ;) Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [ekg-users] błąd kompilac ji (Solaris)
Szymon Zygmunt pisze: Pociągniemy ten temat dalej? Chętnie pomogę znaleźć przyczynę tego błędu. Dodatkowo od pewnego czasu na tym Solarisie mam problem z automatycznym połączeniem się z serwerem - muszę ustawiać zmienną protocol (http://lists.ziew.org/pipermail/ekg-users/2009-June/007793.html). Niestety brakuje mi pomysłów, a dostępu do żadnej maszyny z Solarisem sam nie mam, żeby podłubać we wnętrznościach skryptów :( Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] [ekg-users] błąd kompilac ji (Solaris)
Adam Wysocki pisze: Jeżeli chcesz dobrze to możnaby się dowiedzieć czemu wersja nie jest ustawiana - to problem z libgadu, dlatego wysyłam też na libgadu-devel. Nie zmieniałeś nic w pliku configure.ac (w libgadu)? (...) Fakt, że to trochę niestandardowe użycie autoconfa, ale prawie wszędzie działa. Szymon, jeśli masz basha na tej maszynie, mógłbyś na próbę zmienić na początku skryptu configure zmienić /bin/sh na /bin/bash? w. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] błąd kompilacji na sunie
On Tue, Jun 16, 2009 at 01:42:48PM +0200, Szymon Zygmunt wrote: resolver.c: In function `gg_gethostbyname': resolver.c:107: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type resolver.c:107: error: too many arguments to function `gethostbyname_r' resolver.c:107: warning: assignment makes integer from pointer without a cast Mógłbyś podesłać stronę manuala dla gethostbyname_r, jeśli takowa jest zainstalowana w tym systemie? Najwyraźniej implementacje z glibc i sunowych bibliotek się róźnią. resolver.c: In function `gg_resolver_fork_start': resolver.c:230: error: `INADDR_NONE' undeclared (first use in this function) resolver.c:230: error: (Each undeclared identifier is reported only once resolver.c:230: error: for each function it appears in.) Poprawiłem przed chwilą w repozytorium. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] błąd kompilacji na sunie
On Tue, Jun 16, 2009 at 02:04:50PM +0200, Wojtek Kaniewski wrote: Mógłbyś podesłać stronę manuala dla gethostbyname_r, jeśli takowa jest zainstalowana w tym systemie? Najwyraźniej implementacje z glibc i sunowych bibliotek się róźnią. ...a póki co, poszła tymczasowa poprawka, która powinna pomóc w kompilacji. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] błąd kompilacji na sunie
Szymon Zygmunt pisze: Libgadu się skompilowało, ale musiałem zrobić to: http://lists.ziew.org/pipermail/libgadu-devel/2008-August/000309.html Czy da się to jakoś poprawić na stałe, żeby nie trzeba było ręcznie za każdą kompilacją? Spróbuj teraz. Poprawiłem to wcześniej, ale umknął mi jeszcze jeden program, który korzysta z linuksizmów. Poza tym, poprawiłem już obsługę gethostbyname_r() zamiast wyłączać to na Sunach, więc byłbym wdzięczny, gdybyś sprawdził, czy libgadu nadal umie się połączyć :) Nie działa natomiast 'make install': http://lists.ziew.org/pipermail/libgadu-devel/2008-August/000314.html Nie wiem jak to zrobić, zwykłe przełączenie się na bash nie pomaga. Ew. co mam przekopiować ręcznie abym potem mógł skompilować ekg. Możliwe, że pomoże coś takiego: CONFIG_SHELL=/bin/bash ./configure ... Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] GG8 - Logowanie
wit...@ravir.pl pisze: Witam. Dzięki za poprawienie tego opisu. Jak już mówiłem tłumaczę sobie wszystko na Delphi. Do szyfrowania używam biblioteki DCPCrypt. Mój kod wygląda tak (właściwie to cała procedura szyfrująca testowa) (...) Nie pisałem już w Pascalopodobnych od ładnych paru lat, więc mogę pisać głupoty. Po pierwsze, spróbuj UpdateStr() zamiast Update(). A nuż Update() bierze wskaźnik, a nie to, co jest pod nim? Po drugie, może w drugą stronę, dać @Seed w drugiej linii? Poza tym, hashe zawsze wychodzą te same? Czy jeśli dodasz jakieś zmienne lokalne w okolicy Haslo, wynik nie zmienia się? Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] GG8 - Logowanie
wit...@ravir.pl pisze: Postanowilem skodzic obsługe GG8 w Delphi. Od kilku juz dni meczee sie z logowaniem. Nie wiem dokladnie w czym jest problem - tylko przypuszczam. Gadu po wyslaniu pakietu logowania (0x0031) zawsze zwraca mi 9 - login failed. Wysnifowalem oryginalny klient i porownalem z moim i stwierdzilem, ze Nowe GG za kazdym razem przesyla inny klucz SHA, czyli pewnie go soli? Tylko w jaki sposob. Oblecialem caly internet w poszukiwaniu seedowania, solenia itd. hashy SHA-1. Wszedzie wspomina sie jedynie o hashowaniu hasla i soli jako jeden ciag. Jedyne co znalazlem to w LibGadu modul, ktory uwzglednia wlasnie ziarno, tyle ze po utworzeniu DLLa i podczepieniu do Delphi (bo robie to w Delphi) - też mi nie generuje tego samego hasha co GG8 - spisalem sobie ziarno, ktore wyslalo Nowe GG i wytestowalem je w kilku roznych probach. Żadne nie jest takie jak poiwnno byc, tak wiec jak solic SHA-1? Faktycznie, opis protokołu nie jest zbyt dokładny w tej kwestii. Funkcji liczącej skrót SHA-1 najpierw podaje się hasło, potem ziarno. Dodałem to do opisu, mam nadzieję, że to odrobinę rozjaśni. A jeśli tak właśnie robisz, to najlepiej by było, gdybyś pokazał kawałek kodu. Może coś się rzuci w oczy. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] GG_DISCONNECTING2 i znikający opis
Adam Osuchowski pisze: Piszę o tym tutaj, bo nie wiem czy to jest kwestia samej biblioteki czy klienta. Z jednej strony, pętla obsługi zdarzeń jest kodowana w kliencie, więc to on powinien czekać na ew. pakiety od serwera, ale z drugiej strony, to zachowanie jest związane ze specyfiką protokołu, którego szczegółami zajmuje się libgadu. Decyzja, gdzie to poprawić, należy do developerów. Rodząca się w bólach nowa gałąź libgadu przewiduje już coś takiego -- funkcja gg_session_disconnect() przyjmuje parametr, który mówi o tym, czy zwlekamy z rozłączeniem i czekamy na potwierdzenie, czy może od razu dajemy sobie z tym spokój. Co do aktualnej gałęzi, dodałem obsługę pakietu GG_DISCONNECT_ACK (były GG_DISCONNECTING2), która przekazuje to do aplikacji. Jeśli aplikacja chce mieć pewność, że wszystko będzie w porządku, powinna zawołać gg_change_status_descr(), poczekać na odpowiednie zdarzenie i dopiero wtedy zerwać połączenie. Pozdr, Wojtek ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Dcc7 - odbieranie plików od osoby za NAT
Rafal Malinowski pisze: Dla wersji 0.6.6 Kadu postanowiłem poczynić pewne poprawki z naszym prawie- nigdy-nie-działającym kodem obsługi Dcc. I natrafiłem na drobny problem - nie mogę odebrać (ani wysłać) pliku od osoby która jest za NAT (ja mam publiczne IP). Prawdopodobnie coś robię źle, oto log dcc7 z tego transferu: Nie widzę nigdzie obsługi soft_timeout. Jeśli faktycznie ta flaga jest ignorowana, zerknij na pierwszą uwagę na stronie http://toxygen.net/libgadu/docs/group__events.html. w. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Kompilacja na FreeBSD
Dnia 2008-12-28, nie o godzinie 17:37 +0100, Adam Wysocki pisze: Na FreeBSD kompilacja wykłada się z braku inkludów, patch (eliminuje także warninga w connect() i warningi implicit declaration funkcji ze string.h): Dzięki, commitnięte. w. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Niekonczacy sie watek w libgadu?
Tomek pisze: Przyszedl mi do glowy pomysl zeby napisac resolvera na qt i ustawic przy pomocy gg_session_set_custom_resolver() tylko jest jedno ale - w kadu wywolujemy gg_login() ktora przyjmuje tylko GG_RESOLVER_FORK, GG_RESOLVER_PTHREAD lub GG_RESOLVER_DEFAULT i dla kazdego innego zwroci -1. W takim razie zeby ustawic wlasnego resolvera musze ta funkcje przepisac u siebie z wywolaniem gg_session_set_custom_resolver() zamiast gg_session_set_resolver? Nie ma jakiegos 'ladniejszego' sposobu? Będzie, jak tylko dokończę funkcje gg_session_new(), gg_session_set_*() itp. Większość już mam napisaną, ale używalne to będzie dopiero po świętach. Tak poza tym, to której wersji to dotyczy? Zerknąłbym u siebie, bo może rozwiązanie okaże się proste i pisanie własnych resolverów nie będzie potrzebne. w. ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
