Re: [libgadu-devel] libgadu 1.12.2

[Marcin Owsiany]

Cześć,

Zastanawiam się, czy powinienem wepchnąć tą poprawkę połączeń TLS do
przygotowywanego właśnie wydania Debiana. Obecnie jest tam wersja 1.12.1,
która wydaje się używać "/appsvc/appmsg_ver8.asp" i w ekg
(1:1.9~pre+r2855-2) z ustawieniami domyślnymi nie łączy się po TLS (a po
ustawieniu "set server tls" w ogóle wykłada się na resolverze, tak jakby
dokumentacja nie mówiła prawdy).

Czy dobrze wnioskuję, że w takim przypadku połączenia po TLS w ogóle nie
działały?


W dniu 1 lutego 2017 18:21 użytkownik Tomasz Wasilczyk  napisał:

> Dobry wieczór,
>
> po dwóch latach zbierania poprawek, wydano libgadu 1.12.2. Wydanie to
> skupia się na poprawie stabilności i jakości kodu. Poprawką najbardziej
> widoczną przez użytkowników są naprawione połączenia TLS, po niedawnej
> zmianie konfiguracji po stronie operatora Gadu-Gadu.
>
> Lista zmian:
> * Poprawka nadpisania pamięci przy aktualizacji listy uczestników czatu.
> * Poprawiona obsługa błędów GnuTLS.
> * Zaktualizowany adres połączenia TLS.
> * Poprawka błędu rozłączania w przypadku dołączenia do pokoju z ustawionym
> tytułem.
> * Użycie bezpiecznych funkcji losowania.
> * Poprawka błędu zawieszania się przy wysyłaniu plików pod Windows.
> * Poprawki zachowania w przypadku braku pamięci systemowej.
> * Poprawki rozwiązywania nazw pod systemem Windows.
> * Biblioteka protobuf-c zaktualizowana do wersji 1.2.1.
> * Usprawniony proces budowania dla systemu Windows.
> * Poprawione testy.
>
> Szczegóły pod adresem http://libgadu.net/releases/1.12.2.html
>
> Pozdrawiam,
> Tomek
>
> ___
> libgadu-devel mailing list
> libgadu-devel@lists.ziew.org
> http://lists.ziew.org/mailman/listinfo/libgadu-devel
>
>
___
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?

[Marcin Owsiany]

W dniu 10 czerwca 2014 20:52 użytkownik Tomasz Wasilczyk 
twasilc...@pidgin.im napisał:

 Może podsumujmy problemy, które wstrzymały wydanie tydzień temu.

 - segfault w teście resolvera: poprawka w 3b2b6c05 (zgadza się?)
 - użycie 127.0.0.2 pod kfreebsd: poprawka w fc002e53
 - błąd kompilacji hash.c: poprawka w a644c3ee

 Czy coś pominąłem?


GG_DEFAULT_CLIENT_VERSION

Ale to zdaje się też jest poprawione?

Wygląda na to, że libgadu jest (znowu) gotowe na wydanie.


Będzie oficjalne rc4?

Marcin
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Fwd: Bug#750843: test/automatic/connect fails on kfreebsd-* bind: Cannot assign requested address

[Marcin Owsiany]

FYI

-- Forwarded message --
From: Andreas Metzler ametz...@bebt.de
Date: 2014-06-08 11:30 GMT+02:00
Subject: Bug#750843: test/automatic/connect fails on kfreebsd-* bind:
Cannot assign requested address
To: 750...@bugs.debian.org


On 2014-06-07 Marcin Owsiany mar...@owsiany.pl wrote:
 Thanks for filing the bug.

 2014-06-07 15:24 GMT+02:00 Andreas Metzler ametz...@bebt.de:

 libgadu FTBFS on kfreebsd-*, test/automatic/connect fails with bind:
 Cannot assign requested address.

 FTR, I've seen this a while ago, and asked on debian-bsd for advice
 regardng binding to 127.0.0.2, but there was no response.
 https://lists.debian.org/debian-bsd/2014/05/msg00047.html

Hello,

google suggests that 127.0.0.2 not being automatically mapped to
127.0.0.1 is normal and to be expected on freebsd:
http://serverfault.com/questions/293874/why-cant-i-ping-an-address-on-the-loopback-device-under-freebsd
https://groups.google.com/forum/#!topic/lucky.freebsd.stable/sZROnG-RZDY


-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Every program in development at MIT expands until it can read mail.
-- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Using 127.0.0.2 on kfreebsd

[Marcin Owsiany]

Hello,

libgadu has a test suite which recently started trying to bind to 127.0.0.2:

#define HOST_LOCAL 127.0.0.2
[...]
memset(sin, 0, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = inet_addr(HOST_LOCAL);

if (bind(server_fds[i], (struct sockaddr*) sin, sizeof(sin)) ==
-1) {
perror(bind);
failure();
}

The reason they are not using 127.0.0.1 is that when running on windows
that address is used for something to workaround win32 limitations (don't
know details).

This succeeds on all Debian architectures except kfreebsd-* where it fails
with:
bind: Cannot assign requested address

I didn't do any detailed investigation nor do I know anything about
freebsd-specific network tools, but doesn't RFC3330 mandate that all of
127.0.0.0/8 should be on loopback?

There are a few options:

1) put some ifdefs into the test to treat kfreebsd (or windows) specially
2) somehow make sure that binding to that address works on the buildds.

What do you think?

Marcin
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] libgadu 1.12.0-rc3

[Marcin Owsiany]

W dniu 7 maja 2014 22:14 użytkownik Wojtek Kaniewski
wojte...@toxygen.netnapisał:

 Dobry wieczór,

 Nowa wersja rc3 względem rc2 zawiera wiele, naprawdę wiele drobnych
 poprawek, które ciężko nawet wymienić. Najważniejsza jest taka, że Tomek
 Wasilczyk poprawił kolejny błąd bezpieczeństwa przy alokacji pamięci
 liczonej na podstawie odpowiedzi serwera. Pamięć nie jest nadpisywana
 bezpośrednio tym, co wyśle serwer, więc wykonanie kodu może nie być
 trywialne, ale nie jestem w stanie powiedzieć że niemożliwe.


Rozumiem że ten błąd jest tylko w 1.12.0-rcx?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Every program in development at MIT expands until it can read mail.
-- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] libgadu 1.12.0-rc3

[Marcin Owsiany]

Z innej beczki: martwi mnie nieco ta zmiana:

 /* GG_DEPRECATED */
-#define GG_DEFAULT_CLIENT_VERSION 10.1.0.11070
+#define GG_DEFAULT_CLIENT_VERSION NULL

Jeśli jakiś program tego używał, to ta zmiana zdaje się gwarantuje
segfault. IMHO to trochę duże ryzyko a mały zysk...
Można by to zrevertować przed releasem?

Marcin
___
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

[Marcin Owsiany]

W dniu 27 kwietnia 2014 16:30 użytkownik Wojtek Kaniewski 
wojte...@toxygen.net napisał:

 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ć.


Wydaje mi się, że w świetle
https://lists.debian.org/debian-devel-announce/2014/04/msg00012.html można
się nie przejmować. Możliwe że to była wina sprzętu.

Marcin
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Segfault w testach na architekturze sparc

[Marcin Owsiany]

FYI, przy testach wersji 1.12.0-rc2
../../test-driver: line 107: 12981 Segmentation fault  $@  $log_file 21
FAIL: connect

https://buildd.debian.org/fetch.cgi?pkg=libgaduarch=sparcver=1%3A1.12.0%7Erc2-2stamp=1398191913file=log

Postaram się dostać jakiś zrzut stosu.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Tue, Apr 22, 2014 at 09:09:19PM +0200, Marcin Owsiany wrote:
 FYI, przy testach wersji 1.12.0-rc2
 ../../test-driver: line 107: 12981 Segmentation fault  $@  $log_file 
 21
 FAIL: connect
 
 https://buildd.debian.org/fetch.cgi?pkg=libgaduarch=sparcver=1%3A1.12.0%7Erc2-2stamp=1398191913file=log
 
 Postaram się dostać jakiś zrzut stosu.

Na razie mam tyle:

433/648: sync,  80 open,8074 open,443 open,resolver closed, server 
yes, proxy no,  ssl yes
*** Error in `./connect': double free or corruption (!prev): 0x001e9fa0 ***
Bus error

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Tue, Apr 22, 2014 at 09:45:52PM +0200, Marcin Owsiany wrote:
 On Tue, Apr 22, 2014 at 09:09:19PM +0200, Marcin Owsiany wrote:
  FYI, przy testach wersji 1.12.0-rc2
  ../../test-driver: line 107: 12981 Segmentation fault  $@  $log_file 
  21
  FAIL: connect
  
  https://buildd.debian.org/fetch.cgi?pkg=libgaduarch=sparcver=1%3A1.12.0%7Erc2-2stamp=1398191913file=log
  
  Postaram się dostać jakiś zrzut stosu.
 
 Na razie mam tyle:
 
 433/648: sync,  80 open,8074 open,443 open,resolver closed, 
 server yes, proxy no,  ssl yes
 *** Error in `./connect': double free or corruption (!prev): 0x001e9fa0 ***
 Bus error

