From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49786 invoked by alias); 16 May 2015 14:59:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 49763 invoked by uid 89); 16 May 2015 14:59:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-oi0-f49.google.com Received: from mail-oi0-f49.google.com (HELO mail-oi0-f49.google.com) (209.85.218.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 16 May 2015 14:59:06 +0000 Received: by oiko83 with SMTP id o83so102370464oik.1 for ; Sat, 16 May 2015 07:59:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uX6+pLY6EtIta6ipz/2Pv2rMDSbhgLIijNMZivke340=; b=bFtLddci+BNljLfOl0jigyxWvO6d22qU3+IjjgS8rf1GhHZNw5+NF/3EsQQ4oebkZI FFaqKPwooInDddbuErEbAHTixyi7kVQrp1sowC6n00gK0QHyX/V6NdGMH2BxGn94U/AH xPn1qElmbtocXr9Rb1T5btwxG6TfpaM+fSsnUitKHc//UTlM0GtQ6+fWELsvAg9G48OR v4TO2W86KCvWj/Sn/ArToECDfGE4R0Q8a+kRYamrVp7vZXWzSsCJGl5uX9EJ1x3+fgmS Pb2siZI26Jkrs8W6kjvtK2iz7MemXGR5YRsL7ie+oJ6IB41iULvzWjq/pmy4mecL7w66 Y01g== X-Gm-Message-State: ALoCoQnCa1KqNgzDN3oMlmI1EEBwGuV5ACX5z3IjtHP0ELaS2L7Vn231qRiYSP+Yio3BJ4V2H2UY X-Received: by 10.202.54.3 with SMTP id d3mr12067662oia.103.1431788344563; Sat, 16 May 2015 07:59:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.243.232 with HTTP; Sat, 16 May 2015 07:58:43 -0700 (PDT) In-Reply-To: References: <1431562331-20448-1-git-send-email-patrick@parcs.ath.cx> From: Patrick Palka Date: Sat, 16 May 2015 14:59:00 -0000 Message-ID: Subject: Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8 To: Doug Evans Cc: gdb-patches , Jan Kratochvil Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-05/txt/msg00438.txt.bz2 On Fri, May 15, 2015 at 9:00 PM, Doug Evans wrote: > On Wed, May 13, 2015 at 5:12 PM, Patrick Palka wrote: >> This patch syncs our upstream copy of readline to version 6.3 >> patchlevel 8. >> >> I basically copied what was done when Jan updated to readline 6.2 in >> 2011: http://sourceware.org/ml/gdb-patches/2011-05/msg00003.html >> >> Specifically, I: >> >> 1. Extracted the readline 6.3 tarball on top of readline/ >> 2. Applied patches 1-8 from ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/ >> 3. Omitted all the files in doc/ that were intentionally omitted before. >> 4. Regenerated readline/configure and readline/examples/rlfe/configure >> using autoconf 2.64. No other configure files needed regenerating. >> 5. Reapplied the only local patch since the update to readline 6.2 that >> has not already been applied to readline 6.3, 05942d8a1 ("Fix >> executable indicator in file name completeion on Windows."). This >> particular patch has been applied upstream but readline 6.3 does not >> have it. Whether or not a local patch has already been applied to >> readline 6.3 was determined via manual inspection. (Wasn't too bad >> really.) >> >> The new files to make it into the tree are: >> >> colors.{c,h} >> configure.ac >> parse-colors.{c,h} >> examples/hist_erasedups.c >> examples/hist_purgecmd.c >> >> Deleted files: >> >> configure.in >> >> I've been using this patch locally for a few months now and I've >> experienced only a single regression which has already been preemptively >> fixed by 8900d71e3 ("Explicitly call rl_resize_terminal() in TUI's >> SIGWINCH handler"). Other than that, no issues in either the CLI or the >> TUI, or changes in the testsuite. Though I have only been able to test >> this patch on Linux. >> >> Have I missed anything? What else should be done in order to sync our >> copy of readline? Unlike the last sync from 5.1 to 6.2, this sync to >> 6.3 is quite minor and hopefully painless. >> >> Because the commit is so big and so mechanical I elected to create a >> branch users/ppalka/readline-6.3-update where you can view/test the >> change. >> >> readline/ChangeLog.gdb: >> >> Import readline 6.3 and upstream patches 1-8. >> * configure: Regenerate. >> * examples/rlfe/configure: Regenerate. >> * complete.c: Reapply previous change. > > Hi. > > How does one easily audit whether all local patches are still present? > Looking at ChangeLog.gdb I'm left wondering. > > I'm not saying you've missed anything. > Rather, IWBN to have, after all your efforts, > a *simple* record of what's still local. > > One thought was to just nuke all of the old entries > in ChangeLog.gdb. If you say there's only one local change > present then it should be a really small file. > [IOW, when we import a new readline from upstream, > reset ChangeLog.gdb.] > > Another thought, for those that have an aversion to > emptying out ChangeLog.gdb and starting over, > is to just add a line that says something like > "everything below this line is just > for the archive, ignore it otherwise", and copy up entries > for local patches that are still local. > > If the number of local patches is small (as it should be) > I like starting over with each new import. > But the high order bit for me is to be able to easily > audit/track/find local patches. Another option is that the commit responsible for syncing readline should mention which local commits have been reapplied in the commit message and also mention it in the ChangeLog.gdb entry. So the local commits at any point in time would be all the commits that occurred after the latest readline import plus the earlier commits (if any) referenced in that readline import. I like that idea and the idea of trimming the ChangeLog.gdb file at each import too.