1. 03 Feb, 2011 1 commit
  2. 29 Jan, 2011 1 commit
  3. 28 Jan, 2011 1 commit
  4. 27 Jan, 2011 2 commits
  5. 19 Jan, 2011 1 commit
  6. 29 Oct, 2010 1 commit
  7. 28 Oct, 2010 1 commit
  8. 18 Oct, 2010 1 commit
  9. 31 Mar, 2010 2 commits
  10. 30 Mar, 2010 1 commit
  11. 29 Mar, 2010 2 commits
  12. 08 Dec, 2009 1 commit
  13. 28 Nov, 2009 1 commit
  14. 28 Oct, 2009 1 commit
  15. 27 Oct, 2009 2 commits
  16. 22 Oct, 2009 2 commits
  17. 21 Oct, 2009 1 commit
    • Jeremy Huddleston's avatar
      This is not a GNU project, so declare it foreign. · 6f756640
      Jeremy Huddleston authored
      On Wed, 2009-10-21 at 13:36 +1000, Peter Hutterer wrote:
      > On Tue, Oct 20, 2009 at 08:23:55PM -0700, Jeremy Huddleston wrote:
      > > I noticed an INSTALL file in xlsclients and libXvMC today, and it
      > > was quite annoying to work around since 'autoreconf -fvi' replaces
      > > it and git wants to commit it.  Should these files even be in git?
      > > Can I nuke them for the betterment of humanity and since they get
      > > created by autoreconf anyways?
      >
      > See https://bugs.freedesktop.org/show_bug.cgi?id=24206
      
      As an interim measure, replace AM_INIT_AUTOMAKE([dist-bzip2]) with
      AM_INIT_AUTOMAKE([foreign dist-bzip2]). This will prevent the generation
      of the INSTALL file. It is also part of the 24206 solution.
      Signed-off-by: 's avatarJeremy Huddleston <jeremyhu@freedesktop.org>
      6f756640
  18. 13 Oct, 2009 1 commit
  19. 09 Oct, 2009 1 commit
  20. 08 Oct, 2009 1 commit
  21. 06 Oct, 2009 4 commits
  22. 29 Jan, 2009 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      Janitor: Correct make distcheck and sparse warnings. · 5957fdd9
      Paulo Cesar Pereira de Andrade authored
        Use only one toplevel .gitignore file.
      
        It was tempting to also modify the code to not, first check if
      xrender is >= 0.8.2, and then, if failing, check for libXrender
      functions with different build options, but left as is, as it
      could be somehow useful at least as an example of being backwards
      compatible.
      5957fdd9
  23. 22 Nov, 2008 1 commit
  24. 25 Oct, 2008 1 commit
  25. 02 Jul, 2008 1 commit
  26. 11 Jun, 2008 1 commit
  27. 10 Jun, 2008 1 commit
  28. 24 Mar, 2008 1 commit
  29. 09 Mar, 2008 1 commit
  30. 06 Dec, 2007 1 commit
  31. 04 Nov, 2007 1 commit
  32. 12 Sep, 2007 1 commit
    • Karl Tomlinson's avatar
      XftFontOpenInfo: Use of uninitialised value of size 8 (bug 11200) · 8ae5ea8c
      Karl Tomlinson authored
      This is due to XftFontInfoFill using the binary representation of the
      XftFontInfo to generate fi->hash.
      
      With 64-bit pointers there is padding between .hash and .file in struct
      _XftFontInfo.  This padding is not initialized, and the hash uses these
      bytes.
      
      This will interfere with finding "a matching previously opened font" in
      XftFontOpenInfo, and XftFontInfoEqual, which uses memcmp, will have similar
      problems.
      
      This fix makes no assumptions about the sizes and alignment of members of
      struct _XftFontInfo by using memset.  (It also makes no assumptions about
      what FcPatternGet* does to its output parameter when it returns
      FcResultNoMatch.)
      8ae5ea8c