Kolejny pad:

406/648: sync,  80 open,8074 open,443 open,resolver open, server 
yes, proxy no,  ssl yes
*** Error in `./connect': free(): invalid pointer: 0x001ebb10 ***
*** Error in `./connect': free(): invalid pointer: 0x001eb828 ***
*** Error in `./connect': free(): invalid pointer: 0x001eb990 ***
Segmentation fault (core dumped)

Niestety na stosie jest kaszanka:

Program terminated with signal 11, Segmentation fault.
#0  0xf7d25d5c in ?? () from /lib/sparc-linux-gnu/libc.so.6
(gdb) bt full
#0  0xf7d25d5c in ?? () from /lib/sparc-linux-gnu/libc.so.6
No symbol table info available.
#1  0xf7d25894 in ?? () from /lib/sparc-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 


-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Tue, Apr 22, 2014 at 09:47:38PM +0200, Marcin Owsiany wrote:
 On Tue, Apr 22, 2014 at 09:45:52PM +0200, Marcin Owsiany wrote:
  On Tue, Apr 22, 2014 at 09:09:19PM +0200, Marcin Owsiany wrote:
   FYI, przy testach wersji 1.12.0-rc2
   ../../test-driver: line 107: 12981 Segmentation fault  $@  
   $log_file 21
   FAIL: connect
   
   https://buildd.debian.org/fetch.cgi?pkg=libgaduarch=sparcver=1%3A1.12.0%7Erc2-2stamp=1398191913file=log
   
   Postaram się dostać jakiś zrzut stosu.
  
  Na razie mam tyle:
  
  433/648: sync,  80 open,8074 open,443 open,resolver closed, 
  server yes, proxy no,  ssl yes
  *** Error in `./connect': double free or corruption (!prev): 0x001e9fa0 ***
  Bus error
 
 Kolejny pad:
 
 406/648: sync,  80 open,8074 open,443 open,resolver open, server 
 yes, proxy no,  ssl yes
 *** Error in `./connect': free(): invalid pointer: 0x001ebb10 ***
 *** Error in `./connect': free(): invalid pointer: 0x001eb828 ***
 *** Error in `./connect': free(): invalid pointer: 0x001eb990 ***
 Segmentation fault (core dumped)
 
 Niestety na stosie jest kaszanka:
 
 Program terminated with signal 11, Segmentation fault.
 #0  0xf7d25d5c in ?? () from /lib/sparc-linux-gnu/libc.so.6
 (gdb) bt full
 #0  0xf7d25d5c in ?? () from /lib/sparc-linux-gnu/libc.so.6
 No symbol table info available.
 #1  0xf7d25894 in ?? () from /lib/sparc-linux-gnu/libc.so.6
 No symbol table info available.
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
 (gdb) 

Przy pomocy heap checkera udało mi się wykryć problem nieco wcześniej:

325/648: async, 80 open,8074 open,443 open,resolver open,server 
no,  proxy no,  ssl yes
Aborted (core dumped)
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from 
/home/porridge/libgadu-1.12.0~rc2/test/automatic/connect...done.
[New LWP 24828]
[New LWP 23894]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/sparc-linux-gnu/libthread_db.so.1.
Core was generated by `./connect'.
Program terminated with signal 6, Aborted.
#0  0xf7ca36ac in __GI_raise (sig=0) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0  0xf7ca36ac in __GI_raise (sig=0) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
__o0 = 0
__o1 = 24828
__o2 = 6
err = 211
resultvar = optimized out
pd = 0xf7acfb70
pid = 0
selftid = 24828
#1  0xf7dee008 in ?? () from /lib/sparc-linux-gnu/libc.so.6
No symbol table info available.
#2  0xf7dee008 in ?? () from /lib/sparc-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

albo:

325/648: async, 80 open,8074 open,443 open,resolver open,server 
no,  proxy no,  ssl yes
Segmentation fault (core dumped)
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from 
/home/porridge/libgadu-1.12.0~rc2/test/automatic/connect...done.
[New LWP 25167]
[New LWP 25171]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/sparc-linux-gnu/libthread_db.so.1.
Core was generated by `./connect'.
Program terminated with signal 11, Segmentation fault.
#0  mem2chunk_check (mem=0x9b0f1c8, magic_p=0x0) at hooks.c:161
161 hooks.c: No such file or directory.
(gdb) bt full
#0  mem2chunk_check (mem=0x9b0f1c8, magic_p=0x0) at hooks.c:161
p = optimized out
sz = optimized out
c = optimized out
magic = optimized out
#1  0xf7dc6008 in ?? () from /lib/sparc-linux-gnu/libc.so.6
No symbol table info available.
#2  0xf7dc6008 in ?? () from /lib/sparc-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

Niestety na sparca nie ma valgrinda.  :-/
-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail

Re: [libgadu-devel] Segfault w testach na architekturze sparc

[Marcin Owsiany]

Nieco inaczej, ale chyba w tym samym miejscu:

[New Thread 0xf7307b70 (LWP 30772)]
325/648: sync,  80 open,8074 open,443 open,resolver open,server 
no,  proxy no,  ssl yes
[Thread 0xf7307b70 (LWP 30772) exited]
325/648: async, 80 open,8074 open,443 open,resolver open,server 
no,  proxy no,  ssl yes
[New Thread 0xf7307b70 (LWP 30773)]
[Thread 0xf7307b70 (LWP 30773) exited]
[New Thread 0xf7307b70 (LWP 30774)]
[Thread 0xf7307b70 (LWP 30774) exited]

Program received signal SIGBUS, Bus error.
0xf7c48f5c in asn1_delete_structure2 () from 
/usr/lib/sparc-linux-gnu/libtasn1.so.6
(gdb) bt full
#0  0xf7c48f5c in asn1_delete_structure2 () from 
/usr/lib/sparc-linux-gnu/libtasn1.so.6
No symbol table info available.
#1  0xf7f0cc14 in gnutls_x509_crt_deinit (cert=0x694d8) at x509.c:136
No locals.
#2  0xf7f170a0 in gnutls_x509_trust_list_deinit (list=0x3f140, all=1) at 
verify-high.c:124
i = optimized out
j = optimized out
#3  0xf7eb7f60 in gnutls_certificate_free_credentials (sc=0x3f8d0) at 
gnutls_cert.c:193
No locals.
#4  0xf7f9b230 in gg_free_session (sess=0x3f030) at libgadu.c:1211
tmp = 0x38310
dcc = optimized out
chat = optimized out
#5  0x0001355c in client_func (test=0x264d8 test.8694) at connect.c:463
ge = 0x1
rd = {__fds_bits = {131072, 0 repeats 31 times}}
wr = {__fds_bits = {0 repeats 32 times}}
res = optimized out
max_fd = optimized out
gs = 0x3f030
glp = {uin = 1, password = 0x13e50 dupa.8, async = 1, status = 0, 
status_descr = 0x0, server_addr = 0, server_port = 0, client_addr = 0, 
client_port = 0, protocol_version = 0, client_version = 0x0, has_audio = 0, 
last_sysmsg = 0, external_addr = 0, external_port = 0, tls = 1, image_size = 0, 
era_omnix = 0, hash_type = 0, encoding = GG_ENCODING_CP1250, 
  resolver = GG_RESOLVER_PTHREAD, protocol_features = 0, status_flags = 
0, struct_size = 0, compatibility = GG_COMPAT_LEGACY, connect_host = 0x0, 
socket_manager_type = GG_SOCKET_MANAGER_TYPE_INTERNAL, socket_manager = 
{cb_data = 0x0, connect_cb = 0x0, close_cb = 0x0, read_cb = 0x0, write_cb = 
0x0, reserved1 = 0x0, reserved2 = 0x0, reserved3 = 0x0, reserved4 = 0x0}, 
  host_white_list = 0x0}
tmp = -116 '\214'
#6  0x000118a0 in main (argc=optimized out, argv=optimized out) at 
connect.c:1067
result = optimized out
j = optimized out
expect = 1
i = 324
test_from = optimized out
test_to = 648
exit_code = 0
server_thread = optimized out
one = 1
(gdb) 


-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

I jeszcze raz tak jak za pierwszym razem ale z symbolami z gnutls:


[New Thread 0xf7307b70 (LWP 32164)]
325/648: sync,  80 open,8074 open,443 open,resolver open,server 
no,  proxy no,  ssl yes
[Thread 0xf7307b70 (LWP 32164) exited]
325/648: async, 80 open,8074 open,443 open,resolver open,server 
no,  proxy no,  ssl yes
[New Thread 0xf7307b70 (LWP 32165)]
[Thread 0xf7307b70 (LWP 32165) exited]
[New Thread 0xf7307b70 (LWP 32166)]
[Thread 0xf7307b70 (LWP 32166) exited]
*** Error in `/home/porridge/libgadu-1.12.0~rc2/test/automatic/./connect': 
free(): invalid pointer: 0x00072668 ***

