Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 78381 invoked from network); 11 Oct 2007 10:36:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Oct 2007 10:36:09 -0000 Received: (qmail 64429 invoked by uid 500); 11 Oct 2007 10:35:56 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 64373 invoked by uid 500); 11 Oct 2007 10:35:55 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 64362 invoked by uid 99); 11 Oct 2007 10:35:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2007 03:35:55 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lucian.grijincu@gmail.com designates 66.249.82.239 as permitted sender) Received: from [66.249.82.239] (HELO wx-out-0506.google.com) (66.249.82.239) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2007 10:35:59 +0000 Received: by wx-out-0506.google.com with SMTP id h26so420010wxd for ; Thu, 11 Oct 2007 03:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ELeXQB8pL2tFqZpAAUGGfuyBa8kUOC92w/YERKZ/VA8=; b=mdM/T2H/BUu568PjbOO3YJ0hIoSDgDJG4qp+gXpEPt3zscI2zRgMEJeO8k6hu47q3RvM7hGzwx1pjEuC0YmeR6lkm8fEmIOW0nBWdIFBp4ZsI7jjFruYQWaLr9ZNR9Y9Mvi5Mi8KnQJLJiSTCyRo2QvLGzcqgNPT+8p98XiPsiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z0iRBPsL/O2tKgETVW2HwJ/Sla8vW4RjzCsjVP8mw+ujF7kPkgDpooasK4UuWHSjOZDQQRMMaKxvdt+cm4htAJ1eCl4bRVqoNi6uLNwLJTvlGAgvOZ2mU8uyWj5qFyCiV+LJ2Qc3LSTM7kDwxTOOPles7H/+8QcVe6gz11Oo0qA= Received: by 10.90.118.12 with SMTP id q12mr2741719agc.1192098937891; Thu, 11 Oct 2007 03:35:37 -0700 (PDT) Received: by 10.90.63.7 with HTTP; Thu, 11 Oct 2007 03:35:37 -0700 (PDT) Message-ID: Date: Thu, 11 Oct 2007 13:35:37 +0300 From: "Lucian Adrian Grijincu" To: "William A. Rowe, Jr." Subject: Re: Tagging 1.2.* Sat night or Sun a.m. Cc: "APR Developer List" In-Reply-To: <470DD429.90908@rowe-clan.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <470DD429.90908@rowe-clan.net> X-Virus-Checked: Checked by ClamAV on apache.org On 10/11/07, William A. Rowe, Jr. wrote: > Depending on my weekend. > > I found the bug, I'll commit the fix friday after I vet it a bit more. > Win32 apr_file_dup2's new flags bits for stdio channels were the buggers, > needed to mask those off in appropriate ways, but I'm not done validating > the fix. > > I've committed to trunk the build changes that let us almost seamlessly > transition from .dsp to .vcproj, for x86 and x64. [Actually, they are > seamless here because we don't try stuffing /D "SYM=With a space" at > the resource compiler. httpd is not so lucky]. > > I don't plan to backport the /D WINNT change for x86, or the Win9x > targets. Save that for 1.3. But there's no sense in run time tests > of 9x for x64 ;-) Otherwise, it goes over to 1.2 as-in trunk. > > So the dsp improvements roll on to apr-iconv and apr-util for releases > there too. We should have a really ready-to-rock x64 build schema, all > it still needs is a top level Makefile.win to make things easy, which > I'm about to crib from httpd (including ssl detection logic for apr 1.3, > but nothing that rich for the other trees.) > > So what of y'all - anything else to slide in before the weekend? If > you are still at it Saturday, be sure to holler so I don't accidentally > roll right over anyone's toes. > Do my patches against configure.in, apr.hnw and apr.hw fixing the apr_ino_t ( http://issues.apache.org/bugzilla/show_bug.cgi?id=43417 ) issue have a chance of getting accepted (aka should I try to test them on other configurations to see whether they break something on some systems)? -- Lucian