Widziałem, że Rafał w Kadu walczy z tym samym błędem: http://www.kadu.im/red
mine/issues/3117
Wygląda na to, że jest częściowa poprawka w libgadu 1.12.2. Nie jestem
pewien, jaki jest status tego wydania: tag w Gicie jest, ale nie widziałem
żadnego ogłoszenia, a http://libgadu.net/ oraz htt
Po pobraniu dodatkowych siedmiu DLL-ek, od których ten build libgadu
zależał (a właściwie libgnutls i sześciu jego zależności) i zmianie
nazwy z libgadu-3.dll na gadu.dll działa z Kadu bez zarzutu.
Pozdrawiam!
___
libgadu-devel mailing list
2013/6/15 Wojtek Kaniewski wojte...@toxygen.net:
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
2013/6/13 Wojtek Kaniewski wojte...@toxygen.net:
I plan to copy and paste a part of GnuTLS' configure.ac. Take a look at
https://gitorious.org/gnutls/gnutls/blobs/c59329a089a9ed108692066de95f533f482b5422/configure.ac
line 377. And if we detect GnuTLS 3.x we'll use appropriate function. Are
you
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 have performed some research and the
options seem to be to:
1) Have a build-time option to explicitly specify a CA trust
(Reposting my conversation with Wojtek to the mailing list. I have
just noticed we switched away from it).
2013/6/7 Bartosz Brachaczek b.brachac...@gmail.com:
2013/6/6 Wojtek Kaniewski wojte...@toxygen.net:
Dnia 2013-06-04, wto o godzinie 13:37 +0200, Bartosz Brachaczek pisze:
But checking
Hi,
Simply using SSL_get_verify_result() is not a solution here, as it
returns X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when connecting
to the proprietary servers on my system (I assume I am not being
attacked, you might want to confirm it yourself).
But checking which certificates are
W dniu 20 września 2012 22:01 użytkownik Jakub Zawadzki
darkjames...@darkjames.pl napisał:
Może da się to zaimplementować wykorzystując -timeout oraz -soft_timeout?
(zgaduję, nie oglądałem kodu)
Oczywiście, głupek ze mnie. Kombinowałem jak koń pod górkę, a zupełnie
zapomniałem o soft_timeout.
W dniu 20 września 2012 21:01 użytkownik Tomasz Wasilczyk
tomkiewicz.gro...@gmail.com napisał:
Natrafiłem jednak na pewien problem: nie można potwierdzać odebrania
pakietów z obrazkami od razu po ich otrzymaniu. Zrobiłem więc bufor, w
którym potwierdzam po trzy pakiety (udaję tak oryginalnego
W dniu 21 września 2012 00:38 użytkownik Tomasz Wasilczyk
tomkiewicz.gro...@gmail.com napisał:
3. Z kodu wnioskuję, że co trzeci pakiet potwierdzasz jednak od razu.
Więc widocznie potwierdzanie z opóźnieniem nie jest twardym wymogiem,
a przynajmniej nie zawsze. Brałeś pod uwagę taką możliwość,
W dniu 2 września 2012 16:28 użytkownik Tomasz Wasilczyk
tomkiewicz.gro...@gmail.com napisał:
Napisałem prototyp wspomnianego bufora [1], do odczytywania pakietów
GG11 - nazwa robocza safe const buffer. Działa to w ten sposób, że
sobie odczytujemy z takiego bufora po kolei co chcemy, a on sam
W dniu 2 września 2012 21:24 użytkownik Jakub Zawadzki
darkjames...@darkjames.pl napisał:
On Sun, Sep 02, 2012 at 04:28:04PM +0200, Tomasz Wasilczyk wrote:
Napisałem prototyp wspomnianego bufora, do odczytywania pakietów
GG11 - nazwa robocza safe const buffer. Działa to w ten sposób, że
sobie
2012/8/30 Rafał Malinowski rafal.przemyslaw.malinow...@gmail.com:
Hohohoh!
Trzymamy kciuki w Kadu za to!
Ja postaram się nie tylko trzymać kciuki, ale to jak znajdę znowu trochę czasu.
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
2012/8/27 Daniel Macks dma...@netspace.org:
Now that configure.ac puts -Wall in CFLAGS for the whole build process
conditional on GCC, that same flag should not also be hardcoded in any
specific makefiles. There are several instances of it in
test/automatic/Makefile.am and
W dniu 27 sierpnia 2012 09:17 użytkownik Marcin Owsiany
mar...@owsiany.pl napisał:
Jeśli wyślesz mi łatkę wcześniej, to mogę potestować.
Racja. Łatka jest bardzo prosta. Załączyłem ją w pliku 0005-*.patch.
Łatka 0006-*.patch może przy odrobinie szczęścia nieco rozjaśnić powód
problemów na
Dobra. Chyba poprawiłem też ten test na kFreeBSD. Załączam łatki.
0008-Zawsze-zeruj-struktur-sockaddr_in-valgrind-FreeBSD.patch
Description: Binary data
0009-Popraw-implementacj-timeoutu-w-connect.patch
Description: Binary data
___
libgadu-devel
2012/8/18 Marcin Owsiany mar...@owsiany.pl:
.. w r1314, na kfreebsd-i386 i hurd-i386, ale w różny sposób:
https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=kfreebsd-i386ver=1%3A1.12.0%7Epre%2Br1314-1stamp=1345247660
W dniu 15 sierpnia 2012 16:05 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
Dnia 2012-08-11, sob o godzinie 21:52 +0200, Libgadu commit list pisze:
Author: beevvy
Date: 2012-08-11 21:52:57 +0200 (Sat, 11 Aug 2012)
New Revision: 1307
Modified:
trunk/configure.ac
W dniu 16 czerwca 2012 22:47 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
Dnia 2012-06-16, sob o godzinie 19:22 +0100, Marcin Owsiany pisze:
Witam,
log z autobuildera:
W dniu 16 czerwca 2012 23:03 użytkownik Bartosz Brachaczek
b.brachac...@gmail.com napisał:
I akurat tak się składa, że
wczoraj napisałem poprawkę na test protocol, która powinna tutaj pomóc
-- postaram się ją jeszcze dzisiaj wrzucić.
Poprawka polegała na tym, że używane były sockety AF_UNIX
W dniu 13 czerwca 2012 23:20 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
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? :)
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
W dniu 5 marca 2012 00:02 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
Dnia 2012-03-03, sob o godzinie 18:46 +0100, Bartosz Brachaczek pisze:
Wiem, że powyższa sytuacja to głównie wina błędu w Kadu, ale _wydaje
mi się_, że w gg_handle_connecting() w libgadu powinno nastąpić
2011/12/28 Jakub Zawadzki darkjames...@darkjames.pl:
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ń ;|
Dzięki, pomogło.
A wiadomość z Spróbuj z r1240 w ogóle do mnie nie doszła.
Przeglądając archiwum listy przez
Cześć,
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
Hej,
Czy byłoby możliwe wydanie libgadu 1.11.1? Powód mojego pytania jest
taki, że w libgadu 1.11.0 nie działają połączenia szyfrowane z użyciem
GnuTLS, a w obecnej gałęzi 1.11 jak najbardziej działają (działają
również połączenia z użyciem OpenSSL, tak samo jak w 1.11.0). Zbliża
się nowe wydanie
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
W dniu 29 października 2011 18:53 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
Dnia 2011-10-29, sob o godzinie 02:35 +0200, Bartosz Brachaczek pisze:
W załączonych łatkach moim zdaniem są błędy off-by-one, podobnie
zresztą jak jest w aktualnym kodzie libgadu. Przypadek res == size
W dniu 28 października 2011 06:59 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
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
To ja może podsumuję tutaj znane mi problemy pod MSVC i Win32 ogólnie:
- Na Win32 obecnie nie można polegać na errno, bo funkcje Windows
Sockets go nie ustawiają. Mam na to prawie gotową łatę w duchu
sugestii Wojtka z tego wątku.
- Na Win32 gniazda trzeba zamykać za pomocą closesocket(), ale
: Bartosz Brachaczek b.brachac...@gmail.com
Date: Sat, 29 Oct 2011 01:40:33 +0200
Subject: [PATCH] Popraw gg_vsaprintf() dla nie-C99
---
src/common.c | 58 --
1 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/src/common.c b/src
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
W dniu 23 października 2011 23:25 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
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
W dniu 15 września 2011 01:18 użytkownik Bartosz Brachaczek
b.brachac...@gmail.com napisał:
W dniu 3 września 2010 22:54 użytkownik Jakub Zawadzki
darkja...@darkjames.ath.cx napisał:
Witam,
Nieoficjalnym standardem[1] szyfrowania wiadomości w gg jest wykorzystanie
kluczy RSA w kodowaniu
W dniu 21 października 2011 01:31 użytkownik Tomasz Wasilczyk
tomkiewicz.gro...@gmail.com napisał:
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
W dniu 18 października 2011 16:41 użytkownik Tomasz Wasilczyk
tomkiewicz.gro...@gmail.com napisał:
Nie rozumiem tylko, w jaki sposób bez niektórych z tych zmian wychodzą
np. nowe wersje Kadu pod Windows.
Kadu pod Windows ma własnego forka libgadu[1]. Z tego co wiem, część
kodu dla Windows
W dniu 19 października 2011 00:53 użytkownik Tomasz Wasilczyk
tomkiewicz.gro...@gmail.com napisał:
W dniu 18 października 2011 23:37 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
Dnia 2011-10-13, czw o godzinie 03:22 +0200, Tomasz Wasilczyk pisze:
Pytanie pierwsze: czy libgadu nie
W dniu 11 października 2011 20:46 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
- zastanawiam się, po co kopiować zmienną ap do aq (zresztą jak nie ma
dostępnych funkcji do kopiowania, nasza funkcja tego po prostu nie
robi); Poza tym wywołanie vsnprintf na końcu w wersji patcha C
W dniu 6 września 2011 03:15 użytkownik Bartosz Brachaczek
b.brachac...@gmail.com napisał:
Cześć,
Myślę, że przyszedł czas, aby libgadu mogło umożliwiać wysyłanie
wiadomości poprzez podanie bezpośrednio treści. Dzięki temu klienty
będą mogły całkiem zapomnieć o starych atrybutach formatowania
Witam,
Ostatnio zauważyłem, że na moim systemie test connect w losowym
momencie dostaje SIGABRT z glibc. Problem udało mi się powtórzyć na
kilku systemach (nie na wszystkich). Co ciekawe, pod valgrindem nie
mogłem powtórzyć tego problemu. Za to na wszystkich systemach, jakie
sprawdzałem,
W dniu 3 września 2010 22:54 użytkownik Jakub Zawadzki
darkja...@darkjames.ath.cx napisał:
Witam,
Nieoficjalnym standardem[1] szyfrowania wiadomości w gg jest wykorzystanie
kluczy RSA w kodowaniu WINDOWS-1250.
W ekg2 jak implementowaliśmy obsługę UTF-8 w gg, niechcący zmieniliśmy
również
Cześć,
Myślę, że przyszedł czas, aby libgadu mogło umożliwiać wysyłanie
wiadomości poprzez podanie bezpośrednio treści. Dzięki temu klienty
będą mogły całkiem zapomnieć o starych atrybutach formatowania, a
także obsługiwać bardziej szczegółowe formatowanie, jeśli taka będzie
wola ich developerów.
Co prawda nie mam żadnego doświadczenia z architekturami big endian
i nie testowałem na takiej maszynie, ale ta poprawka wydaje mi się
w porządku. W każdym razie wydaje się nie psuć niczego na little endian.
Nie użyłem funkcji gg_fix16(), aby plik message.c pozostał niezależny
od zewnętrznego
---
src/libgadu.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/libgadu.c b/src/libgadu.c
index fe69daa..aec389c 100644
--- a/src/libgadu.c
+++ b/src/libgadu.c
@@ -1475,7 +1475,7 @@ int gg_send_message_confer_richtext(struct
gg_session *sess, int msgclass,
---
src/handlers.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index bc442e8..0377937 100644
--- a/src/handlers.c
+++ b/src/handlers.c
@@ -790,7 +790,6 @@ static int gg_session_handle_recv_msg(struct gg_session
*sess, uint32_t
---
src/handlers.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index 0377937..9100e1b 100644
--- a/src/handlers.c
+++ b/src/handlers.c
@@ -834,8 +834,10 @@ static int gg_session_handle_recv_msg(struct
Ostatni z dodanych testów pokazuje dlaczego ta zmiana była konieczna.
Krótko mówiąc, oryginalny klient wcale nie gwarantuje, że prześle
atrybuty formatowania posortowane niemalejąco według pozycji w tekście,
jak do tej pory zakładaliśmy.
---
src/message.c | 79
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 11 ++-
test/automatic/message2.c |4 ++--
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/message.h b/include/message.h
index 824f1a8..9d02baf 100644
---
src/message.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/message.c b/src/message.c
index 125cc72..7fc2145 100644
--- a/src/message.c
+++ b/src/message.c
@@ -393,7 +393,7 @@ size_t gg_message_text_to_html(char *dst, const char *src,
gg_encoding_t
W razie potrzeby konwertujemy przychodzącą wiadomość w czystym tekście
do HTML-a.
---
src/handlers.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index 9100e1b..764c5a0 100644
--- a/src/handlers.c
+++
---
src/message.c | 14 ++
test/automatic/message2.c | 99 +
2 files changed, 78 insertions(+), 35 deletions(-)
diff --git a/src/message.c b/src/message.c
index 0cb8ef1..2048934 100644
--- a/src/message.c
+++ b/src/message.c
@@
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 25 -
test/automatic/message2.c |4 ++--
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/include/message.h b/include/message.h
index
---
include/message.h |2 +-
src/handlers.c|4 +-
src/message.c | 237 +
test/automatic/message2.c |4 +-
4 files changed, 222 insertions(+), 25 deletions(-)
diff --git a/include/message.h
Dzięki tej zmianie formatowanie w odebranych wiadomościach m.in. od
Infobota jest poprawne.
---
src/handlers.c| 15 ---
test/automatic/script/20-messages.scr | 30 --
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git
---
test/automatic/message2.c | 129 ++--
1 files changed, 111 insertions(+), 18 deletions(-)
diff --git a/test/automatic/message2.c b/test/automatic/message2.c
index e01f5fd..8add069 100644
--- a/test/automatic/message2.c
+++ b/test/automatic/message2.c
Przesyłam serię ponownie. Jedyna zmiana to wycofanie z serii poprzedniego
patcha 08, bo okazał się zupełnie niepotrzeby, oraz dostosowanie dalszych
łatek, aby się poprawnie nakładały.
Pozdrawiam
Bartosz Brachaczek (13):
Usunięcie niepotrzebnej zmiennej
Bardziej zwracamy uwagę na
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 11 ++-
test/automatic/message2.c |4 ++--
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/message.h b/include/message.h
index 824f1a8..9d02baf 100644
W razie potrzeby konwertujemy przychodzącą wiadomość w czystym tekście
do HTML-a.
---
src/handlers.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/handlers.c b/src/handlers.c
index 9100e1b..764c5a0 100644
--- a/src/handlers.c
+++
---
src/encoding.c |5 +
src/message.c | 18 +-
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/src/encoding.c b/src/encoding.c
index ef2ff5c..41822df 100644
--- a/src/encoding.c
+++ b/src/encoding.c
@@ -136,11 +136,8 @@ static char
Ostatni z dodanych testów pokazuje dlaczego ta zmiana była konieczna.
Krótko mówiąc, oryginalny klient wcale nie gwarantuje, że prześle
atrybuty formatowania posortowane niemalejąco według pozycji w tekście,
jak do tej pory zakładaliśmy.
---
src/message.c | 79
---
src/message.c | 27 ---
test/automatic/message2.c | 14 +++---
test/automatic/script/20-messages.scr |2 +-
3 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/src/message.c b/src/message.c
index
---
src/message.c | 14 ++
test/automatic/message2.c | 99 +
2 files changed, 78 insertions(+), 35 deletions(-)
diff --git a/src/message.c b/src/message.c
index 7fc2145..7c35cb1 100644
--- a/src/message.c
+++ b/src/message.c
@@
---
include/message.h |2 +-
src/handlers.c|4 +-
src/message.c | 237 +
test/automatic/message2.c |4 +-
4 files changed, 222 insertions(+), 25 deletions(-)
diff --git a/include/message.h
---
include/message.h |2 +-
src/libgadu.c |4 ++--
src/message.c | 25 -
test/automatic/message2.c |4 ++--
4 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/include/message.h b/include/message.h
index
Dzięki tej zmianie formatowanie w odebranych wiadomościach m.in. od
Infobota jest poprawne.
---
src/handlers.c| 15 ---
test/automatic/script/20-messages.scr | 30 --
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git
Cześć,
Zaktualizowałem swoje libgadu do najnowszej wersji z gałęzi trunk (tj.
r1146) i mam problemy ze zrywaniem połączenia z serwerem chwilę po
jego uzyskaniu. Odrobina testów wykazała, że problemy zaczęły się wraz
z wersją r1142. Załączam dwa przykładowe logi z zerwanych sesji. Przed
każdym
Witam,
Funkcja gg_session_handle_recv_msg_80() zakłada, że zawsze dostanie
wiadomość w czystym tekście, natomiast wiadomość w formacie HTML jest
opcjonalna. Jednak, jak widzę, w przypadku dostania wiadomości w
formacie HTML wiadomość w czystym tekście jest całkowicie ignorowana i
do pola message
Witam,
W Kadu stwierdziliśmy, że miło by było pozbyć się kodu
odpowiedzialnego za formatowanie wiadomości GG za pomocą atrybutów i
pracować wyłącznie na HTML-u. Stąd propozycja kilku zmian w libgadu.
Jestem gotów je zaimplementować, chciałbym tylko się dogadać, jak to
ma być zrobione i w czy w
W dniu 5 maja 2011 15:11 użytkownik Krzysztof Klinikowski
kkszy...@gmail.com napisał:
I jakiś mały update samej dokumentacji protokołu związany z tymi pakietami?
Mały update dokumentacji protokołu był od początku częścią tej serii
łatek i, jak widzę, również został dzisiaj wrzucony. :)
Sprawdzanie zlib w configure.ac wymaga poprawki. Sam nie mam pojęcia o
autotools i zrobiłem to tylko tak, żeby na moim systemie libgadu w ogóle
chciało się linkować.
Zmiany względem v1:
- Kilka deklaracji przesuniętych z libgadu.h do internal.h i protocol.h.
---
configure.ac |4 ++
Zmiany względem v1:
- Przesunięcie jednej deklaracji z libgadu.h do internal.h.
- Usunięcie zapomnianego gg_debug_session z funkcji
gg_session_handle_userlist_100_reply.
---
include/internal.h |1 +
include/libgadu.h.in | 33 +++
include/protocol.h | 10 ++
W dniu 23 kwietnia 2011 16:53 użytkownik Wojtek Kaniewski
wojte...@toxygen.net napisał:
Świetnie! Jedna uwaga -- wszystko, co dotyczy protokołu, powinno trafić
do protocol.h, a funkcje wewnętrzne biblioteki do internal.h. Nie chcemy
zaśmiecać API/ABI rzeczami, które użytkowników nie dotyczą.
---
docs/protocol.html | 110 +---
1 files changed, 79 insertions(+), 31 deletions(-)
diff --git a/docs/protocol.html b/docs/protocol.html
index dc9982b..1141ffa 100644
--- a/docs/protocol.html
+++ b/docs/protocol.html
@@ -1496,10 +1496,13 @@
---
include/libgadu.h.in |4 ++--
include/protocol.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/libgadu.h.in b/include/libgadu.h.in
index 142e1ea..fb1d5ef 100644
--- a/include/libgadu.h.in
+++ b/include/libgadu.h.in
@@ -696,7 +696,7 @@ enum gg_event_t
Sprawdzanie zlib w configure.ac wymaga poprawki przez kogoś zaznajomionego z
autotools. Sam nie mam pojęcia o autotools i zrobiłem to tylko tak, żeby na
moim systemie libgadu w ogóle chciało się linkować ;).
---
configure.ac |4 ++
include/libgadu.h.in | 53
---
docs/importexport.dox | 31 ---
1 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/docs/importexport.dox b/docs/importexport.dox
index 0554f41..31e7c67 100644
--- a/docs/importexport.dox
+++ b/docs/importexport.dox
@@ -7,27 +7,36 @@
Serwer
W dniu 6 marca 2011 22:57 użytkownik Bartosz Brachaczek
b.brachac...@gmail.com napisał:
Witam,
Po aktualizacji libgadu do wersji 1.10.0 zauważyłem problemy z
wysyłaniem obrazków. Używam Kadu w wersji z git master (z resolverem
pthreads z libgadu). Problemy objawiają się tym, że zazwyczaj przy
dla paczkujących. Co za
nieprofesjonalizm!
Pozdrawiam,
Bartosz Brachaczek
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
/000623.html
Pozdrawiam,
Bartosz Brachaczek
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
79 matches
Mail list logo