Program received signal SIGABRT, Aborted.
0xf7cdb6ac in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0  0xf7cdb6ac in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
__o0 = 0
__o1 = 30801
__o2 = 6
err = 211
resultvar = optimized out
pd = 0xf7b1f5c0
pid = 0
selftid = 30801
#1  0xf7cdf4d4 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0, 1701934437, 1852007680, 1952776241, 1060241408, 1, 3, 0, 
0, 0, 2182540689, 0, 2, 0, 0, 5, 0, 8, 1872227351, 3072785625, 3109907645, 
3074703569, 10, 3565868, 32, 0, 3565808, 3565816, 4294955192, 4159305420, 
1969384037, 1668567157}}, sa_flags = 1651272035, sa_restorer = 0x4b657949}
sigs = {__val = {32, 0 repeats 31 times}}
#2  0xf7d1d1f4 in __libc_message (do_abort=2, fmt=optimized out) at 
../sysdeps/posix/libc_fatal.c:175
ap = 0xd250
fd = 19
on_2 = optimized out
list = optimized out
nlist = optimized out
cp = optimized out
written = optimized out
#3  0xf7d290ac in malloc_printerr (action=3, str=0xf7e02b48 free(): invalid 
pointer, ptr=0x72668) at malloc.c:4927
buf = 00072668
cp = optimized out
#4  0xf7d2d3cc in __GI___libc_free (mem=0x72668) at malloc.c:2882
ar_ptr = optimized out
p = optimized out
hook = optimized out
#5  0xf7f0cc44 in gnutls_x509_crt_deinit (cert=0x72668) at x509.c:139
No locals.
#6  0xf7f170a0 in gnutls_x509_trust_list_deinit (list=0x3ce88, all=1) at 
verify-high.c:124
i = optimized out
j = optimized out
#7  0xf7eb7f60 in gnutls_certificate_free_credentials (sc=0x3f8d0) at 
gnutls_cert.c:193
No locals.
#8  0xf7f9b230 in gg_free_session (sess=0x3f030) at libgadu.c:1211
tmp = 0x38310
dcc = optimized out
chat = optimized out
#9  0x0001355c in client_func (test=0x264d8 test.8694) at connect.c:463
ge = 0x1
rd = {__fds_bits = {131072, 0 repeats 31 times}}
wr = {__fds_bits = {0 repeats 32 times}}
res = optimized out
max_fd = optimized out
gs = 0x3f030
glp = {uin = 1, password = 0x13e50 dupa.8, async = 1, status = 0, 
status_descr = 0x0, server_addr = 0, server_port = 0, client_addr = 0, 
client_port = 0, protocol_version = 0, client_version = 0x0, has_audio = 0, 
last_sysmsg = 0, external_addr = 0, external_port = 0, tls = 1, image_size = 0, 
era_omnix = 0, hash_type = 0, encoding = GG_ENCODING_CP1250, 
  resolver = GG_RESOLVER_PTHREAD, protocol_features = 0, status_flags = 
0, struct_size = 0, compatibility = GG_COMPAT_LEGACY, connect_host = 0x0, 
socket_manager_type = GG_SOCKET_MANAGER_TYPE_INTERNAL, socket_manager = 
{cb_data = 0x0, connect_cb = 0x0, close_cb = 0x0, read_cb = 0x0, write_cb = 
0x0, reserved1 = 0x0, reserved2 = 0x0, reserved3 = 0x0, reserved4 = 0x0}, 
  host_white_list = 0x0}
tmp = -116 '\214'
#10 0x000118a0 in main (argc=optimized out, argv=optimized out) at 
connect.c:1067
result = optimized out
j = optimized out
expect = 1
i = 324
test_from = optimized out
test_to = 648
exit_code = 0
server_thread = optimized out
one = 1
(gdb) 

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

W dniu 4 lutego 2014 21:36 użytkownik Jakub Zawadzki 
darkjames...@darkjames.pl napisał:

 On Tue, Feb 04, 2014 at 08:54:10PM +0100, Tomasz Wasilczyk wrote:
  Od siebie dodam jeszcze, że wersja rc2 ma przydatną zmianę w API: dodany
  symbol gg_is_gpl_compliant, który jest obecny wtedy i tylko wtedy, gdy
  biblioteka jest zgodna z GPL (tzn. nie jest skompilowana z openssl).
 
  Pidgin się tym przejmował już wcześniej - teraz i inne projekty GPL
  (Kadu?) mogą zapewnić GPL-spójność jednolinijkowym checkiem w configure.

 Przyznam się, że ja nigdy tego nie rozumiałem, ale czy samo sprawdzenie
 w configure jest wystarczające?

 W sensie, czy ktoś jak skompiluje program z GPLowym libgadu, potem
 zrekompiluje libgadu z openssl, to myślę, że taki komplet nie jest
 zgodny z GPL?


Wydaje mi się że linker dynamiczny nie pozwoli uruchomić tego drugiego
libgadu z programem, bo będzie brakowało wspomnianego symbolu.

Marcin
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] libgadu 1.11.3

[Marcin Owsiany]

W dniu 31 stycznia 2014 23:03 użytkownik Wojtek Kaniewski 
wojte...@toxygen.net napisał:

 Dnia 2014-01-31, pią o godzinie 22:08 +0100, Marcin Owsiany pisze:
  Przy przygotowaniu aktualizacji pakietu security team Debiana zapytał
  o:
 
  What about CVE-2013-4488?  Is there a fix for this one available now?
 
  Czy jest poprawka tego w ogólności a dla 1.11 w szczególności?

 W ogólności jest poprawione w 1.12.0-rc1. Jak już pisałem wcześniej, nie
 uważam tego za poważny problem, co najwyżej braki w dokumentacji, więc
 nie mam za bardzo motywacji, żeby portować zmianę do 1.11. Ludzie z
 security teamu Debiana będą bardzo nalegać?


Chyba nie, nikt wcześniej mnie o to nie pytał, pewnie zagadali przy okazji.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Every program in development at MIT expands until it can read mail.
-- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Protokół GG11 i nowe pakiety

[Marcin Owsiany]

On Fri, Feb 15, 2013 at 09:11:20PM +0100, Wojtek Kaniewski wrote:
 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.

http://packages.debian.org/sid/protobuf-c-compiler ?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Protokół GG11 i nowe pakiety

[Marcin Owsiany]

On Sat, Feb 16, 2013 at 03:08:51PM +0100, Tomasz Wasilczyk wrote:
 Przyjrzałem się temu, pogooglowałem i okazuje się, że chyba wystarczy
 dodać samo protobuf-c.c do i nawet się będzie kompilowało na
 windowsie. Licencja to BSD-new, czyli (z tego, co wiem) zgodna z
 GPL/LGPL.
 
 Zaleta: będziemy bazować na czystych deklaracjach .proto.
 Wada: projekt ostatnio ruszany w grudniu 2011.
 
 To będzie chyba najlepsze rozwiązanie - ten projekt generuje ładny kod
 i obsługuje całkiem sporą część standardu.

Jeśli można to prosiłbym aby ten plik był używany tylko jeśli w systemie
nie ma obecnej zainstalowanej właściwej biblioteki (i najlepiej jeśli
dałoby się wymusić na etapie konfiguracji, żeby nie był używany).

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Kolejne zawodzące testy

[Marcin Owsiany]

On Mon, Aug 27, 2012 at 09:24:23PM +0200, Bartosz Brachaczek wrote:
 Dobra. Chyba poprawiłem też ten test na kFreeBSD. Załączam łatki.

r1323 się buduje na wszystkich architekturach. Pozostaje trzymać kciuki
że tak zostanie, a nie że tylko miałem szczęście :-)

Dzięki!

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Implementacja protokołu GG11 w libgadu

[Marcin Owsiany]

On Mon, Sep 03, 2012 at 02:21:37AM +0200, Jakub Zawadzki wrote:
 Twoje rozwiązanie ma też lepszą kontrolę typów, w moim pomylisz się w
 literce i pozamiatane.

Wyjąłeś mi to z ust :)
-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Kolejne zawodzące testy

[Marcin Owsiany]

On Mon, Aug 27, 2012 at 12:33:07AM +0200, Bartosz Brachaczek wrote:
 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
 
  https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=hurd-i386ver=1%3A1.12.0%7Epre%2Br1314-1stamp=1345256162
 
 Mam poprawkę na problem z Test error (ten z Hurda). Brakowało
 continue po złapaniu EINTR w select(). Natomiast nie wiem jeszcze, co
 powoduje problem na kFreeBSD. Być może też gdzieś jest EINTR, a my
 tego nie obsługujemy. Wygląda na to, że na Linuksie nigdy nie
 dostajemy EINTR, jeśli nie mamy własnej obsługi sygnałów, ale gdzie
 indziej może się to zdarzyć (dziwne...).
 
 Wrzucę poprawki do repozytorium, jak tylko będzie to możliwe. Bo
 chwilowo serwer ma problemy, już napisałem Wojtkowi.

