From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53474 invoked by alias); 16 May 2015 15:23:30 -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 52445 invoked by uid 89); 16 May 2015 15:23:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f46.google.com Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com) (209.85.218.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 16 May 2015 15:23:25 +0000 Received: by oift201 with SMTP id t201so102527376oif.3 for ; Sat, 16 May 2015 08:23:23 -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:date :message-id:subject:from:to:cc:content-type; bh=qSY2bHck1jl3SsN++sTXFJXQc81l+mGHDDL0nVgYGjs=; b=dx9T/dzqsBDUgkIqk1nbHGGUKIX4J/HrdTFqJQUN1USAICj/MyUfBbHNNT4bKHwfRl R6fhyaapaunM46Xsx1y1OEv9h7LpilnPKNucxblU9of0C5XzPf1lREffbCt8zO2PbzDg 6whQJNWVrZ/UQnX4IEZCLMpFEslT7Yr9zqZm9R4pY6WzP3Nzh55o8NYaikJOwNM+5prr +qGOyZF5DfK0tcU9Z0/SWCCV9kAkR94kX+mo1dW3OIaXk/xG6Vbp2aN4nml58UefneNe 3dJtqEQXHce1eqRtKYdx1GALsWqLaSYirKC2uP7Q5fgYfX0D8XndzkQMBEiHyROyF6nx Xt/A== X-Gm-Message-State: ALoCoQm2biRJOW6dynKssc+pOv1rjdjtcjvHUVQp3uRw96Sd8Mu+93Z9XxtQay9WqwtBGZ4gODHv MIME-Version: 1.0 X-Received: by 10.202.198.149 with SMTP id w143mr12408953oif.72.1431789803291; Sat, 16 May 2015 08:23:23 -0700 (PDT) Received: by 10.182.89.99 with HTTP; Sat, 16 May 2015 08:23:23 -0700 (PDT) In-Reply-To: References: <1431562331-20448-1-git-send-email-patrick@parcs.ath.cx> Date: Sat, 16 May 2015 15:23:00 -0000 Message-ID: Subject: Re: [PATCH] [RFC] Sync readline to version 6.3 patchlevel 8 From: Doug Evans To: Patrick Palka Cc: gdb-patches , Jan Kratochvil Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00439.txt.bz2 On Sat, May 16, 2015 at 7:58 AM, Patrick Palka wrote: > 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. Another thought is that IWBN if the reapplication of local patches was a separate commit. Even better if each local patch was its own commit, but depending on the quantity that may be too onerous (I don't think it is, I do this for every major gdb release in our own tree, but I'm not the one doing the work here:-)). I realize this is more work, but IWBN to "see" a local patch with minimal effort. Thoughts?