1. 30 Jul, 2019 2 commits
  2. 29 Jul, 2019 4 commits
  3. 03 Jul, 2019 2 commits
  4. 22 Jun, 2019 1 commit
  5. 21 Jun, 2019 1 commit
  6. 17 Jun, 2019 2 commits
  7. 09 Jun, 2019 4 commits
    • Matt Turner's avatar
      Use AC_SYS_LARGEFILE · 5464b302
      Matt Turner authored
      ... and include config.h in makekeys.c to get the definition of
      _FILE_OFFSET_BITS. Without it, libX11 can fail to build on a file
      system with 64-bit inode numbers.
      Bug: https://bugs.gentoo.org/550502
      Bug: https://bugs.gentoo.org/616140Signed-off-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
    • Ran Benita's avatar
      Compose.man: fix escaped hexadecimal char description · 33b9148a
      Ran Benita authored
      The man page says:
          Strings may be direct text encoded in the locale for which the
          compose file is to be used, or an escaped octal or hexadecimal
          character code.   Octal codes are specified as "\123" and
          hexadecimal codes as "\0x123a".
      But the grammar in the parser and the implementation say:
          ESCAPED_CHAR  ::= ('\\' | '\"' | OCTAL | HEX )
          HEX           ::= '\' (x|X) HEX_CHAR [HEX_CHAR]]
          HEX_CHAR      ::= (0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F|a|b|c|d|e|f)
      So "\0x123a" -> "\x3a".
      Signed-off-by: default avatarRan Benita <ran234@gmail.com>
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
    • ojab's avatar
      Compose sequences for rouble sign · d9b2cc35
      ojab authored
      Cyrillic combinations mirror the Qwerty-Jcuken keyboard layout.
      Signed-off-by: ojab's avatarSlava Kardakov <ojab@ojab.ru>
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
    • Pavel Labath's avatar
      Fix a leak in XCreateFontSet · 3f211616
      Pavel Labath authored
      a simple snippet like XFreeFontSet(d, XCreateFontSet(d, ...)) will generate lots of memory leaks,
      as evidenced by the following valgrind output:
      ==983== HEAP SUMMARY:
      ==983==     in use at exit: 39,409 bytes in 341 blocks
      ==983==   total heap usage: 4,795 allocs, 4,454 frees, 489,086 bytes allocated
      ==983== 1,688 (136 direct, 1,552 indirect) bytes in 1 blocks are definitely lost in loss record
      40 of 46
      ==983==    at 0x4C2B042: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==983==    by 0x56D5A93: add_codeset.clone.9 (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56D5FE0: load_generic (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56D7612: initialize (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56D7E75: _XlcCreateLC (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56F9A5F: _XlcUtf8Loader (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56DF815: _XOpenLC (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56B255A: XOpenOM (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56A665A: XCreateFontSet (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x4FCA80: conky::x11_output::create_gc() (x11.cc:746)
      ==983==    by 0x4FC3B4: conky::x11_output::use_own_window() (x11.cc:602)
      ==983==    by 0x4FAD42: conky::priv::own_window_setting::set(bool const&, bool) (x11.cc:92)
      ==983== LEAK SUMMARY:
      ==983==    definitely lost: 136 bytes in 1 blocks
      ==983==    indirectly lost: 1,552 bytes in 34 blocks
      ==983==      possibly lost: 0 bytes in 0 blocks
      ==983==    still reachable: 37,721 bytes in 306 blocks
      ==983==         suppressed: 0 bytes in 0 blocks
      This patch makes the leak dissappear (Well, at least the "definitely lost part". The "still
      reachable" thingy remains). After some analysis, I've discovered that the XLCd structure is
      destroyed improperly. The "constructor" is in lcGeneric.c, but the structure is destroyed using
      code from lcPublic.c. I've found that changing the destructor call to _XlcDestroyLC executes the
      correct code path, and I'm pretty sure this is correct (the object was constructed using
      _XlcCreateLC, it make sense to destroy it using its conterpart).
      So far I haven't observed any strange behaviour on my system caused by this change (although, I'm
      not sure, how many programs actually use this function).
      Signed-off-by: default avatarPavel Labath <pavelo@centrum.sk>
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
  8. 08 Jun, 2019 3 commits
    • Jon Turney's avatar
      Avoid using libtool wrapper for makekeys · 4645e219
      Jon Turney authored
      For Windows targets, libtool uses a wrapper executable, not a wrapper
      script (see [1]), which it compiles with the host compiler.  This
      doesn't work when cross-compiling.
      Since we don't actually need to link with anything, use the libtool flag
      -all-static to tell it to stay completely out of this.
      [1] https://www.gnu.org/software/libtool/manual/html_node/Wrapper-executables.html
    • Jon Turney's avatar
      Use EXEEXT_FOR_BUILD for makekeys · 6886d9ba
      Jon Turney authored
      Use EXEXT_FOR_BUILD, to fix cross-compiling where EXEEXT differs from
      EXEEXT_FOR_BUILD, such as when building for Windows from unix.
      (Note: As written, this assumes EXEEXT_FOR_BUILD is always empty when
      cross-compiling.  There could be some elaborate autodetection for
      EXEXT_FOR_BUILD, but for the moment, if you are cross-compiling from
      Windows to Unix, you'll need to set EXEEXT_FOR_BUILD explicity...)
    • Jon Turney's avatar
      Remove makekeys dependency on X headers · a121b7b0
      Jon Turney authored
      This is the patch from https://bugs.freedesktop.org/show_bug.cgi?id=6669
      by Pierre Ossman, reworked for master.
      Avoid using LIBS (which are for host, but we don't need) and rewrite
      makekeys slightly to avoid needing to include any X headers, which
      avoids potentially having -I with host paths in CFLAGS, which can cause
      standard headers e.g. stdio.h for the host to also be used, which can
      break things...
  9. 07 Jun, 2019 1 commit
  10. 14 May, 2019 1 commit
  11. 30 Apr, 2019 1 commit
  12. 16 Mar, 2019 3 commits
  13. 10 Mar, 2019 4 commits
  14. 23 Feb, 2019 7 commits
  15. 17 Feb, 2019 1 commit
  16. 16 Jan, 2019 2 commits
  17. 01 Jan, 2019 1 commit