Jeśli wyślesz mi łatkę wcześniej, to mogę potestować.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Kolejne zawodzące testy

[Marcin Owsiany]

.. 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

https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=hurd-i386ver=1%3A1.12.0%7Epre%2Br1314-1stamp=1345256162

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Mon, Jul 09, 2012 at 10:45:39PM +0100, Marcin Owsiany wrote:
 On Wed, Jun 27, 2012 at 01:16:33PM +0100, Marcin Owsiany wrote:
  On Wed, Jun 27, 2012 at 07:22:58AM +0100, Marcin Owsiany wrote:
   On Tue, Jun 26, 2012 at 11:28:46PM +0200, Wojtek Kaniewski wrote:
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.
   
   Wysypało się już przy pierwszej próbie. I to inaczej niż ostatnio:
   
   https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=kfreebsd-amd64ver=1%3A1.12.0~pre%2Br1302-1stamp=1340758217file=log
  
  FYI, odpaliłem na tej architekturze każdy test 10 razy, i jedyne które
  zawiodły choć raz to następujące:
  
7 *.**..
   88 **
   89 .**...
   90 *..**.
  115 *.*..*
  116 ..*.**.*..
  117 *...**
  142 *..*.*...*
  144 .*...*
  
  . = OK
  * = FAIL
  
  Mam teraz shella na którym mogę trochę poeksperymentować, więc jeśli
  masz jakieś pomysły to daj znać.
 
 Ping?

Ping ping?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Wed, Jun 27, 2012 at 01:16:33PM +0100, Marcin Owsiany wrote:
 On Wed, Jun 27, 2012 at 07:22:58AM +0100, Marcin Owsiany wrote:
  On Tue, Jun 26, 2012 at 11:28:46PM +0200, Wojtek Kaniewski wrote:
   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.
  
  Wysypało się już przy pierwszej próbie. I to inaczej niż ostatnio:
  
  https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=kfreebsd-amd64ver=1%3A1.12.0~pre%2Br1302-1stamp=1340758217file=log
 
 FYI, odpaliłem na tej architekturze każdy test 10 razy, i jedyne które
 zawiodły choć raz to następujące:
 
   7 *.**..
  88 **
  89 .**...
  90 *..**.
 115 *.*..*
 116 ..*.**.*..
 117 *...**
 142 *..*.*...*
 144 .*...*
 
 . = OK
 * = FAIL
 
 Mam teraz shella na którym mogę trochę poeksperymentować, więc jeśli
 masz jakieś pomysły to daj znać.

Ping?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Tue, Jun 26, 2012 at 11:28:46PM +0200, Wojtek Kaniewski wrote:
 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.

Wysypało się już przy pierwszej próbie. I to inaczej niż ostatnio:

https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=kfreebsd-amd64ver=1%3A1.12.0~pre%2Br1302-1stamp=1340758217file=log

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Wed, Jun 27, 2012 at 07:22:58AM +0100, Marcin Owsiany wrote:
 On Tue, Jun 26, 2012 at 11:28:46PM +0200, Wojtek Kaniewski wrote:
  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.
 
 Wysypało się już przy pierwszej próbie. I to inaczej niż ostatnio:
 
 https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=kfreebsd-amd64ver=1%3A1.12.0~pre%2Br1302-1stamp=1340758217file=log

FYI, odpaliłem na tej architekturze każdy test 10 razy, i jedyne które
zawiodły choć raz to następujące:

  7 *.**..
 88 **
 89 .**...
 90 *..**.
115 *.*..*
116 ..*.**.*..
117 *...**
142 *..*.*...*
144 .*...*

. = OK
* = FAIL

Mam teraz shella na którym mogę trochę poeksperymentować, więc jeśli
masz jakieś pomysły to daj znać.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Tue, Jun 26, 2012 at 11:28:46PM +0200, Wojtek Kaniewski wrote:
 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.

Spróbuję.

 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ć?

Tak, pakiet źródłowy libgadu w squeeze (1:1.9.0-2) nie wymaga gnutls.
Zależnośc wprowadziłem dopiero w 1:1.10.0+r1057-1

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Sun, Jun 24, 2012 at 10:27:01PM +0200, Wojtek Kaniewski wrote:
 Dnia 2012-06-23, sob o godzinie 17:50 +0100, Marcin Owsiany pisze:
  On Sat, Jun 23, 2012 at 05:29:07PM +0100, Marcin Owsiany wrote:
   On Sat, Jun 23, 2012 at 11:49:41AM +0200, Wojtek Kaniewski wrote:
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?
   
   Odpaliłem to na maszynie hurdowej, i wygląda na to że testy idą szybko,
   ale w pewnym momencie jeden z nich (losowy, bo na dwa opalenia zawiesiły 
   się
   dwa różne) się zawiesza.
  
  O, na r1300 poszło (10 prób na 10).
 
 A u mnie pod QEMU wywala się 10 prób na 10. I jak widzę hurdowego
 backtrace'a, zaczynam zastanawiać się, czy nie jestem już za stary, żeby
 próbować to zrozumieć ;) Pośledzę, ale nie wiem czy uda mi się cokolwiek
 z tego wywnioskować w skończonym czasie.

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

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Fri, Jun 22, 2012 at 10:26:20PM +0100, Marcin Owsiany wrote:
 On Fri, Jun 22, 2012 at 07:43:01PM +0200, Wojtek Kaniewski wrote:
  Dnia 2012-06-22, pią o godzinie 09:19 +0100, Marcin Owsiany pisze:
   ping?
  
  Trochę to trwało, ale udało mi się tak przerobić testy, żeby timeout też
  był symulowany, zamiast naprawdę pozwolić bibliotece czekać. Dzięki temu
  test puszczany na normalnej maszynie będzie trwał kilka(naście) sekund,
  nie minut, a na wolnych maszynach (lub pod Valgrindem) będzie leciał
  swoim tempem i nic mu nie będzie przeszkadzać. Dzięki za motywację :)
 
 Rewelacja! Zapaczkowałem, zobaczymy czy pomoże.

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.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Sat, Jun 23, 2012 at 11:49:41AM +0200, Wojtek Kaniewski wrote:
 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?

http://people.debian.org/~sthibault/hurd-i386/README

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Sat, Jun 23, 2012 at 11:49:41AM +0200, Wojtek Kaniewski wrote:
 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?

Odpaliłem to na maszynie hurdowej, i wygląda na to że testy idą szybko,
ale w pewnym momencie jeden z nich (losowy, bo na dwa opalenia zawiesiły się
dwa różne) się zawiesza. Oto stosy z zawieszonego testu 648/648. Mam nadzieję
że pomogą:

(gdb) thread apply all bt full

