Loading ...
Sorry, an error occurred while loading the content.
 

Patch 7.2a.001

Expand Messages
  • Bram Moolenaar
    Patch 7.2a.001 Problem: On some systems X11/Xlib.h exists (from X11-dev package) but X11/Intrinsic.h does not (in Xt-dev package). This breaks the build.
    Message 1 of 23 , Jun 26, 2008
      Patch 7.2a.001
      Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
      X11/Intrinsic.h does not (in Xt-dev package). This breaks the
      build. Also, on Solaris 9 sys/ptem.h isn't found.
      Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
      Check for sys/ptem.h while including sys/stream.h. (Vladimir
      Marek)
      Files: src/auto/configure, src/configure.in


      *** ../vim-7.2a.000/src/auto/configure Tue Jun 24 23:41:27 2008
      --- src/auto/configure Thu Jun 26 21:31:24 2008
      ***************
      *** 7565,7571 ****
      X_LIBS="`echo $X_LIBS\ | sed -e 's%-R/usr/lib %%' -e 's%-R /usr/lib %%'`"


      ! { $as_echo "$as_me:$LINENO: checking if X11 header files can be found" >&5
      $as_echo_n "checking if X11 header files can be found... " >&6; }
      cflags_save=$CFLAGS
      CFLAGS="$CFLAGS $X_CFLAGS"
      --- 7565,7571 ----
      X_LIBS="`echo $X_LIBS\ | sed -e 's%-R/usr/lib %%' -e 's%-R /usr/lib %%'`"


      ! { $as_echo "$as_me:$LINENO: checking if X11 header files can be found" >&5
      $as_echo_n "checking if X11 header files can be found... " >&6; }
      cflags_save=$CFLAGS
      CFLAGS="$CFLAGS $X_CFLAGS"
      ***************
      *** 7576,7581 ****
      --- 7576,7582 ----
      cat >>conftest.$ac_ext <<_ACEOF
      /* end confdefs.h. */
      #include <X11/Xlib.h>
      + #include <X11/Intrinsic.h>
      int
      main ()
      {
      ***************
      *** 10883,10894 ****



      -
      for ac_header in stdarg.h stdlib.h string.h sys/select.h sys/utsname.h \
      termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h sys/types.h termio.h \
      iconv.h langinfo.h math.h unistd.h stropts.h errno.h \
      sys/resource.h sys/systeminfo.h locale.h \
      ! sys/stream.h sys/ptem.h termios.h libc.h sys/statfs.h \
      poll.h sys/poll.h pwd.h utime.h sys/param.h libintl.h \
      libgen.h util/debug.h util/msg18n.h frame.h \
      sys/acl.h sys/access.h sys/sysctl.h sys/sysinfo.h wchar.h wctype.h
      --- 10884,10894 ----



      for ac_header in stdarg.h stdlib.h string.h sys/select.h sys/utsname.h \
      termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h sys/types.h termio.h \
      iconv.h langinfo.h math.h unistd.h stropts.h errno.h \
      sys/resource.h sys/systeminfo.h locale.h \
      ! sys/stream.h termios.h libc.h sys/statfs.h \
      poll.h sys/poll.h pwd.h utime.h sys/param.h libintl.h \
      libgen.h util/debug.h util/msg18n.h frame.h \
      sys/acl.h sys/access.h sys/sysctl.h sys/sysinfo.h wchar.h wctype.h
      ***************
      *** 11036,11041 ****
      --- 11036,11106 ----
      done


      +
      + for ac_header in sys/ptem.h
      + do
      + as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
      + { $as_echo "$as_me:$LINENO: checking for $ac_header" >&5
      + $as_echo_n "checking for $ac_header... " >&6; }
      + if { as_var=$as_ac_Header; eval "test \"\${$as_var+set}\" = set"; }; then
      + $as_echo_n "(cached) " >&6
      + else
      + cat >conftest.$ac_ext <<_ACEOF
      + /* confdefs.h. */
      + _ACEOF
      + cat confdefs.h >>conftest.$ac_ext
      + cat >>conftest.$ac_ext <<_ACEOF
      + /* end confdefs.h. */
      + #if defined HAVE_SYS_STREAM_H
      + # include <sys/stream.h>
      + #endif
      +
      + #include <$ac_header>
      + _ACEOF
      + rm -f conftest.$ac_objext
      + if { (ac_try="$ac_compile"
      + case "(($ac_try" in
      + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
      + *) ac_try_echo=$ac_try;;
      + esac
      + eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
      + $as_echo "$ac_try_echo") >&5
      + (eval "$ac_compile") 2>conftest.er1
      + ac_status=$?
      + grep -v '^ *+' conftest.er1 >conftest.err
      + rm -f conftest.er1
      + cat conftest.err >&5
      + $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
      + (exit $ac_status); } && {
      + test -z "$ac_c_werror_flag" ||
      + test ! -s conftest.err
      + } && test -s conftest.$ac_objext; then
      + eval "$as_ac_Header=yes"
      + else
      + $as_echo "$as_me: failed program was:" >&5
      + sed 's/^/| /' conftest.$ac_ext >&5
      +
      + eval "$as_ac_Header=no"
      + fi
      +
      + rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
      + fi
      + ac_res=`eval 'as_val=${'$as_ac_Header'}
      + $as_echo "$as_val"'`
      + { $as_echo "$as_me:$LINENO: result: $ac_res" >&5
      + $as_echo "$ac_res" >&6; }
      + if test `eval 'as_val=${'$as_ac_Header'}
      + $as_echo "$as_val"'` = yes; then
      + cat >>confdefs.h <<_ACEOF
      + #define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
      + _ACEOF
      +
      + fi
      +
      + done
      +
      +
      +
      { $as_echo "$as_me:$LINENO: checking for pthread_np.h" >&5
      $as_echo_n "checking for pthread_np.h... " >&6; }
      cat >conftest.$ac_ext <<_ACEOF
      *** ../vim-7.2a.000/src/configure.in Tue Jun 24 23:48:47 2008
      --- src/configure.in Thu Jun 26 21:31:19 2008
      ***************
      *** 1120,1130 ****


      dnl Check if the X11 header files are correctly installed. On some systems
      ! dnl Xlib.h includes files that don't exist
      AC_MSG_CHECKING(if X11 header files can be found)
      cflags_save=$CFLAGS
      CFLAGS="$CFLAGS $X_CFLAGS"
      ! AC_TRY_COMPILE([#include <X11/Xlib.h>], ,
      AC_MSG_RESULT(yes),
      AC_MSG_RESULT(no); no_x=yes)
      CFLAGS=$cflags_save
      --- 1120,1132 ----


      dnl Check if the X11 header files are correctly installed. On some systems
      ! dnl Xlib.h includes files that don't exist. On some systems X11/Intrinsic.h
      ! dnl is missing.
      AC_MSG_CHECKING(if X11 header files can be found)
      cflags_save=$CFLAGS
      CFLAGS="$CFLAGS $X_CFLAGS"
      ! AC_TRY_COMPILE([#include <X11/Xlib.h>
      ! #include <X11/Intrinsic.h>], ,
      AC_MSG_RESULT(yes),
      AC_MSG_RESULT(no); no_x=yes)
      CFLAGS=$cflags_save
      ***************
      *** 2071,2081 ****
      termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h sys/types.h termio.h \
      iconv.h langinfo.h math.h unistd.h stropts.h errno.h \
      sys/resource.h sys/systeminfo.h locale.h \
      ! sys/stream.h sys/ptem.h termios.h libc.h sys/statfs.h \
      poll.h sys/poll.h pwd.h utime.h sys/param.h libintl.h \
      libgen.h util/debug.h util/msg18n.h frame.h \
      sys/acl.h sys/access.h sys/sysctl.h sys/sysinfo.h wchar.h wctype.h)

      dnl pthread_np.h may exist but can only be used after including pthread.h
      AC_MSG_CHECKING([for pthread_np.h])
      AC_TRY_COMPILE([
      --- 2073,2090 ----
      termcap.h fcntl.h sgtty.h sys/ioctl.h sys/time.h sys/types.h termio.h \
      iconv.h langinfo.h math.h unistd.h stropts.h errno.h \
      sys/resource.h sys/systeminfo.h locale.h \
      ! sys/stream.h termios.h libc.h sys/statfs.h \
      poll.h sys/poll.h pwd.h utime.h sys/param.h libintl.h \
      libgen.h util/debug.h util/msg18n.h frame.h \
      sys/acl.h sys/access.h sys/sysctl.h sys/sysinfo.h wchar.h wctype.h)

      + dnl sys/ptem.h depends on sys/stream.h on Solaris
      + AC_CHECK_HEADERS(sys/ptem.h, [], [],
      + [#if defined HAVE_SYS_STREAM_H
      + # include <sys/stream.h>
      + #endif])
      +
      +
      dnl pthread_np.h may exist but can only be used after including pthread.h
      AC_MSG_CHECKING([for pthread_np.h])
      AC_TRY_COMPILE([
      *** ../vim-7.2a.000/src/version.c Tue Jun 24 23:51:48 2008
      --- src/version.c Thu Jun 26 22:08:32 2008
      ***************
      *** 678,679 ****
      --- 678,681 ----
      { /* Add new patch number below this line */
      + /**/
      + 1,
      /**/

      --
      I AM THANKFUL...
      ...for a lawn that needs mowing, windows that need cleaning
      and gutters that need fixing because it means I have a home.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... [...] And for those who, like me, are slow to readjust: the 7.2a patches directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of course it s
      Message 2 of 23 , Jun 26, 2008
        On 26/06/08 22:18, Bram Moolenaar wrote:
        >
        > Patch 7.2a.001
        > Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
        > X11/Intrinsic.h does not (in Xt-dev package). This breaks the
        > build. Also, on Solaris 9 sys/ptem.h isn't found.
        > Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
        > Check for sys/ptem.h while including sys/stream.h. (Vladimir
        > Marek)
        > Files: src/auto/configure, src/configure.in
        [...]

        And for those who, like me, are slow to readjust: the 7.2a patches
        directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of
        course it's accessible also by ftp). This means it's *not* a sibling of
        the 7.1 patches directory (it's in the "unstable" tree).


        Best regards,
        Tony.
        --
        If a listener nods his head when you're explaining your program, wake
        him up.

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Hisashi T Fujinaka
        ... Oh, boy. Is this 7.2a - 7.2.0 transition going to break version sorting again? -- Hisashi T Fujinaka - htodd@twofifty.com BSEE(6/86) + BSChem(3/95) +
        Message 3 of 23 , Jun 26, 2008
          On Thu, 26 Jun 2008, Tony Mechelynck wrote:

          >
          > On 26/06/08 22:18, Bram Moolenaar wrote:
          >>
          >> Patch 7.2a.001
          >> Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
          >> X11/Intrinsic.h does not (in Xt-dev package). This breaks the
          >> build. Also, on Solaris 9 sys/ptem.h isn't found.
          >> Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
          >> Check for sys/ptem.h while including sys/stream.h. (Vladimir
          >> Marek)
          >> Files: src/auto/configure, src/configure.in
          > [...]
          >
          > And for those who, like me, are slow to readjust: the 7.2a patches
          > directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of
          > course it's accessible also by ftp). This means it's *not* a sibling of
          > the 7.1 patches directory (it's in the "unstable" tree).

          Oh, boy. Is this 7.2a -> 7.2.0 transition going to break version sorting
          again?

          --
          Hisashi T Fujinaka - htodd@...
          BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • François Ingelrest
          ... Is, by any chance, an AAP recipe going to be set up? That s much simpler on user s side, although maybe not on your side.
          Message 4 of 23 , Jun 26, 2008
            On Thu, Jun 26, 2008 at 22:18, Bram Moolenaar <Bram@...> wrote:
            > Patch 7.2a.001
            > Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
            > X11/Intrinsic.h does not (in Xt-dev package). This breaks the
            > build. Also, on Solaris 9 sys/ptem.h isn't found.
            > Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
            > Check for sys/ptem.h while including sys/stream.h. (Vladimir
            > Marek)
            > Files: src/auto/configure, src/configure.in

            Is, by any chance, an AAP recipe going to be set up? That's much
            simpler on user's side, although maybe not on your side.

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Antonio Colombo
            Hi François, ... as a matter of fact, aap update using CVS gives you the new 7.2a BETA version. Cheers, Antonio -- /|| | Antonio Colombo / || |
            Message 5 of 23 , Jun 27, 2008
              Hi François,

              > Is, by any chance, an AAP recipe going to be set up?

              as a matter of fact, "aap update" using CVS gives you
              the new 7.2a BETA version.

              Cheers, Antonio
              --
              /||\ | Antonio Colombo
              / || \ | antonio@...
              / () \ | azc100@...
              (___||___) | azc10@...


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • François Ingelrest
              ... Thanks! Actually I did not try CVS at first because I can t use it at home---I have a shared Internet connection with most ports blocked---, but I can
              Message 6 of 23 , Jun 27, 2008
                On Fri, Jun 27, 2008 at 11:22, Antonio Colombo <azc100@...> wrote:
                > > Is, by any chance, an AAP recipe going to be set up?
                >
                > as a matter of fact, "aap update" using CVS gives you
                > the new 7.2a BETA version.

                Thanks! Actually I did not try CVS at first because I can't use it at
                home---I have a shared Internet connection with most ports blocked---,
                but I can stand updating Vim at work.

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Bram Moolenaar
                ... Well, it means that everybody will get the beta test version. Since I did quite a few last-minute changes I was awaiting success/fail reports first. It
                Message 7 of 23 , Jun 27, 2008
                  Francois Ingelrest wrote:

                  > On Thu, Jun 26, 2008 at 22:18, Bram Moolenaar <Bram@...> wrote:
                  > > Patch 7.2a.001
                  > > Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
                  > > X11/Intrinsic.h does not (in Xt-dev package). This breaks the
                  > > build. Also, on Solaris 9 sys/ptem.h isn't found.
                  > > Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
                  > > Check for sys/ptem.h while including sys/stream.h. (Vladimir
                  > > Marek)
                  > > Files: src/auto/configure, src/configure.in
                  >
                  > Is, by any chance, an AAP recipe going to be set up? That's much
                  > simpler on user's side, although maybe not on your side.

                  Well, it means that everybody will get the beta test version. Since I
                  did quite a few last-minute changes I was awaiting success/fail reports
                  first. It looks like 7.2a is doing quite well, so I might indeed update
                  the script. Those who use CVS got it already anyway.

                  --
                  From "know your smileys":
                  :-| :-| Deja' vu!

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ download, build and distribute -- http://www.A-A-P.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • François Ingelrest
                  ... Isn t it possible to create a specific recipe for v7.2, different from the official one? The latter could still point to the current version, it doesn t
                  Message 8 of 23 , Jun 27, 2008
                    On Fri, Jun 27, 2008 at 15:42, Bram Moolenaar <Bram@...> wrote:
                    >
                    > Francois Ingelrest wrote:
                    >
                    >> On Thu, Jun 26, 2008 at 22:18, Bram Moolenaar <Bram@...> wrote:
                    >> > Patch 7.2a.001
                    >> > Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
                    >> > X11/Intrinsic.h does not (in Xt-dev package). This breaks the
                    >> > build. Also, on Solaris 9 sys/ptem.h isn't found.
                    >> > Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
                    >> > Check for sys/ptem.h while including sys/stream.h. (Vladimir
                    >> > Marek)
                    >> > Files: src/auto/configure, src/configure.in
                    >>
                    >> Is, by any chance, an AAP recipe going to be set up? That's much
                    >> simpler on user's side, although maybe not on your side.
                    >
                    > Well, it means that everybody will get the beta test version. Since I
                    > did quite a few last-minute changes I was awaiting success/fail reports
                    > first. It looks like 7.2a is doing quite well, so I might indeed update
                    > the script. Those who use CVS got it already anyway.

                    Isn't it possible to create a specific recipe for v7.2, different from
                    the "official" one? The latter could still point to the current
                    version, it doesn't have to be changed. Anyway, I can still use CVS
                    with aap, which is also fine.

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Christian MICHON
                    Bram, what is the unix command you use to generate your patches ? (actually with their current format, they re not well accepted by git). Thanks -- Christian
                    Message 9 of 23 , Jun 27, 2008
                      Bram,

                      what is the unix command you use to generate your patches ?
                      (actually with their current format, they're not well accepted by git).

                      Thanks

                      --
                      Christian
                      --
                      http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • James Vega
                      ... I d be surprised if it s something other than normal diff. The format is a context diff, which is what diff generates by default. ... That s because git
                      Message 10 of 23 , Jun 27, 2008
                        On Fri, Jun 27, 2008 at 07:42:43PM +0200, Christian MICHON wrote:
                        > what is the unix command you use to generate your patches ?

                        I'd be surprised if it's something other than normal diff. The format
                        is a context diff, which is what diff generates by default.

                        > (actually with their current format, they're not well accepted by git).

                        That's because git only accepts unified diffs which are generated by
                        running diff with the -u option.

                        For the "upstream" branch I maintain in my git repository for the Debian
                        package, I have a script which simply applies Bram's patches with the
                        patch command and then constructs commit messages based on the short
                        description from the README file on the ftp server and the block
                        description in the actual patch.

                        --
                        James
                        GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                      • Christian MICHON
                        ... yes, this is what I do too (for many years). It s frustrating to find out git does not swallow all types of patches. Thanks for the explanations.
                        Message 11 of 23 , Jun 27, 2008
                          On Fri, Jun 27, 2008 at 8:13 PM, James Vega <jamessan@...> wrote:
                          > For the "upstream" branch I maintain in my git repository for the Debian
                          > package, I have a script which simply applies Bram's patches with the
                          > patch command and then constructs commit messages based on the short
                          > description from the README file on the ftp server and the block
                          > description in the actual patch.
                          >
                          > --

                          yes, this is what I do too (for many years). It's frustrating to find
                          out git does not swallow all types of patches.

                          Thanks for the explanations. Apparently, we use a similar approach to
                          build a git repo. Is yours already available somewhere ?

                          --
                          Christian
                          --
                          http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • James Vega
                          ... Yes, it s available at git.debian.org[0]. update-patches[1] is the script I use. Lines 55-65 are the parts that update the upstream branch and the rest
                          Message 12 of 23 , Jun 27, 2008
                            On Fri, Jun 27, 2008 at 08:22:08PM +0200, Christian MICHON wrote:
                            >
                            > On Fri, Jun 27, 2008 at 8:13 PM, James Vega <jamessan@...> wrote:
                            > > For the "upstream" branch I maintain in my git repository for the Debian
                            > > package, I have a script which simply applies Bram's patches with the
                            > > patch command and then constructs commit messages based on the short
                            > > description from the README file on the ftp server and the block
                            > > description in the actual patch.
                            > >
                            > > --
                            >
                            > yes, this is what I do too (for many years). It's frustrating to find
                            > out git does not swallow all types of patches.
                            >
                            > Thanks for the explanations. Apparently, we use a similar approach to
                            > build a git repo. Is yours already available somewhere ?

                            Yes, it's available at git.debian.org[0]. update-patches[1] is the script I
                            use. Lines 55-65 are the parts that update the upstream branch and the rest
                            is just to ease the process of keeping the Debian branches updated.

                            [0] - http://git.debian.org/?p=pkg-vim/vim.git
                            [1] - http://git.debian.org/?p=pkg-vim/vim.git;a=blob;f=debian/update-patches;hb=HEAD
                            --
                            James
                            GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                          • Gautam Iyer
                            ... Any chance we can update the downloads section on www.vim.org to provide a link to this? (I see you have an upstream branch, so that non-debian users can
                            Message 13 of 23 , Jun 27, 2008
                              On Fri, Jun 27, 2008 at 02:50:48PM -0400, James Vega wrote:

                              >>> For the "upstream" branch I maintain in my git repository for the Debian
                              >>> package, I have a script which simply applies Bram's patches with the
                              >>> patch command and then constructs commit messages based on the short
                              >>> description from the README file on the ftp server and the block
                              >>> description in the actual patch.
                              >>>
                              >> yes, this is what I do too (for many years). It's frustrating to find
                              >> out git does not swallow all types of patches.
                              >>
                              >> Thanks for the explanations. Apparently, we use a similar approach to
                              >> build a git repo. Is yours already available somewhere ?
                              >
                              > Yes, it's available at git.debian.org[0]. update-patches[1] is the script I
                              > use. Lines 55-65 are the parts that update the upstream branch and the rest
                              > is just to ease the process of keeping the Debian branches updated.
                              >
                              > [0] - http://git.debian.org/?p=pkg-vim/vim.git
                              > [1] - http://git.debian.org/?p=pkg-vim/vim.git;a=blob;f=debian/update-patches;hb=HEAD

                              Any chance we can update the downloads section on www.vim.org to provide
                              a link to this? (I see you have an "upstream" branch, so that non-debian
                              users can get the vanilla sources if they so desire.)

                              GI

                              --
                              American beer is like making love in a canoe. It's #%$&*! close to
                              water.
                            • Bram Moolenaar
                              ... diff -acN Although version.c is using less context. -- hundred-and-one symptoms of being an internet addict: 99. The hum of a cooling fan and the click
                              Message 14 of 23 , Jun 27, 2008
                                Christian Michon wrote:

                                > what is the unix command you use to generate your patches ?
                                > (actually with their current format, they're not well accepted by git).

                                "diff -acN"

                                Although version.c is using less context.

                                --
                                hundred-and-one symptoms of being an internet addict:
                                99. The hum of a cooling fan and the click of keys is comforting to you.

                                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                                \\\ download, build and distribute -- http://www.A-A-P.org ///
                                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_dev" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • James Vega
                                ... I only update the upstream branch when I get around to working on the package, though, instead of as Bram releases patches. It s not uncommon for me to be
                                Message 15 of 23 , Jun 27, 2008
                                  On Fri, Jun 27, 2008 at 11:57:33AM -0700, Gautam Iyer wrote:
                                  > On Fri, Jun 27, 2008 at 02:50:48PM -0400, James Vega wrote:
                                  >
                                  > >>> For the "upstream" branch I maintain in my git repository for the Debian
                                  > >>> package, I have a script which simply applies Bram's patches with the
                                  > >>> patch command and then constructs commit messages based on the short
                                  > >>> description from the README file on the ftp server and the block
                                  > >>> description in the actual patch.
                                  > >>>
                                  > >> yes, this is what I do too (for many years). It's frustrating to find
                                  > >> out git does not swallow all types of patches.
                                  > >>
                                  > >> Thanks for the explanations. Apparently, we use a similar approach to
                                  > >> build a git repo. Is yours already available somewhere ?
                                  > >
                                  > > Yes, it's available at git.debian.org[0]. update-patches[1] is the script I
                                  > > use. Lines 55-65 are the parts that update the upstream branch and the rest
                                  > > is just to ease the process of keeping the Debian branches updated.
                                  > >
                                  > > [0] - http://git.debian.org/?p=pkg-vim/vim.git
                                  > > [1] - http://git.debian.org/?p=pkg-vim/vim.git;a=blob;f=debian/update-patches;hb=HEAD
                                  >
                                  > Any chance we can update the downloads section on www.vim.org to provide
                                  > a link to this? (I see you have an "upstream" branch, so that non-debian
                                  > users can get the vanilla sources if they so desire.)

                                  I only update the upstream branch when I get around to working on the
                                  package, though, instead of as Bram releases patches. It's not uncommon
                                  for me to be 10-20 patches behind.

                                  --
                                  James
                                  GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                                • Hisashi T Fujinaka
                                  ... Is there any chance the beta versioning could be made so 7.2.000 will be greater on comparison? 7.2a.x is usually newer than 7.2.x. 7.2a.x is usually
                                  Message 16 of 23 , Jun 28, 2008
                                    On Thu, 26 Jun 2008, Hisashi T Fujinaka wrote:

                                    > On Thu, 26 Jun 2008, Tony Mechelynck wrote:
                                    >>
                                    >> On 26/06/08 22:18, Bram Moolenaar wrote:
                                    >>>
                                    >>> Patch 7.2a.001
                                    >>> Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
                                    >>> X11/Intrinsic.h does not (in Xt-dev package). This breaks the
                                    >>> build. Also, on Solaris 9 sys/ptem.h isn't found.
                                    >>> Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
                                    >>> Check for sys/ptem.h while including sys/stream.h. (Vladimir
                                    >>> Marek)
                                    >>> Files: src/auto/configure, src/configure.in
                                    >> [...]
                                    >>
                                    >> And for those who, like me, are slow to readjust: the 7.2a patches
                                    >> directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of
                                    >> course it's accessible also by ftp). This means it's *not* a sibling of
                                    >> the 7.1 patches directory (it's in the "unstable" tree).
                                    >
                                    > Oh, boy. Is this 7.2a -> 7.2.0 transition going to break version sorting
                                    > again?

                                    Is there any chance the beta versioning could be made so 7.2.000 will be
                                    "greater" on comparison? 7.2a.x is usually "newer" than 7.2.x. 7.2a.x is
                                    usually "newer" than 7.2.x. For example, you could make the version
                                    7.1.999.x or something.

                                    Thanks.

                                    --
                                    Hisashi T Fujinaka - htodd@...
                                    BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_dev" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  • James Vega
                                    ... It s common practice to make pre-release versions named similar to the to-be-released version (usually use pre1 or rc1 in place of a). Given that, I think
                                    Message 17 of 23 , Jun 28, 2008
                                      On Sat, Jun 28, 2008 at 03:03:09PM -0700, Hisashi T Fujinaka wrote:
                                      >
                                      > On Thu, 26 Jun 2008, Hisashi T Fujinaka wrote:
                                      >
                                      > > On Thu, 26 Jun 2008, Tony Mechelynck wrote:
                                      > >>
                                      > >> On 26/06/08 22:18, Bram Moolenaar wrote:
                                      > >>>
                                      > >>> Patch 7.2a.001
                                      > >>> Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
                                      > >>> X11/Intrinsic.h does not (in Xt-dev package). This breaks the
                                      > >>> build. Also, on Solaris 9 sys/ptem.h isn't found.
                                      > >>> Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
                                      > >>> Check for sys/ptem.h while including sys/stream.h. (Vladimir
                                      > >>> Marek)
                                      > >>> Files: src/auto/configure, src/configure.in
                                      > >> [...]
                                      > >>
                                      > >> And for those who, like me, are slow to readjust: the 7.2a patches
                                      > >> directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of
                                      > >> course it's accessible also by ftp). This means it's *not* a sibling of
                                      > >> the 7.1 patches directory (it's in the "unstable" tree).
                                      > >
                                      > > Oh, boy. Is this 7.2a -> 7.2.0 transition going to break version sorting
                                      > > again?
                                      >
                                      > Is there any chance the beta versioning could be made so 7.2.000 will be
                                      > "greater" on comparison? 7.2a.x is usually "newer" than 7.2.x. 7.2a.x is
                                      > usually "newer" than 7.2.x. For example, you could make the version
                                      > 7.1.999.x or something.

                                      It's common practice to make pre-release versions named similar to the
                                      to-be-released version (usually use pre1 or rc1 in place of a). Given
                                      that, I think the bump from 7.2a to 7.2 should be able to be handled
                                      just as well as the other naming conventions.

                                      There's certainly no conflict with regard to the ftp directories since
                                      they're in completely separate trees. Therefore the versioning is
                                      primarily a problem with packaging and package management systems should
                                      have a way to handle specifying a pre-release version as lower than the
                                      released version.

                                      For example, in Debian the version number is 7.2.0~a, since I embed the
                                      patch-level in the version, which will always be less than 7.2.0.
                                      Although, now that I test it, 7.2a.0 compares less than 7.2.0 for
                                      Debian's packaging tools.

                                      --
                                      James
                                      GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                                    • Tony Mechelynck
                                      ... No, in Bram s system anything with two letters (alpha) is before anything with one letter (beta) which is before anything with no letters (release). So in
                                      Message 18 of 23 , Jun 28, 2008
                                        On 29/06/08 00:03, Hisashi T Fujinaka wrote:
                                        > On Thu, 26 Jun 2008, Hisashi T Fujinaka wrote:
                                        >
                                        >> On Thu, 26 Jun 2008, Tony Mechelynck wrote:
                                        >>> On 26/06/08 22:18, Bram Moolenaar wrote:
                                        >>>> Patch 7.2a.001
                                        >>>> Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
                                        >>>> X11/Intrinsic.h does not (in Xt-dev package). This breaks the
                                        >>>> build. Also, on Solaris 9 sys/ptem.h isn't found.
                                        >>>> Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
                                        >>>> Check for sys/ptem.h while including sys/stream.h. (Vladimir
                                        >>>> Marek)
                                        >>>> Files: src/auto/configure, src/configure.in
                                        >>> [...]
                                        >>>
                                        >>> And for those who, like me, are slow to readjust: the 7.2a patches
                                        >>> directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of
                                        >>> course it's accessible also by ftp). This means it's *not* a sibling of
                                        >>> the 7.1 patches directory (it's in the "unstable" tree).
                                        >> Oh, boy. Is this 7.2a -> 7.2.0 transition going to break version sorting
                                        >> again?
                                        >
                                        > Is there any chance the beta versioning could be made so 7.2.000 will be
                                        > "greater" on comparison? 7.2a.x is usually "newer" than 7.2.x. 7.2a.x is
                                        > usually "newer" than 7.2.x. For example, you could make the version
                                        > 7.1.999.x or something.
                                        >
                                        > Thanks.
                                        >

                                        No, in Bram's system anything with two letters (alpha) is before
                                        anything with one letter (beta) which is before anything with no letters
                                        (release). So in this case 7.2a.008 comes before 7.2.0. Similarly with
                                        Mozilla, (Firefox) 2.0.0.16pre is before 2.0.0.16 and (SeaMonkey)
                                        2.0a1pre is before 2.0a1 which is before 2.0, in a manner which is just
                                        as contrary to strict lexicographical ordering.

                                        Best regards,
                                        Tony.
                                        --
                                        Corruption is not the #1 priority of the Police Commissioner. His job
                                        is to enforce the law and fight crime.
                                        -- P.B.A. President E. J. Kiernan

                                        --~--~---------~--~----~------------~-------~--~----~
                                        You received this message from the "vim_dev" maillist.
                                        For more information, visit http://www.vim.org/maillist.php
                                        -~----------~----~----~----~------~----~------~--~---
                                      • Hisashi T Fujinaka
                                        ... That s why I m asking Bram to change his ways. Just because Mozilla does it wrong doesn t mean Bram has to. -- Hisashi T Fujinaka - htodd@twofifty.com
                                        Message 19 of 23 , Jun 28, 2008
                                          On Sun, 29 Jun 2008, Tony Mechelynck wrote:

                                          >
                                          > On 29/06/08 00:03, Hisashi T Fujinaka wrote:
                                          >> On Thu, 26 Jun 2008, Hisashi T Fujinaka wrote:
                                          >>
                                          >>> On Thu, 26 Jun 2008, Tony Mechelynck wrote:
                                          >>>> On 26/06/08 22:18, Bram Moolenaar wrote:
                                          >>>>> Patch 7.2a.001
                                          >>>>> Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
                                          >>>>> X11/Intrinsic.h does not (in Xt-dev package). This breaks the
                                          >>>>> build. Also, on Solaris 9 sys/ptem.h isn't found.
                                          >>>>> Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
                                          >>>>> Check for sys/ptem.h while including sys/stream.h. (Vladimir
                                          >>>>> Marek)
                                          >>>>> Files: src/auto/configure, src/configure.in
                                          >>>> [...]
                                          >>>>
                                          >>>> And for those who, like me, are slow to readjust: the 7.2a patches
                                          >>>> directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of
                                          >>>> course it's accessible also by ftp). This means it's *not* a sibling of
                                          >>>> the 7.1 patches directory (it's in the "unstable" tree).
                                          >>> Oh, boy. Is this 7.2a -> 7.2.0 transition going to break version sorting
                                          >>> again?
                                          >>
                                          >> Is there any chance the beta versioning could be made so 7.2.000 will be
                                          >> "greater" on comparison? 7.2a.x is usually "newer" than 7.2.x. 7.2a.x is
                                          >> usually "newer" than 7.2.x. For example, you could make the version
                                          >> 7.1.999.x or something.
                                          >>
                                          >> Thanks.
                                          >>
                                          >
                                          > No, in Bram's system anything with two letters (alpha) is before
                                          > anything with one letter (beta) which is before anything with no letters
                                          > (release). So in this case 7.2a.008 comes before 7.2.0. Similarly with
                                          > Mozilla, (Firefox) 2.0.0.16pre is before 2.0.0.16 and (SeaMonkey)
                                          > 2.0a1pre is before 2.0a1 which is before 2.0, in a manner which is just
                                          > as contrary to strict lexicographical ordering.

                                          That's why I'm asking Bram to change his ways. Just because Mozilla does
                                          it "wrong" doesn't mean Bram has to.

                                          --
                                          Hisashi T Fujinaka - htodd@...
                                          BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

                                          --~--~---------~--~----~------------~-------~--~----~
                                          You received this message from the "vim_dev" maillist.
                                          For more information, visit http://www.vim.org/maillist.php
                                          -~----------~----~----~----~------~----~------~--~---
                                        • Tony Mechelynck
                                          ... It isn t wrong per se. It s just a different, maybe less mechanical, criterion. Even ls is wrong from my POV when it puts Zimbabwe mechanically
                                          Message 20 of 23 , Jun 28, 2008
                                            On 29/06/08 02:22, Hisashi T Fujinaka wrote:
                                            > On Sun, 29 Jun 2008, Tony Mechelynck wrote:
                                            >
                                            >> On 29/06/08 00:03, Hisashi T Fujinaka wrote:
                                            >>> On Thu, 26 Jun 2008, Hisashi T Fujinaka wrote:
                                            >>>
                                            >>>> On Thu, 26 Jun 2008, Tony Mechelynck wrote:
                                            >>>>> On 26/06/08 22:18, Bram Moolenaar wrote:
                                            >>>>>> Patch 7.2a.001
                                            >>>>>> Problem: On some systems X11/Xlib.h exists (from X11-dev package) but
                                            >>>>>> X11/Intrinsic.h does not (in Xt-dev package). This breaks the
                                            >>>>>> build. Also, on Solaris 9 sys/ptem.h isn't found.
                                            >>>>>> Solution: Have configure only accept X11 when X11/Intrinsic.h exists.
                                            >>>>>> Check for sys/ptem.h while including sys/stream.h. (Vladimir
                                            >>>>>> Marek)
                                            >>>>>> Files: src/auto/configure, src/configure.in
                                            >>>>> [...]
                                            >>>>>
                                            >>>>> And for those who, like me, are slow to readjust: the 7.2a patches
                                            >>>>> directory is http://ftp.vim.org/pub/vim/unstable/patches/7.2a/ (of
                                            >>>>> course it's accessible also by ftp). This means it's *not* a sibling of
                                            >>>>> the 7.1 patches directory (it's in the "unstable" tree).
                                            >>>> Oh, boy. Is this 7.2a -> 7.2.0 transition going to break version sorting
                                            >>>> again?
                                            >>> Is there any chance the beta versioning could be made so 7.2.000 will be
                                            >>> "greater" on comparison? 7.2a.x is usually "newer" than 7.2.x. 7.2a.x is
                                            >>> usually "newer" than 7.2.x. For example, you could make the version
                                            >>> 7.1.999.x or something.
                                            >>>
                                            >>> Thanks.
                                            >>>
                                            >> No, in Bram's system anything with two letters (alpha) is before
                                            >> anything with one letter (beta) which is before anything with no letters
                                            >> (release). So in this case 7.2a.008 comes before 7.2.0. Similarly with
                                            >> Mozilla, (Firefox) 2.0.0.16pre is before 2.0.0.16 and (SeaMonkey)
                                            >> 2.0a1pre is before 2.0a1 which is before 2.0, in a manner which is just
                                            >> as contrary to strict lexicographical ordering.
                                            >
                                            > That's why I'm asking Bram to change his ways. Just because Mozilla does
                                            > it "wrong" doesn't mean Bram has to.
                                            >

                                            It isn't "wrong" per se. It's just a different, maybe less mechanical,
                                            criterion. Even "ls" is "wrong" from my POV when it puts Zimbabwe
                                            mechanically before al-Arabiya, because Z (0x5A) comes "before" a (0x61)
                                            in its strictly numerical ordering.

                                            Best regards,
                                            Tony.
                                            --
                                            hundred-and-one symptoms of being an internet addict:
                                            30. Even though you died last week, you've managed to retain OPS on your
                                            favorite IRC channel.

                                            --~--~---------~--~----~------------~-------~--~----~
                                            You received this message from the "vim_dev" maillist.
                                            For more information, visit http://www.vim.org/maillist.php
                                            -~----------~----~----~----~------~----~------~--~---
                                          • Christian MICHON
                                            ... I had a adsl modem failure (found a replacement). I finally managed some time to have a look at your repo. One feedback: we should try to keep the patch
                                            Message 21 of 23 , Jun 30, 2008
                                              On Fri, Jun 27, 2008 at 8:50 PM, James Vega <jamessan@...> wrote:
                                              >> Thanks for the explanations. Apparently, we use a similar approach to
                                              >> build a git repo. Is yours already available somewhere ?
                                              >
                                              > Yes, it's available at git.debian.org[0]. update-patches[1] is the script I
                                              > use. Lines 55-65 are the parts that update the upstream branch and the rest
                                              > is just to ease the process of keeping the Debian branches updated.
                                              >
                                              > [0] - http://git.debian.org/?p=pkg-vim/vim.git

                                              I had a adsl modem failure (found a replacement). I finally managed
                                              some time to have a look at your repo.

                                              One feedback: we should try to keep the patch numbers from Bram in the
                                              shortlog, shouldn't we ?

                                              I also see you've a lot of branches and tags. In my current repo's
                                              experiments, I stick only to released versions (I prefer to leave the
                                              alpha versions off the repo, too many of them) and use a branch for
                                              each version. Then I use a tag to mark/keep the start of it and a tag
                                              for versions which are not maintained anymore.

                                              My commit's dates are based on the ftp server: I guess a cleaner
                                              approach should be to scan the mailing list archives or copy the dates
                                              from cvs.

                                              I'm consolidating the repo then I'll find a web server to host it.
                                              Thanks for the git address.

                                              --
                                              Christian
                                              --
                                              http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

                                              --~--~---------~--~----~------------~-------~--~----~
                                              You received this message from the "vim_dev" maillist.
                                              For more information, visit http://www.vim.org/maillist.php
                                              -~----------~----~----~----~------~----~------~--~---
                                            • James Vega
                                              ... *shrug* I went back and forth on that and ended up leaving it as is since that s the way I started. ... The workflow for the repo is geared towards what
                                              Message 22 of 23 , Jun 30, 2008
                                                On Mon, Jun 30, 2008 at 10:37:41PM +0200, Christian MICHON wrote:
                                                >
                                                > On Fri, Jun 27, 2008 at 8:50 PM, James Vega <jamessan@...> wrote:
                                                > >> Thanks for the explanations. Apparently, we use a similar approach to
                                                > >> build a git repo. Is yours already available somewhere ?
                                                > >
                                                > > Yes, it's available at git.debian.org[0]. update-patches[1] is the script I
                                                > > use. Lines 55-65 are the parts that update the upstream branch and the rest
                                                > > is just to ease the process of keeping the Debian branches updated.
                                                > >
                                                > > [0] - http://git.debian.org/?p=pkg-vim/vim.git
                                                >
                                                > I had a adsl modem failure (found a replacement). I finally managed
                                                > some time to have a look at your repo.
                                                >
                                                > One feedback: we should try to keep the patch numbers from Bram in the
                                                > shortlog, shouldn't we ?

                                                *shrug* I went back and forth on that and ended up leaving it as is
                                                since that's the way I started.

                                                > I also see you've a lot of branches and tags. In my current repo's
                                                > experiments, I stick only to released versions (I prefer to leave the
                                                > alpha versions off the repo, too many of them) and use a branch for
                                                > each version. Then I use a tag to mark/keep the start of it and a tag
                                                > for versions which are not maintained anymore.

                                                The workflow for the repo is geared towards what works for maintaining
                                                the Debian vim package. For that purpose, tagging the upstream+patch
                                                level that was used to release a Debian package is useful.

                                                > My commit's dates are based on the ftp server: I guess a cleaner
                                                > approach should be to scan the mailing list archives or copy the dates
                                                > from cvs.

                                                I had thought about making git record the date as when the patch was
                                                released but since that information isn't in the patch itself, gave up
                                                on it.

                                                > I'm consolidating the repo then I'll find a web server to host it.
                                                > Thanks for the git address.

                                                Cool. I'm sure people will find a repo meant purely for replication
                                                instead of my specific needs more useful.

                                                --
                                                James
                                                GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>
                                              • Christian MICHON
                                                ... I managed to find a neat way to do this. ... good hint. actually, it s inside each patch itself (just need to look for the date of version.c updates). ...
                                                Message 23 of 23 , Jul 1 3:58 AM
                                                  On Mon, Jun 30, 2008 at 11:39 PM, James Vega <jamessan@...> wrote:
                                                  >> One feedback: we should try to keep the patch numbers from Bram in the
                                                  >> shortlog, shouldn't we ?
                                                  >
                                                  > *shrug* I went back and forth on that and ended up leaving it as is
                                                  > since that's the way I started.

                                                  I managed to find a neat way to do this.

                                                  >> My commit's dates are based on the ftp server: I guess a cleaner
                                                  >> approach should be to scan the mailing list archives or copy the dates
                                                  >> from cvs.
                                                  >
                                                  > I had thought about making git record the date as when the patch was
                                                  > released but since that information isn't in the patch itself, gave up
                                                  > on it.

                                                  good hint. actually, it's inside each patch itself (just need to look
                                                  for the date of version.c updates).

                                                  >
                                                  >> I'm consolidating the repo then I'll find a web server to host it.
                                                  >> Thanks for the git address.
                                                  >
                                                  > Cool. I'm sure people will find a repo meant purely for replication
                                                  > instead of my specific needs more useful.

                                                  well, I know the pristine tar habits you have... I want to focus on
                                                  vim+extra+all patches only.
                                                  It's progressing well. Just cpu time mostly...

                                                  --
                                                  Christian
                                                  --
                                                  http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

                                                  --~--~---------~--~----~------------~-------~--~----~
                                                  You received this message from the "vim_dev" maillist.
                                                  For more information, visit http://www.vim.org/maillist.php
                                                  -~----------~----~----~----~------~----~------~--~---
                                                Your message has been successfully submitted and would be delivered to recipients shortly.