Christian Persch [Fri, 3 Sep 2010 19:39:07 +0000 (15:39 -0400)]
Plug a mem leak in converter-stream test
==2396== 66 (24 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 565 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396== by 0x417BA38: g_charset_converter_convert (gcharsetconverter.c:344)
==2396== by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396== by 0x417C9EB: g_converter_input_stream_read (gconverterinputstream.c:403)
==2396== by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396== by 0x41A7B43: g_input_stream_read_all (ginputstream.c:256)
==2396== by 0x804B0E4: test_charset (converter-stream.c:682)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:37:56 +0000 (15:37 -0400)]
Plug a mem leak in converter-stream test
==2396== 39 (24 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 398 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396== by 0x80498F7: g_compressor_converter_convert (converter-stream.c:244)
==2396== by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396== by 0x417CBDE: g_converter_input_stream_read (gconverterinputstream.c:460)
==2396== by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396== by 0x804A832: test_compressor (converter-stream.c:545)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:37:08 +0000 (15:37 -0400)]
Plug a mem leak in g-file-info test
==2395== 64 bytes in 1 blocks are definitely lost in loss record 381 of 407
==2395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395== by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395== by 0x40571A5: g_realloc (gmem.c:181)
==2395== by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395== by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395== by 0x4199AA9: g_file_info_list_attributes (gfileinfo.c:646)
==2395== by 0x80491CE: test_g_file_info (g-file-info.c:76)
==2395== 132 (64 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 396 of 407
==2395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395== by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395== by 0x40571A5: g_realloc (gmem.c:181)
==2395== by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395== by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395== by 0x4199A82: g_file_info_list_attributes (gfileinfo.c:642)
==2395== by 0x80492B7: test_g_file_info (g-file-info.c:86)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:35:44 +0000 (15:35 -0400)]
Plug a mem leak in the readwrite test
And use g_assert_[no_]error().
==2392== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 451 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2392== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2392== by 0x41B7619: g_output_stream_set_pending (goutputstream.c:1198)
==2392== by 0x41B5799: g_output_stream_write (goutputstream.c:210)
==2392== by 0x41B590B: g_output_stream_write_all (goutputstream.c:268)
==2392== by 0x8049B54: verify_iostream (readwrite.c:110)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:34:12 +0000 (15:34 -0400)]
Plug a mem leak in the readwrite test
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 369 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x804A2B9: test_g_file_replace_readwrite (readwrite.c:235)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:33:28 +0000 (15:33 -0400)]
Plug a mem leak in the readwrite test
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x8049F23: test_g_file_create_readwrite (readwrite.c:183)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:32:32 +0000 (15:32 -0400)]
Plug a mem leak in the readwrite test
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 367 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x8049E30: test_g_file_open_readwrite (readwrite.c:153)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:31:37 +0000 (15:31 -0400)]
Plug a mem leak in the memory-input-stream test
==2389== 84 (44 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 299 of 315
==2389== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389== by 0x4057094: g_malloc (gmem.c:134)
==2389== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2389== by 0x412372A: g_object_constructor (gobject.c:1482)
==2389== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2389== by 0x4122B93: g_object_new (gobject.c:1178)
==2389== by 0x41AF54C: g_memory_input_stream_new (gmemoryinputstream.c:199)
==2389== by 0x8048BD1: test_read_chunks (memory-input-stream.c:40)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:30:47 +0000 (15:30 -0400)]
Plug a mem leak in the memory-input-stream test
==2389== 59 (24 direct, 35 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 315
==2389== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389== by 0x4057094: g_malloc (gmem.c:134)
==2389== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2389== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2389== by 0x41AFD15: g_memory_input_stream_truncate (gmemoryinputstream.c:517)
==2389== by 0x41BAC0F: g_seekable_truncate (gseekable.c:174)
==2389== by 0x8049595: test_truncate (memory-input-stream.c:123)
Bug #628331.
Christian Persch [Fri, 3 Sep 2010 19:29:51 +0000 (15:29 -0400)]
Plug a mem leak in gsettings test
==2530== 13 bytes in 1 blocks are definitely lost in loss record 373 of 681
==2530== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2530== by 0x4057094: g_malloc (gmem.c:134)
==2530== by 0x40573DB: g_malloc_n (gmem.c:281)
==2530== by 0x40717FC: g_strdup (gstrfuncs.c:101)
==2530== by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==2530== by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==2530== by 0x41240FF: g_object_get (gobject.c:1731)
==2530== by 0x804A4BA: test_basic (gsettings.c:28)
Bug #628331.
Christian Persch [Tue, 31 Aug 2010 17:42:32 +0000 (19:42 +0200)]
Plug a mem leak
Don't leak the ptr arrays in the map_sender_unique_name_to_signal_data_array
hash table.
==23440== 84 (20 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 920 of 993
==23440== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23440== by 0x4057094: g_malloc (gmem.c:134)
==23440== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23440== by 0x401D2D0: g_ptr_array_sized_new (garray.c:799)
==23440== by 0x401D2AC: g_ptr_array_new (garray.c:783)
==23440== by 0x420834A: g_dbus_connection_signal_subscribe (gdbusconnection.c:3084)
Bug #628436.
Christian Persch [Mon, 30 Aug 2010 17:31:09 +0000 (19:31 +0200)]
Plug a mem leak
==31063== 98 (24 direct, 74 indirect) bytes in 1 blocks are definitely lost in loss record 946 of 1,136
==31063== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==31063== by 0x4057094: g_malloc (gmem.c:134)
==31063== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==31063== by 0x4092383: g_variant_get_child_value (gvariant-core.c:847)
==31063== by 0x408BE9E: g_variant_get_variant (gvariant.c:709)
==31063== by 0x40903F5: g_variant_valist_get_nnp (gvariant.c:3767)
==31063== by 0x40907A9: g_variant_valist_get_leaf (gvariant.c:3884)
==31063== by 0x4090D10: g_variant_valist_get (gvariant.c:4065)
==31063== by 0x4090E59: g_variant_valist_get (gvariant.c:4100)
==31063== by 0x40911B6: g_variant_get_va (gvariant.c:4296)
==31063== by 0x40910BC: g_variant_get (gvariant.c:4248)
==31063== by 0x4208DAF: invoke_set_property_in_idle_cb (gdbusconnection.c:3676)
Bug #628346.
Christian Persch [Mon, 30 Aug 2010 17:00:05 +0000 (19:00 +0200)]
Plug a mem leak
... and use g_error_matches().
==29535== 1,360 (408 direct, 952 indirect) bytes in 17 blocks are definitely lost in loss record 1,252 of 1,264
==29535== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535== by 0x4057094: g_malloc (gmem.c:134)
==29535== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==29535== by 0x403A751: g_error_new_valist (gerror.c:54)
==29535== by 0x403AAD4: g_set_error (gerror.c:240)
==29535== by 0x41C06C8: g_socket_send_message (gsocket.c:2967)
==29535== by 0x421CB64: write_message_continue_writing (gdbusprivate.c:958)
==29535== by 0x421CE2A: write_message_async (gdbusprivate.c:1049)
==29535== by 0x421D4DD: maybe_write_next_message (gdbusprivate.c:1291)
==29535== by 0x421D26B: message_written (gdbusprivate.c:1187)
==29535== by 0x421D322: write_message_cb (gdbusprivate.c:1216)
Bug #628345.
Matthias Clasen [Fri, 3 Sep 2010 18:52:16 +0000 (14:52 -0400)]
Make ordering for overridden interface properties consistent
g_object_class_list_properties tries to sort the returned list of
paramspecs by 'type depth' and param_id. But all the overridden
interface properties have a param_id of 0, so they come out in
a random order.
Bug 628253.
Tor Lillqvist [Thu, 2 Sep 2010 18:56:02 +0000 (21:56 +0300)]
Recuce DLL hijack risk on Windows
Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.
For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.
Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
Kjartan Maraas [Thu, 2 Sep 2010 09:56:09 +0000 (11:56 +0200)]
Updated Norwegian bokmål translation
noch [Thu, 2 Sep 2010 07:35:02 +0000 (12:35 +0500)]
Modified Armenian translation - po file
Christian Persch [Wed, 1 Sep 2010 13:05:59 +0000 (15:05 +0200)]
Fix building with zlib < 1.2.4 on win32
The gzip header processing functions were only exported
since 1.2.4 on win32, so #ifdef this code accordingly.
Bug #628505.
Ryan Lortie [Wed, 1 Sep 2010 13:04:41 +0000 (15:04 +0200)]
Fix small bug in registry backend
'n' and 'q' types had their signed/unsigned meaning inverted.
Sam Thursfield [Thu, 12 Aug 2010 15:10:23 +0000 (16:10 +0100)]
Add GSettings Windows Registry backend
Jon Nordby [Thu, 26 Aug 2010 14:51:33 +0000 (16:51 +0200)]
docs: Inline docs from tmpl/memory.smgl
Andika Triwidada [Wed, 1 Sep 2010 02:54:52 +0000 (09:54 +0700)]
Updated Indonesian translation
noch [Tue, 31 Aug 2010 11:49:31 +0000 (16:49 +0500)]
Modified hy.po
noch [Tue, 31 Aug 2010 07:34:36 +0000 (12:34 +0500)]
Modified hy.po
Matthias Clasen [Tue, 31 Aug 2010 00:47:40 +0000 (20:47 -0400)]
Bump version
Matthias Clasen [Mon, 30 Aug 2010 23:29:09 +0000 (19:29 -0400)]
Update symbol list
Branko Kokanović [Tue, 31 Aug 2010 00:33:26 +0000 (02:33 +0200)]
Updated Serbian translation
Philip Withnall [Mon, 30 Aug 2010 21:13:18 +0000 (22:13 +0100)]
Update British English translation
Matthias Clasen [Mon, 30 Aug 2010 20:08:25 +0000 (16:08 -0400)]
Add one more bug ref
David Zeuthen [Mon, 30 Aug 2010 17:58:41 +0000 (13:58 -0400)]
GDBusProxy: remove superfluous -gdbus-proxy-method-name qdata
Looks like we're not using this anymore.
Signed-off-by: David Zeuthen <davidz@redhat.com>
David Zeuthen [Mon, 30 Aug 2010 17:45:46 +0000 (13:45 -0400)]
Bug 628324 – Invalid reads in gdbus-export test
Looks like we forgot to ref the returned GVariant in
g_dbus_proxy_call_finish().
It's a good question why code using g_dbus_proxy_call() and
g_dbus_proxy_call_finish() worked in the first place - probably the
answer is that no-one really used these APIs.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Matthias Clasen [Mon, 30 Aug 2010 17:28:06 +0000 (13:28 -0400)]
Tweak the wording
Ryan Lortie [Mon, 30 Aug 2010 16:58:49 +0000 (18:58 +0200)]
GAction is now an interface
the new class GSimpleAction is the implementation half
Ryan Lortie [Mon, 30 Aug 2010 15:31:06 +0000 (17:31 +0200)]
GActionGroup is now an interface
- make GAction.get_state() return a reference
- fix some leaks/warnings in the tests
- fix signal propagation in GSimpleActionGroup
Matthias Clasen [Mon, 30 Aug 2010 17:11:52 +0000 (13:11 -0400)]
Update NEWS for 2.25.15
Christian Persch [Mon, 30 Aug 2010 14:12:42 +0000 (16:12 +0200)]
Make g_emblemed_icon_add_emblem() keep the list sorted
Fixes bug #628317.
Christian Persch [Mon, 30 Aug 2010 13:53:49 +0000 (15:53 +0200)]
Don't leak the FD list
==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 780 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==6793== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==6793== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==6793== by 0x412372A: g_object_constructor (gobject.c:1482)
==6793== by 0x4122E1D: g_object_newv (gobject.c:1266)
==6793== by 0x4122B93: g_object_new (gobject.c:1178)
==6793== by 0x41DB582: g_unix_fd_list_new_from_array (gunixfdlist.c:191)
==6793== by 0x421BFD6: _g_dbus_worker_do_read_cb (gdbusprivate.c:590)
Bug #628329.
Christian Persch [Mon, 30 Aug 2010 14:21:43 +0000 (10:21 -0400)]
Fix invalid reads
Don't use a guint16* when getting a guint property via g_object_get()!
Bug #628323.
Christian Persch [Mon, 30 Aug 2010 14:18:30 +0000 (10:18 -0400)]
Plug a mem leak in GConverterOutputStream
==8221== 1,047 (672 direct, 375 indirect) bytes in 28 blocks are definitely lost in loss record 589 of 603
==8221== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==8221== by 0x4057094: g_malloc (gmem.c:134)
==8221== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==8221== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==8221== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==8221== by 0x403AC31: g_set_error_literal (gerror.c:314)
==8221== by 0x80499DC: g_compressor_converter_convert (converter-stream.c:267)
==8221== by 0x417BF67: g_converter_convert (gconverter.c:174)
==8221== by 0x417D7F0: g_converter_output_stream_write (gconverteroutputstream.c:428)
==8221== by 0x41B57DF: g_output_stream_write (goutputstream.c:216)
==8221== by 0x804A367: test_compressor (converter-stream.c:456)
Bug #628309.
Christian Persch [Mon, 30 Aug 2010 14:16:31 +0000 (10:16 -0400)]
Plug a mem leak
==6793== 19 (8 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 640 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x40573DB: g_malloc_n (gmem.c:281)
==6793== by 0x4073D1B: g_strsplit (gstrfuncs.c:2436)
==6793== by 0x4224A89: initable_init (gdbusserver.c:1040)
==6793== by 0x41A73F9: g_initable_init (ginitable.c:105)
==6793== by 0x41A759B: g_initable_new_valist (ginitable.c:218)
==6793== by 0x41A743E: g_initable_new (ginitable.c:138)
==6793== by 0x42238F5: g_dbus_server_new_sync (gdbusserver.c:484)
Bug #628328.
Christian Persch [Mon, 30 Aug 2010 14:14:39 +0000 (10:14 -0400)]
Plug a mem leak
==6793== 16 bytes in 1 blocks are definitely lost in loss record 632 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x417FC29: g_data_input_stream_read_line (gdatainputstream.c:797)
==6793== by 0x41F99C1: _my_g_data_input_stream_read_line (gdbusauth.c:279)
==6793== by 0x41FA728: _g_dbus_auth_run_client (gdbusauth.c:759)
Bug #628327.
Matthias Clasen [Mon, 30 Aug 2010 14:02:32 +0000 (10:02 -0400)]
Add an annotation
Dan Winship [Mon, 30 Aug 2010 13:23:09 +0000 (09:23 -0400)]
GSocketClient: fix a crash on cancellation
some code rearrangement when adding proxy support resulted in trying to
use a GSocket that wasn't there.
https://bugzilla.gnome.org/show_bug.cgi?id=628296
Matthias Clasen [Mon, 30 Aug 2010 12:58:31 +0000 (08:58 -0400)]
Disable the 'extra data' test for now
Matthias Clasen [Mon, 30 Aug 2010 12:50:09 +0000 (08:50 -0400)]
Introspection: make 'direction' default to 'in' for methods
Matthias Clasen [Mon, 30 Aug 2010 12:49:41 +0000 (08:49 -0400)]
Add some more gdbus introspection tests (currently failing)
Branko Kokanović [Sun, 29 Aug 2010 17:07:46 +0000 (19:07 +0200)]
Updated Serbian translation
Yaron Shahrabani [Sun, 29 Aug 2010 12:57:41 +0000 (15:57 +0300)]
Updated Hebrew translation.
Jorge González [Sun, 29 Aug 2010 09:33:56 +0000 (11:33 +0200)]
Updated Spanish translation
A S Alam [Sun, 29 Aug 2010 04:02:03 +0000 (09:32 +0530)]
update translation for Punjabi
Fran Diéguez [Sun, 29 Aug 2010 02:19:12 +0000 (04:19 +0200)]
Added Galician help translations
Philip Withnall [Sat, 28 Aug 2010 11:18:37 +0000 (12:18 +0100)]
Change "type-string" to "type string" in translatable strings
Helps: bgo#628193
Philip Withnall [Sat, 28 Aug 2010 11:17:45 +0000 (12:17 +0100)]
Change "lock-file" to "lock file" in translatable strings
Helps: bgo#628193
Philip Withnall [Sat, 28 Aug 2010 10:54:01 +0000 (11:54 +0100)]
Update British English translation
Jorge González [Sat, 28 Aug 2010 08:08:04 +0000 (10:08 +0200)]
Updated Spanish translation
Yaron Shahrabani [Sat, 28 Aug 2010 07:46:19 +0000 (10:46 +0300)]
Updated Hebrew translation.
Fran Diéguez [Fri, 27 Aug 2010 21:15:49 +0000 (23:15 +0200)]
Update Galician translations
Claude Paroz [Fri, 27 Aug 2010 18:04:38 +0000 (20:04 +0200)]
Added missing files in POTFILES.in
David Zeuthen [Fri, 27 Aug 2010 14:50:03 +0000 (10:50 -0400)]
Bug 628084 – gdbus-peer fails with assertion
Make it work on systems where /etc/hosts is bigger than 1024 bytes.
https://bugzilla.gnome.org/show_bug.cgi?id=628084
Signed-off-by: David Zeuthen <davidz@redhat.com>
Yaron Shahrabani [Fri, 27 Aug 2010 11:53:57 +0000 (14:53 +0300)]
Updated Hebrew translation.
Jens Georg [Tue, 24 Aug 2010 21:18:23 +0000 (00:18 +0300)]
Improve parsing of date-only iso8601 strings
Emmanuele Bassi [Thu, 26 Aug 2010 11:58:19 +0000 (12:58 +0100)]
datetime: Re-use add_dmy()
Avoid code duplication.
Tor Lillqvist [Thu, 26 Aug 2010 09:41:46 +0000 (12:41 +0300)]
Fix Win32 build
Matthias Clasen [Thu, 26 Aug 2010 04:16:30 +0000 (00:16 -0400)]
Make this thing work
Matthias Clasen [Thu, 26 Aug 2010 04:00:56 +0000 (00:00 -0400)]
Improve g_file_set_contents docs
Mention that the temporary filename is longer than the passed-in
filename, so people can avoid passing a name that is already
NAME_MAX long.
Matthias Clasen [Thu, 26 Aug 2010 02:07:59 +0000 (22:07 -0400)]
Point out that g_type_init() is required
A S Alam [Wed, 25 Aug 2010 16:30:53 +0000 (22:00 +0530)]
update translation for Punjabi
Matthias Clasen [Thu, 26 Aug 2010 00:04:45 +0000 (20:04 -0400)]
Guarantee that g_get_tmp_dir () doesn't return an empty string
If it does, g_file_open_tmp() would be in trouble. Pointed
out by Morten Welinder in bug 627969.
Matthias Clasen [Wed, 25 Aug 2010 22:44:59 +0000 (18:44 -0400)]
NEWS for 2.25.15
Emmanuele Bassi [Wed, 25 Aug 2010 22:08:18 +0000 (23:08 +0100)]
datetime: Fix a thinko
We need to check if a year is a leap one *after* we increased it with
the given value, not before.
Emmanuele Bassi [Wed, 25 Aug 2010 22:00:31 +0000 (23:00 +0100)]
datetime: Avoid excessive copies in add_full()
The current implementation of g_date_time_add_full() creates multiple
GDateTime temporary objects and unrefs them immediately; even with the
slice allocator this could result in a performance bottleneck,
especially if the atomic integer operations fall back to slow paths.
We can isolate the components of the add_full() operation and create
internal modifiers that operate on an existing GDateTime; this brings
down the number of GDateTime copies created from six to one.
While at it, the test suite for add_full() should have more checks for
roll-over of months and days.
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
David Zeuthen [Wed, 25 Aug 2010 18:45:28 +0000 (14:45 -0400)]
GDBusConnection: Document memory management semantics for get_property()
Turns out we are leaking non-floating GVariant instances returned by
get_property() functions.
Also avoid imprecise language such as "newly-allocated GVariant" as
this doesn't specify whether the variant can be floating or not.
Also see https://bugzilla.gnome.org/show_bug.cgi?id=627974 as it is
very related to this change.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Emmanuele Bassi [Wed, 25 Aug 2010 15:24:46 +0000 (16:24 +0100)]
docs: Fix up GDateTime for the GObject reference
Emmanuele Bassi [Wed, 25 Aug 2010 15:23:34 +0000 (16:23 +0100)]
docs: Reword the datetime short description
Emmanuele Bassi [Wed, 25 Aug 2010 15:13:24 +0000 (16:13 +0100)]
docs: Fix the section name for GDateTime
Emmanuele Bassi [Wed, 25 Aug 2010 11:30:09 +0000 (12:30 +0100)]
datetime: Fix leap year check
Remove a FIXME and an approximation when computing the seconds from
the Unix epoch.
Emmanuele Bassi [Wed, 25 Aug 2010 11:24:54 +0000 (12:24 +0100)]
datetime: Fix coding style
Emmanuele Bassi [Wed, 25 Aug 2010 11:14:04 +0000 (12:14 +0100)]
datetime: Use %Z for the timezone name
We should try and follow strftime(3) for the format control characters
as much as possible.
Emmanuele Bassi [Wed, 25 Aug 2010 11:09:16 +0000 (12:09 +0100)]
datetime: Fix the format documentation
The %x format is for the preferred date, and the %X format is for the
preferred time.
Emmanuele Bassi [Wed, 25 Aug 2010 11:06:47 +0000 (12:06 +0100)]
datetime: Clean up macros and unused variables
The most complex macros should be converted to inlined functions,
instead, to guarantee some type safety.
Emmanuele Bassi [Tue, 24 Aug 2010 23:27:49 +0000 (00:27 +0100)]
datetime: Remove the translation marker for a warning message
Emmanuele Bassi [Tue, 24 Aug 2010 22:30:30 +0000 (23:30 +0100)]
docs: Add GDateTime to the GLib API reference
Emmanuele Bassi [Tue, 24 Aug 2010 20:37:43 +0000 (21:37 +0100)]
docs: Mention TZDIR
The timezone code in GDateTime honours the TZDIR environment variable,
so it should be mentioned in the list of variables GLib checks at
runtime.
Thiago Santos [Fri, 28 May 2010 11:19:29 +0000 (08:19 -0300)]
datetime: Add GDateTime to the GType system
As with other GLib data types, use a GBoxed.
Thiago Santos [Fri, 28 May 2010 11:19:29 +0000 (08:19 -0300)]
Add GDateTime to GLib
GDateTime is an opaque data type containing a date and time
representation. It's immutable once created and reference
counted.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Based on the code by: Christian Hergert <chris@dronelabs.com>
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Emmanuele Bassi [Tue, 24 Aug 2010 21:47:02 +0000 (22:47 +0100)]
Add C_() to glibintl.h
Cody Russell [Mon, 23 Aug 2010 17:34:53 +0000 (12:34 -0500)]
Add const to _pcre_ucp_othercase() definition in pcre_internal.h
Jorge González [Mon, 23 Aug 2010 15:40:02 +0000 (17:40 +0200)]
Updated Spanish translation
Tor Lillqvist [Mon, 23 Aug 2010 11:31:20 +0000 (14:31 +0300)]
Include gproxyaddress.h explicitly
Matthias Clasen [Mon, 23 Aug 2010 04:37:52 +0000 (00:37 -0400)]
Improve testutils test coverage
Matthias Clasen [Mon, 23 Aug 2010 04:37:37 +0000 (00:37 -0400)]
Improve printf test coverage
Matthias Clasen [Mon, 23 Aug 2010 04:37:21 +0000 (00:37 -0400)]
Improve GDate test coverate
Matthias Clasen [Mon, 23 Aug 2010 04:36:36 +0000 (00:36 -0400)]
Improve GDBus introspection test coverage
David Zeuthen [Mon, 23 Aug 2010 02:56:49 +0000 (22:56 -0400)]
GDBusMethodInvocation: nuke constructor
... that is, make it private. This makes sense because users are never
expected to create such objects themselves - only the GDBus core will
need this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Fran Diéguez [Mon, 23 Aug 2010 00:24:25 +0000 (02:24 +0200)]
Updated galician translations
Jorge González [Sun, 22 Aug 2010 19:17:53 +0000 (21:17 +0200)]
Updated Spanish translation
David Zeuthen [Fri, 6 Aug 2010 00:37:27 +0000 (20:37 -0400)]
Bug 624546 – Modification of GDBusMessage in filter function
Allow modifying a GDBusMessage in a filter function and also add tests
for this. This breaks API but leaves ABI (almost) intact - at least
dconf's GSettings backend (the only big user I know of) will keep
working.
https://bugzilla.gnome.org/show_bug.cgi?id=624546
Signed-off-by: David Zeuthen <davidz@redhat.com>
Ask H. Larsen [Sun, 22 Aug 2010 11:17:24 +0000 (13:17 +0200)]
Updated Danish translation
Matthias Clasen [Sun, 22 Aug 2010 02:22:25 +0000 (22:22 -0400)]
Add proxy extension point to overview docs
The 'Extending GIO' section is supposed to list all extension
points, so add the proxy extension point here.
Matthias Clasen [Sun, 22 Aug 2010 02:14:28 +0000 (22:14 -0400)]
Fix build on !unix
There was one code block still referring to fd_list outside of
the ifdef G_OS_UNIX. Pointed out by Sam Thursfield in bug 627392.
projects / platform / upstream / glib.git / log