Thread 3 (Thread 3623.3):
#0  0x011fd7cc in mach_msg_trap () at 
/build/buildd-eglibc_2.13-33+b1-hurd-i386-_ygsAA/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
No locals.
#1  0x011fdfc9 in __mach_msg (msg=0x19fed38, option=258, send_size=0, 
rcv_size=40, rcv_name=1555, timeout=1000, notify=0) at msg.c:110
ret = optimized out
#2  0x01204d39 in _hurd_select (nfds=12, pollfds=0x0, readfds=0x19fee5c, 
writefds=0x19fee7c, exceptfds=0x0, timeout=0x19fedfc, sigmask=0x0) at 
hurdselect.c:340
msg = {head = {msgh_bits = 0, msgh_size = 20385780, msgh_remote_port = 
20407300, msgh_local_port = 155656, msgh_seqno = 27258376, msgh_id = 19958121}, 
error = {head = {
  msgh_bits = 0, msgh_size = 20385780, msgh_remote_port = 20407300, 
msgh_local_port = 155656, msgh_seqno = 27258376, msgh_id = 19958121}, err_type 
= {type = {
msgt_name = 1, msgt_size = 0, msgt_number = 0, msgt_inline = 0, 
msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, word = 1}, err = 0}, 
success = {
head = {msgh_bits = 0, msgh_size = 20385780, msgh_remote_port = 
20407300, msgh_local_port = 155656, msgh_seqno = 27258376, msgh_id = 19958121}, 
err_type = {type = {
msgt_name = 1, msgt_size = 0, msgt_number = 0, msgt_inline = 0, 
msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, word = 1}, err = 0, 
result_type = {
  type = {msgt_name = 0, msgt_size = 0, msgt_number = 0, 
msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, word 
= 0}, result = 27258356}}
options = optimized out
msgerr = optimized out
i = 352
portset = 1555
got = 0
rfds = {fds_bits = {3840, 0, 0, 0, 0, 0, 0, 0}}
wfds = {fds_bits = {0, 0, 0, 0, 0, 0, 0, 0}}
xfds = {fds_bits = {0, 0, 0, 0, 0, 0, 0, 0}}
firstfd = 8
lastfd = 11
to = optimized out
oset = 1554
__PRETTY_FUNCTION__ = _hurd_select
#3  0x012f3f41 in __select (nfds=12, readfds=0x19fee5c, writefds=0x19fee7c, 
exceptfds=0x0, timeout=0x19feeb0) at ../sysdeps/mach/hurd/select.c:47
ts = {tv_sec = 1, tv_nsec = 0}
to = 0x160
#4  0x0804ad82 in server (arg=0x15ffaf0) at connect.c:602
tv = {tv_sec = 1, tv_usec = 0}
rd = {__fds_bits = {3840, 0, 0, 0, 0, 0, 0, 0}}
wr = {__fds_bits = {0, 0, 0, 0, 0, 0, 0, 0}}
max = 11
res = optimized out
port_pipe = optimized out
sfds = {8, 9, 10, 11, 12}
cfd = -1
ctype = CLIENT_PROXY
i = optimized out
buf = CONNECT 127.0.0.1:443 HTTP/1.0\r\n\r\n, '\000' repeats 4061 
times
len = 0
welcome_packet = \001\000\000\000\004\000\000\000\001\002\003\004
login_ok_packet = \003\000\000\000\000\000\000
hub_reply = HTTP/1.0 200 OK\r\n\r\n0 0 127.0.0.1:8074 127.0.0.1\r\n
hub_ssl_reply = HTTP/1.0 200 OK\r\n\r\n0 0 127.0.0.1:443 127.0.0.1\r\n
proxy_reply = HTTP/1.0 200 OK\r\n\r\n
proxy_error = HTTP/1.0 404 Not Found\r\n\r\n404 Not Found\r\n
session = 0x0
#5  0x011d7c80 in entry_point (start_routine=0x804a8c0 server, arg=0x15ffaf0) 
at ./pthread/pt-create.c:50
No locals.
#6  0x in ?? ()
No symbol table info available.

Thread 2 (Thread 3623.2):
#0  0x011fd7cc in mach_msg_trap () at 
/build/buildd-eglibc_2.13-33+b1-hurd-i386-_ygsAA/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
No locals.
#1  0x011fdfc9 in __mach_msg (msg=0x17fdf30, option=3, send_size=32, 
rcv_size=4096, rcv_name=237, timeout=0, notify=0) at msg.c:110
ret = optimized out
#2  0x011fe6f9 in __mach_msg_server_timeout (demux=0x120ef00 msgport_server, 
max_size=4096, rcv_name=237, option=0, timeout=0) at msgserver.c:151
request = 0x17fef40
reply = 0x17fdf30
mr = optimized out
__PRETTY_FUNCTION__ = __mach_msg_server_timeout
#3  0x011fe7cb in __mach_msg_server (demux=0x120ef00 msgport_server, 
max_size=4096, rcv_name=237) at msgserver.c:196
No locals.
#4  0x0120eecf in _hurd_msgport_receive () at msgportdemux.c:68
No locals.
#5  0x011d7c80 in entry_point (start_routine=0x120ee60 _hurd_msgport_receive, 
arg=0x0) at ./pthread/pt

Re: [libgadu-devel] Testy zawodzą na GNU/kFreeBSD

[Marcin Owsiany]

On Sat, Jun 23, 2012 at 05:29:07PM +0100, Marcin Owsiany wrote:
 On Sat, Jun 23, 2012 at 11:49:41AM +0200, Wojtek Kaniewski wrote:
  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?
 
 Odpaliłem to na maszynie hurdowej, i wygląda na to że testy idą szybko,
 ale w pewnym momencie jeden z nich (losowy, bo na dwa opalenia zawiesiły się
 dwa różne) się zawiesza.

O, na r1300 poszło (10 prób na 10).

Wywaliło się za to nieco dalej przy linkowaniu:

libtool: link: gcc -Wall -DHAVE_OPENSSL -DGG_IGNORE_DEPRECATED -Wl,-z -Wl,relro 
-o search search-search.o search-base64.o search-hmac.o search-http.o 
search-oauth.o search-oauth_parameter.o search-sha1.o search-urlencode.o 
search-xml.o -pthread  /usr/lib/i386-gnu/libcurl-gnutls.so 
/usr/lib/i386-gnu/libexpat.so -lssl -L/usr/lib/i386-gnu -lgnutls -lz 
-L/lib/i386-gnu -lgcrypt -pthread -Wl,-rpath -Wl,/usr/lib/i386-gnu -Wl,-rpath 
-Wl,/usr/lib/i386-gnu
/usr/bin/ld.bfd.real: search-base64.o: undefined reference to symbol 
'BIO_ctrl@@OPENSSL_1.0.0'
/usr/bin/ld.bfd.real: note: 'BIO_ctrl@@OPENSSL_1.0.0' is defined in DSO 
/usr/lib/i386-gnu/libcrypto.so.1.0.0 so try adding it to the linker command line
/usr/lib/i386-gnu/libcrypto.so.1.0.0: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

Dodanie -lcrypto do search_LDFLAGS pomaga.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Tue, Jun 19, 2012 at 08:53:32AM +0100, Marcin Owsiany wrote:
 On Mon, Jun 18, 2012 at 11:08:38PM +0200, Wojtek Kaniewski wrote:
  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.
 
 W tzw międzyczasie wyleciał test na armelu:
 https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=armelver=1%3A1.12.0~pre%2Br1295-1stamp=1340090070file=log
 
 Z tego wynika, że ta zmiana będzie potrzebna też na architekturach
 linuksowych, a one już na pewno losowego napisu w LD_PRELOAD nie
 przełkną.  Nie widzę problemu żeby testy po prostu odpalać pod
 valgrindem, co powinno mieć ten sam efekt uboczny w LD_PRELOAD a może
 przy okazji złapie jaki wyciek.
 
 Tylko powiedz mi jak to zrobić?

ping?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Fri, Jun 22, 2012 at 07:43:01PM +0200, Wojtek Kaniewski wrote:
 Dnia 2012-06-22, pią o godzinie 09:19 +0100, Marcin Owsiany pisze:
  ping?
 
 Trochę to trwało, ale udało mi się tak przerobić testy, żeby timeout też
 był symulowany, zamiast naprawdę pozwolić bibliotece czekać. Dzięki temu
 test puszczany na normalnej maszynie będzie trwał kilka(naście) sekund,
 nie minut, a na wolnych maszynach (lub pod Valgrindem) będzie leciał
 swoim tempem i nic mu nie będzie przeszkadzać. Dzięki za motywację :)

Rewelacja! Zapaczkowałem, zobaczymy czy pomoże.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Mon, Jun 18, 2012 at 11:08:38PM +0200, Wojtek Kaniewski wrote:
 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.

W tzw międzyczasie wyleciał test na armelu:
https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=armelver=1%3A1.12.0~pre%2Br1295-1stamp=1340090070file=log

Z tego wynika, że ta zmiana będzie potrzebna też na architekturach
linuksowych, a one już na pewno losowego napisu w LD_PRELOAD nie
przełkną.  Nie widzę problemu żeby testy po prostu odpalać pod
valgrindem, co powinno mieć ten sam efekt uboczny w LD_PRELOAD a może
przy okazji złapie jaki wyciek.

Tylko powiedz mi jak to zrobić?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Sat, Jun 16, 2012 at 11:24:56PM +0200, Wojtek Kaniewski wrote:
 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.

Zrobiłem upload 1289 i nadal czekam na wynik z kfreebsd, ale jak na
razie nie przeszły na hurd-i386:

https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=hurd-i386ver=1%3A1.12.0~pre%2Br1289-1stamp=1340005322

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Mon, Jun 18, 2012 at 09:39:17PM +0200, Wojtek Kaniewski wrote:
 Dnia 2012-06-18, pon o godzinie 19:01 +0100, Marcin Owsiany pisze:
  On Mon, Jun 18, 2012 at 07:55:28PM +0200, Wojtek Kaniewski wrote:
   Dnia 2012-06-18, pon o godzinie 10:35 +0100, Marcin Owsiany pisze:
Zrobiłem upload 1289 i nadal czekam na wynik z kfreebsd, ale jak na
razie nie przeszły na hurd-i386:

https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=hurd-i386ver=1%3A1.12.0~pre%2Br1289-1stamp=1340005322
   
   Nie przeszły, a przechodziły wcześniej, czy pierwszy raz były puszczane?
  
  Pierwszy raz.
 
 Możliwe, że maszyna testowa jest mocno obciążona?

Możliwe, no i nie wiem jak teraz, ale kiedyś hurd miał opinię dość
wolnego.

 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.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Sat, Jun 16, 2012 at 11:24:56PM +0200, Wojtek Kaniewski wrote:
 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.

Dzięki, sprawdzę (nawiasem ten log to był trunk). Spróbuję też zobaczyć
czy da się jakoś usdostępniać report.html na przyszłość.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Ostrzeżenia

[Marcin Owsiany]

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?


automake-1.11: compiling `httphash.c' with per-target flags requires 
`AM_PROG_CC_C_O' in `configure.ac'
examples/Makefile.am:1:   while processing program `httphash'

test/automatic/Makefile.am:5: `CFLAGS' is a user variable, you should not 
override it;
test/automatic/Makefile.am:5: use `AM_CFLAGS' instead.
test/manual/Makefile.am:4: `CFLAGS' is a user variable, you should not override 
it;
test/manual/Makefile.am:4: use `AM_CFLAGS' instead.

make[5]: Entering directory 
`/tmp/buildd/libgadu-1.12.0~pre+r1289/test/automatic'
convert.c:124:6: warning: no previous prototype for 'test_utf8_to_cp1250' 
[-Wmissing-prototypes]
convert.c: In function 'test_utf8_to_cp1250':
convert.c:131:3: warning: format '%d' expects argument of type 'int', but 
argument 6 has type 'ssize_t' [-Wformat]
convert.c:131:3: warning: format '%d' expects argument of type 'int', but 
argument 7 has type 'ssize_t' [-Wformat]
convert.c: At top level:
convert.c:138:6: warning: no previous prototype for 'test_cp1250_to_utf8' 
[-Wmissing-prototypes]
convert.c: In function 'test_cp1250_to_utf8':
convert.c:145:3: warning: format '%d' expects argument of type 'int', but 
argument 6 has type 'ssize_t' [-Wformat]
convert.c:145:3: warning: format '%d' expects argument of type 'int', but 
argument 7 has type 'ssize_t' [-Wformat]

message2.c: In function 'test_text_to_html':
message2.c:225:8: warning: unused variable 'tmp' [-Wunused-variable]

resolver.c:78:5: warning: no previous prototype for 'test' 
[-Wmissing-prototypes]
resolver.c:155:5: warning: no previous prototype for 'test_set_get' 
[-Wmissing-prototypes]

packet.c: In function 'send':
packet.c:224:3: warning: format '%d' expects argument of type 'int', but 
argument 3 has type 'size_t' [-Wformat]
packet.c:224:3: warning: format '%d' expects argument of type 'int', but 
argument 4 has type 'size_t' [-Wformat]
packet.c:237:2: warning: format '%d' expects argument of type 'int', but 
argument 4 has type 'size_t' [-Wformat]
packet.c:237:2: warning: format '%d' expects argument of type 'int', but 
argument 6 has type 'ssize_t' [-Wformat]

connect.c: In function 'server_ssl_init':
connect.c:444:37: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
connect.c: In function 'server':
connect.c:466:18: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
connect.c: In function 'main':
connect.c:828:35: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Use of uninitialized value $1 in uc at script/compile line 85, FILE line 5.
Use of uninitialized value $1 in uc at script/compile line 85, FILE line 18.
Use of uninitialized value $1 in uc at script/compile line 85, FILE line 31.
Use of uninitialized value $1 in uc at script/compile line 85, FILE line 43.
Use of uninitialized value $1 in uc at script/compile line 85, FILE line 55.
Use of uninitialized value $1 in uc at script/compile line 85, FILE line 67.

doxygen
warning: Tag `HTML_ALIGN_MEMBERS' at line 91 of file Doxyfile has become 
obsolete.
To avoid this warning please remove this line from your configuration file or 
upgrade it using doxygen -u


-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Testy zawodzą na GNU/kFreeBSD

[Marcin Owsiany]

Witam,

log z autobuildera:
https://buildd.debian.org/status/fetch.php?pkg=libgaduarch=kfreebsd-amd64ver=1%3A1.12.0~pre%2Br1278-1stamp=1339864900file=log

Jakieś pomysły?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Thu, Dec 15, 2011 at 02:17:28AM +0100, Rafał Malinowski wrote:
 Witam.
 
 Nie udało mi się skompilować libgadu z gnutls na Opensuse Factory
 dopóki nie wprowadziłem małej zmiany w Makefile.am w src:
 
 libgadu_la_LDFLAGS = -lgcrypt -version-number 3:13 -export-symbols
 $(srcdir)/libgadu.sym @MINGW_LDFLAGS@
 
 Wymusiłem linkowanie z libgcrypt, która zawiera symbole:
 gcry_md_open
 gcry_md_write
 gcry_md_read
 gcry_md_close
 
 Nie wiem, jak to naprawić we właściwy sposób, więc przekazuje
 informacje ludziom obeznanym z autohell :)

Ustawieniem odpowiednich flag powinien zająć się fragment po
AC_ARG_WITH(gnutls, w configure.ac.
Polega on na tym co zwraca pkg-config --libs gnutls

Co ta komenda wypisuje w Twoim systemie? Którą wersję gnutls masz?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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

[Marcin Owsiany]

On Sat, Oct 29, 2011 at 07:26:59PM +0200, Wojtek Kaniewski wrote:
 Dnia 2011-10-29, sob o godzinie 03:11 +0200, Bartosz Brachaczek pisze:
  - 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!).

Wygląda mi na to, że ta nazwa nigdzie nie jest używana, ani w
bibliotece, ani w żadnym kliencie (przynajmniej wg.
google.com./codesearch). W takim razie nie stanowi części ABI, więc nie
popsuje istniejących binarek. Jeśli zaś (mało prawdopodobne) okaże się,
że jakiś program jednak tego wymaga do kompilacji, to sobie dorzucę do
debianowego patcha. Wydaje mi się, że można usunąć, jeśli moje domysły
są poprawne.

pozdrawiam,
-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Neverending test...

[Marcin Owsiany]

On Wed, Jun 15, 2011 at 11:28:45PM +0200, Wojtek Kaniewski wrote:
 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.

Ręcznie nie mogę tego crasha powtórzyć, z valgrindem czy bez.
Modyfikacja builda żeby ten test odpalał przez valgrinda też nie pomaga.
A zwykły build wykopuje się w ~50% przypadków.
Valgrind pokazuje jedynie parę ostrzeżeń - patrz załącznik.

  2) jak zrobić żeby zrzut stosu dostawał się do logu?
 
 To już kwestia glibc, nie wiem.

Dokumentacja jak zwykle jest niepełna, ale zerknięcie w źródła eglibc wyjawia:

  /* Open a descriptor for /dev/tty unless the user explicitly
 requests errors on standard error.  */   
  const char *on_2 = __secure_getenv (LIBC_FATAL_STDERR_);  

Ustawię sobie to w makefile'u.

  3) jak zrobić żeby przy podobnych błędach build nie zwisał w nieskończoność?
 
 Zobacz, czy łata w załączniku pomoże.

Ta z SIGABRT która weszła, powinna.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
==3358== Memcheck, a memory error detector
==3358== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3358== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for 
copyright info
==3358== Command: ./.libs/connect
==3358== 
==3358== Thread 2:
==3358== Use of uninitialised value of size 8
==3358==at 0x576DE4B: _itoa_word (_itoa.c:195)
==3358==by 0x576F138: vfprintf (vfprintf.c:1613)
==3358==by 0x5795681: vsnprintf (vsnprintf.c:120)
==3358==by 0x40192C: debug_handler (connect.c:60)
==3358==by 0x4E38982: gg_debug (debug.c:127)
==3358==by 0x4E453C9: gg_resolver_run (resolver.c:274)
==3358==by 0x4E4548C: gg_resolver_pthread_thread (resolver.c:480)
==3358==by 0x55129C9: start_thread (pthread_create.c:300)
==3358==by 0x6B516FF: ???
==3358== 
==3358== Conditional jump or move depends on uninitialised value(s)
==3358==at 0x576DE55: _itoa_word (_itoa.c:195)
==3358==by 0x576F138: vfprintf (vfprintf.c:1613)
==3358==by 0x5795681: vsnprintf (vsnprintf.c:120)
==3358==by 0x40192C: debug_handler (connect.c:60)
==3358==by 0x4E38982: gg_debug (debug.c:127)
==3358==by 0x4E453C9: gg_resolver_run (resolver.c:274)
==3358==by 0x4E4548C: gg_resolver_pthread_thread (resolver.c:480)
==3358==by 0x55129C9: start_thread (pthread_create.c:300)
==3358==by 0x6B516FF: ???
==3358== 
==3358== Conditional jump or move depends on uninitialised value(s)
==3358==at 0x5770FB1: vfprintf (vfprintf.c:1613)
==3358==by 0x5795681: vsnprintf (vsnprintf.c:120)
==3358==by 0x40192C: debug_handler (connect.c:60)
==3358==by 0x4E38982: gg_debug (debug.c:127)
==3358==by 0x4E453C9: gg_resolver_run (resolver.c:274)
==3358==by 0x4E4548C: gg_resolver_pthread_thread (resolver.c:480)
==3358==by 0x55129C9: start_thread (pthread_create.c:300)
==3358==by 0x6B516FF: ???
==3358== 
==3358== Conditional jump or move depends on uninitialised value(s)
==3358==at 0x576F226: vfprintf (vfprintf.c:1613)
==3358==by 0x5795681: vsnprintf (vsnprintf.c:120)
==3358==by 0x40192C: debug_handler (connect.c:60)
==3358==by 0x4E38982: gg_debug (debug.c:127)
==3358==by 0x4E453C9: gg_resolver_run (resolver.c:274)
==3358==by 0x4E4548C: gg_resolver_pthread_thread (resolver.c:480)
==3358==by 0x55129C9: start_thread (pthread_create.c:300)
==3358==by 0x6B516FF: ???
==3358== 
==3358== Syscall param write(count) contains uninitialised byte(s)
==3358==at 0x551A8DD: ??? (syscall-template.S:82)
==3358== 
==3358== Conditional jump or move depends on uninitialised value(s)
==3358==at 0x4E45490: gg_resolver_pthread_thread (resolver.c:480)
==3358== 
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Brakujący symbol w 1.10.0

[Marcin Owsiany]

On Thu, Feb 24, 2011 at 11:00:59PM +0100, Jakub Zawadzki wrote:
 On Thu, Feb 24, 2011 at 09:35:52PM +, Marcin Owsiany wrote:
  Wygląda na to, że gdzieś pomiędzy wersją 1.8.0+r592 (czyli zdaje się
  prawie 1.9) a 1.10.0 
 
 A dokładniej zniknął w r985
 
  zniknął symbol gg_debug_common@Base. Wygląda na to, że według narzędzi dpkg 
  powoduje to złamanie ABI.
 
 IMHO nie ma czym się przejmować, gg_debug_common() nigdy nie było w
 pliku nagłowkowym.

Z drugiej strony nagłówki to API, a symbole to ABI. Zmiany w API to
problem dla programisty korzystającego z biblioteki. Złamanie ABI to
problem dla użytkownika programu, którego autor myślał że był cwany bo
użył ukrytej funkcji.

Czy jest jakiś powód żeby tego nie poprawić?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] Brakujący symbol w 1.10.0

[Marcin Owsiany]

On Fri, Feb 25, 2011 at 05:36:34PM +0100, Tomek wrote:
 Pytanie czy ktokolwiek byl cwany i uzyl tej funkcji.

Uważam, że właśnie dlatego, że trudno to sprawdzić, powinniśmy zachwać
ABI.

 Zreszta problem
 jest po stronie tego kto uzywa nieudokumentowanych/niewystawionych w
 API funkcji.

*Wina* jest po stronie tej osoby. *Problem* będzie po stronie niczego
nie spodziewającego się użytkownika, gdy zaktualizuje sobie bibliotekę.

pozdrawiam,
-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Brakujący symbol w 1.10.0

[Marcin Owsiany]

Witam,

Wygląda na to, że gdzieś pomiędzy wersją 1.8.0+r592 (czyli zdaje się
prawie 1.9) a 1.10.0 zniknął symbol gg_debug_common@Base. Wygląda na
to, że według narzędzi dpkg powoduje to złamanie ABI.

Postaram się zbadać o co dokładnie chodzi i jak to poprawić, ale może
ktoś ma już jakiś pomysł?

pozdrawiam,
-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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]

On Tue, Oct 20, 2009 at 12:08:50AM +0200, Wojtek Kaniewski wrote:
 Marcin Owsiany pisze:
  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 ;)

Ślicznie!
Widzę też że szykuje się rc2? :)

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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]

On Mon, Oct 19, 2009 at 10:00:54PM +0200, Wojtek Kaniewski wrote:
 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ć?

Elegancko, ale bije po oczach ta kombinacja no-op + touch html-stamp
:)

Może zamiast ustawiać DOXYGEN na : zrobić żeby make nie wchodził w
ogóle do podkatalogu docs? Czy ten html-stamp jest do czegoś potrzebny w
innym miejscu?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] [kzu...@netglob.com.pl: [OT] GG.]

[Marcin Owsiany]

hoho, kto by przypuszczał? :-)

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
---BeginMessage---

Witam.
Podaje najswiezsza ciekawosteke od Thecamels. Oto ona.

*

Temat: Nowym sercem sieci Gadu-Gadu jest Linux
Nadawca: thecamels.org n...@thecamels.org
Data: Tue, 6 Oct 2009 07:33:43 +0200
Adresat: kzu...@netglob.com.pl

W dniu 30 września Spółka GG Network poinformowała o zmianach w
architekturze sprzętowej sieci GG. Architektura oparta o Windows Server
System została zastąpiona przez Linuksa. Scentralizowana i przestarzała
architektura została wyparta przez rozproszone systemy kontrolowane przez
Linuksa. Nowy serwer ruszył w dniu 26 września i zastąpił działający stary
serwer, który pracował od samego początku istnienia Gadu-Gadu, czyli od
2000 roku.

Ciąg dalszy na:
http://thecamels.org/2009/10/05/nowym-sercem-sieci-gadu-gadu-jest-linux/#more-8390



Och nareszcie. :)

--
Konczac Pozdrawiam. Krzysztof.

Registered Linux User: 253243
Powered by Aurox 11.0, Ubuntu Studio 8.04 i Fedora 9.0
Krzysztof Zubik. | kzu...@netglob.com.pl| kzu...@wp.pl
http://www.kzubik.cba.pl
GaduGadu. 1208376 | Jabber. kzu...@jabber.wp.pl | Skype. kzubik


--
To UNSUBSCRIBE, email to debian-user-polish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

---End Message---
___
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]

On Sat, Oct 03, 2009 at 02:37:21PM +0200, Jakub Zawadzki wrote:
 On Thu, Oct 01, 2009 at 12:33:27PM +0100, Marcin Owsiany wrote:
  Reszta zależy od tego jak definiujesz jakikolwiek. 
 
 Chodziło mi o to czy Debian prowadzi bazę symboli używane przez programy
 w paczkach.

Nie.

 I czy dałoby się wyszukać czy np. takie gg_gethostbyname dostarczane
 przez libgadu jest używane przez jakiś program, który ma paczkę w
 Debianie.

W informatyce wszystko się da :-)
Ale trzeba by przemielić wszystkie pakiety, a conajmniej te które
wymagają libgadu3.

 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)

Tak to się chyba nazywa, ale prawdę mówiąc nie wiem do czego to służy.
Ale słyszałem że to nic łatwego.

pozdrawiam,
-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Ostrzeżenia przy budowaniu

[Marcin Owsiany]

Zauważyłem następujące ostrzeżenia. Może ktoś będzie miał ochotę poprawić zanim
ja się zbiorę żeby to zrobić:

remind.c:35: warning: implicit declaration of function 'atoi'
token.c:87: warning: implicit declaration of function 'mkstemp'

Warning: Tag `DETAILS_AT_TOP' at line 44 of file Doxyfile has become obsolete.
To avoid this warning please update your configuration file using doxygen -u
Warning: The selected output language polish has not been updated
since release 1.6.0.  As a result some sentences may appear in English.

/build/buildd/libgadu-1.9.0~rc1+r837/docs/events.dox:849: Warning: expected 
whitespace after c command
/build/buildd/libgadu-1.9.0~rc1+r837/docs/events.dox:849: Warning: expected 
whitespace after c command
/build/buildd/libgadu-1.9.0~rc1+r837/docs/events.dox:775: Warning: expected 
whitespace after c command
/build/buildd/libgadu-1.9.0~rc1+r837/docs/events.dox:775: Warning: expected 
whitespace after c command

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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]

On Thu, Oct 01, 2009 at 12:57:32PM +0200, Jakub Zawadzki wrote:
 On Thu, Oct 01, 2009 at 09:05:13AM +0100, Marcin Owsiany wrote:
  
  Jestem w trakcie przygotowywania aktualizacji Debianowej paczki, i jak
  na razie znalazłem jeszcze jeden potencjalny problem:
 
 Btw. Czy Debian ma jakieś narzędzie do sprawdzenia czy funkcja xyz
 bibloteki foo jest używana w jakimkolwiek programie?

Do sprawdzenia czy jest używana w _danym_ programie wystarczy chyba
objdump -R binarka | grep funkcja

Reszta zależy od tego jak definiujesz jakikolwiek. Nie jestem pewien
czy łamanie ABI jest dozwolone nawet jeśli nie popsuje żadnego programu
zapaczkowanego przez Debiana, który deklaruje zależność od libgadu.
Userzy mogą mieć swoje własne prywatnie zbudowane programy, i zakładają
że się nie popsują przy aktualizacji libgadu...

  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)
  
  gg_gethostbyname przemianować na gg_gethostbyname_cośtam, a zostawić stuba 
  ze starą
  nazwą?
 
 Mógłbyś sprawdzić czy ta łatka Ci odpowiada?

Na oko wygląda OK, sprawdzę jeszcze dokładniej.

 W łatce zmieniłem nazwę gg_gethostbyname na gg_gethostbyname_real.
 Dorobiłem działające stare gg_gethostbyname.

Wow! :-)

 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ę?

 commitnąć?

+1
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.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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]

On Fri, Sep 18, 2009 at 12:33:35AM +0200, Dominik 'Rathann' Mierzejewski wrote:
 On Tuesday, 15 September 2009 at 13:06, Marcin Owsiany wrote:
  [ wysłane ponownie, jakieś problemy z DNS były? ]
  
  On Fri, Sep 04, 2009 at 12:51:13AM +0200, Wojtek Kaniewski wrote:
   * 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.
  
  Czy powyższe nie powinno spowodować podbicia numeru API?
 
 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_.

Natomiast _dodanie_ nowych funkcji do API powinno spowodować podbicie
numeru API (i spowodowało :).


-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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]

On Thu, Sep 17, 2009 at 01:03:34AM +0200, Kosma Moczek wrote:
 2009/9/17 Wojtek Kaniewski wojte...@toxygen.net:
  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?
 
 Wydaje mi się (proszę poprawić, jeśli się mylę), że problem leży w
 złym zlinkowaniu. Ekg jest linkowane przez -lgadu, co łatwo sprawdzić:
 
 $ readelf -d /opt/ekg-svn/bin/ekg | grep gadu
  0x0001 (NEEDED) Shared library: [libgadu.so.3]
 
 Gdyby było linkowane do nazwy zawierającej wersję (libgadu.so.3.10.0),
 nie byłoby możliwości niedopasowania wersji headerów (klienta) i
 biblioteki.

Tak jak jest teraz jest dobrze. 3 to wersja ABI, która przy takiej
zmianie nie powinna ulec modyfikacji.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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?

[Marcin Owsiany]

[-wojtekka, czyta libgadu-devel]

On Sat, Dec 20, 2008 at 03:18:42PM +0100, Tomek wrote:
 Marcin Owsiany pisze:
 On Fri, Dec 19, 2008 at 06:37:38PM +0100, Tomek wrote:
 Marcin Owsiany pisze:
 On Thu, Dec 18, 2008 at 09:29:46PM +0100, Tomek wrote:
 A no i jest jeszcze jedna rzecz - skrypt configure wymaga modyfikacji 
 zeby wykrywal pthreads pod makiem - z linii 21268 configure (z 1.8.2):
 CFLAGS=-shared -fPIC -Wl,-z,defs $CFLAGS $PTHREAD_CFLAGS nalezy 
 wywalic -Wl,-z,defs inaczej pthready nie zostana wykryte
 To jest mój kod:
 
 r399 | porridge | 2005-04-28 00:35:20 +0100 (Thu, 28 Apr 2005) | 2 lines
 Changed paths:
M /trunk/m4/acx_pthread.m4
 - wyłączenie sprawdzania błędów w GCC dot. pthreads przy 
 --disable-shared i
   reorganzacja tegoż sprawdzania w acx_pthread.m4 (porridge)
 
 Komentarz nad tą linią:
 -Wl,-z,defs forces link-time symbol resolution, so that the linking 
 checks with -shared actually have any value
 Nadal wydaje mi się, że to jest potrzebne. Czy możesz podesłać 
 config.log z
 próby skonfigurowania libgadu gdy ta flaga jest jak w oryginale?
 Plik config.log znajduje sie w zalaczniku.
 configure:21272: checking whether -pthread is sufficient with -shared
 configure:21297: gcc -o conftest -shared -fPIC -Wl,-z,defs -g -O2 -Wall   
  conftest.c   5
 conftest.c:22:1: warning: GG_LIBGADU_VERSION redefined
 conftest.c:21:1: warning: this is the location of the previous definition
 conftest.c: In function 'main':
 conftest.c:31: warning: 'th' is used uninitialized in this function
 ld: unknown option: -z
 collect2: ld returned 1 exit status
 Hm, może to nie jest GNU ld, więc nie lubi -z defs?
 Chyba trzeba będzie wprowadzić podprzypadek..

 To nie jest GNU ld. Man do tej wersji ld znajduje sie np. tutaj: 
 http://developer.apple.com/documentation/Darwin/Reference/Manpages/man1/ld64.1.html

Według tej strony:

| -undefined treatment
| Specifies how undefined symbols are to be treated.  Options 
are: error, warning, suppress,
| or dynamic_lookup.  The default is error.

czyli wygląda jakby ten linker domyślnie robił to co ta flaga wymuszała.
Zresztą nawet jeśli nie, to nie mamy za bardzo wyboru - zmieniłem kod (w
trunk) tak, aby używał -Wl,-z,defs tylko gdy mamy do czynienia z GNU ld.

W moim systemie działa, a makro którego użyłem jest definiowane przez
libtoola, więc chyba nic nie popsułem.

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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?

[Marcin Owsiany]

On Thu, Dec 18, 2008 at 09:29:46PM +0100, Tomek wrote:
 A no i jest jeszcze jedna rzecz - skrypt configure wymaga modyfikacji 
 zeby wykrywal pthreads pod makiem - z linii 21268 configure (z 1.8.2):
 CFLAGS=-shared -fPIC -Wl,-z,defs $CFLAGS $PTHREAD_CFLAGS nalezy 
 wywalic -Wl,-z,defs inaczej pthready nie zostana wykryte

To jest mój kod:


r399 | porridge | 2005-04-28 00:35:20 +0100 (Thu, 28 Apr 2005) | 2 lines
Changed paths:
   M /trunk/m4/acx_pthread.m4

- wyłączenie sprawdzania błędów w GCC dot. pthreads przy --disable-shared i
  reorganzacja tegoż sprawdzania w acx_pthread.m4 (porridge)


Komentarz nad tą linią:
-Wl,-z,defs forces link-time symbol resolution, so that the linking checks with 
-shared actually have any value

Nadal wydaje mi się, że to jest potrzebne. Czy możesz podesłać config.log z
próby skonfigurowania libgadu gdy ta flaga jest jak w oryginale?

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
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?

[Marcin Owsiany]

On Fri, Dec 19, 2008 at 06:37:38PM +0100, Tomek wrote:
 Marcin Owsiany pisze:
 On Thu, Dec 18, 2008 at 09:29:46PM +0100, Tomek wrote:
 A no i jest jeszcze jedna rzecz - skrypt configure wymaga modyfikacji 
 zeby wykrywal pthreads pod makiem - z linii 21268 configure (z 1.8.2):
 CFLAGS=-shared -fPIC -Wl,-z,defs $CFLAGS $PTHREAD_CFLAGS nalezy wywalic 
 -Wl,-z,defs inaczej pthready nie zostana wykryte
 To jest mój kod:
 
 r399 | porridge | 2005-04-28 00:35:20 +0100 (Thu, 28 Apr 2005) | 2 lines
 Changed paths:
M /trunk/m4/acx_pthread.m4
 - wyłączenie sprawdzania błędów w GCC dot. pthreads przy 
 --disable-shared i
   reorganzacja tegoż sprawdzania w acx_pthread.m4 (porridge)
 
 Komentarz nad tą linią:
 -Wl,-z,defs forces link-time symbol resolution, so that the linking checks 
 with -shared actually have any value
 Nadal wydaje mi się, że to jest potrzebne. Czy możesz podesłać 
 config.log z
 próby skonfigurowania libgadu gdy ta flaga jest jak w oryginale?

 Plik config.log znajduje sie w zalaczniku.

 configure:21272: checking whether -pthread is sufficient with -shared
 configure:21297: gcc -o conftest -shared -fPIC -Wl,-z,defs -g -O2 -Wall
 conftest.c   5
 conftest.c:22:1: warning: GG_LIBGADU_VERSION redefined
 conftest.c:21:1: warning: this is the location of the previous definition
 conftest.c: In function 'main':
 conftest.c:31: warning: 'th' is used uninitialized in this function
 ld: unknown option: -z
 collect2: ld returned 1 exit status

Hm, może to nie jest GNU ld, więc nie lubi -z defs?
Chyba trzeba będzie wprowadzić podprzypadek..

-- 
Marcin Owsiany mar...@owsiany.pl  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Re: [libgadu-devel] [libgadu-commit] r619 - in trunk: include src

[Marcin Owsiany]

On Mon, Jun 09, 2008 at 09:53:02PM +0200, Wojtek Kaniewski wrote:
 To jedna z wielu zmian, które będą wymagane do obsługi protokołu 
 Gadu-Gadu 8.0, więc spokojnie :)

OK, wolę ponarzekać i wyjść na głupka niż przepuścić błąd :)

 Poza tym to tylko rozszerzenie ABI i 
 stare aplikacje będą działać bez problemu.

Napewno? Wydawało mi się, że dodanie pola do struktury, a co za tym
idzie zmiana jej rozmiaru, powoduje że ABI się sypie? Chyba po to
własnie czasami dodaje się pola dummy żeby usuwając je przy dodawaniu
nowych pól zachować rozmiar struktury?

Marcin
-- 
Marcin Owsiany [EMAIL PROTECTED]  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

[libgadu-devel] Problem z SVN log

[Marcin Owsiany]

$ svn log https://toxygen.net/svn/libgadu/trunk  /dev/null
[...]
svn: żądanie REPORT nie powiodło się dla '/svn/libgadu/!svn/bc/540/trunk'
svn: REPORT z '/svn/libgadu/!svn/bc/540/trunk': 200 OK (https://toxygen.net)
$

W efekcie najstarszy wpis w logu jaki dostaję to r454

Dostaję identyczny błąd używając 1.4.2 i 1.4.6

-- 
Marcin Owsiany [EMAIL PROTECTED]  http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216
 
Every program in development at MIT expands until it can read mail.
  -- Unknown
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel