X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=oe5pZrJZz9Z+16DO
	UWTmFpfy1YMVG7qZKFvgfz70yLUcdosiQ2Ny/MCj6lIKD+tc2SxcGZH31/H9bWxl
	i42n5xbuYIA8lfW1ScfcRdjCdhx32fKlB3AGlBxFTLZ1xmV+mx+Fw98thRV5nfBN
	7cem9O9ZU0m5XSlgkkBsAo4jcKA=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=KVbZ7CIeP01XZgZ7Gt7QU8
	rNqko=; b=lCFx3izGLAa8qoJBlbnhxtp02/NFAo5ncOh2HNcp2y7g7RUJ/nAaNX
	8+qj9cfac8eRNSL2Mzn//CrKqaAzVyTIkVtpdEg8xk1/mY3EOgRnHWsV9yKaXgkc
	DHpxh00P/ijiD7zEdonqCaG9JxGKbYifoTSm6F7pqpHvfi3/3I90s=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=0.2 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=privacy, retrieve, Gratz, gratz
X-HELO:	mout.kundenserver.de
Subject:	Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
To:	cygwin AT cygwin DOT com
References:	<announce DOT 6264b24c-18bd-814e-16e9-1852f3433e98 AT towo DOT net> <87pnqq536x DOT fsf AT Rainer DOT invalid> <8bf901a3-5e61-fa65-651f-5bdb9dddba4b AT towo DOT net> <20190324181931 DOT GE3471 AT calimero DOT vinschen DOT de> <8b43cced-6c22-e9de-046d-0895d0bc4f81 AT towo DOT net> <87sgvarfgt DOT fsf AT Rainer DOT invalid> <fe281b79-3ba1-0352-b73e-ab858d068d30 AT towo DOT net> <fa67f31ca3e068ad0e1a8996986ddf9c9c72f3fc DOT camel AT cygwin DOT com>
From:	Thomas Wolff <towo AT towo DOT net>
Message-ID:	<f8600ba7-08cd-3551-6f57-1517ae84f4f8@towo.net>
Date:	Thu, 28 Mar 2019 09:43:36 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version:	1.0
In-Reply-To:	<fa67f31ca3e068ad0e1a8996986ddf9c9c72f3fc.camel@cygwin.com>
X-IsSubscribed:	yes

Achim Gratz wrote:
>
>> Trying cygport package, a bunch of problems arise:
>>
>> I removed -s as suggested by Achim, added -g as advised by Corinna,
>> but cygport still says:
>> *** Info: No debug files, skipping debuginfo subpackage
> Well, do not reset CFLAGS in your Makefile and cygport helpfully
> provides all the scaffolding you need.  You might have noticed I
> replaced the ":=" in your Makefile for exactly that reason.
I wondered why and forgot... Works now, thank you.
> A build system is supposed to be able to pre-configure CFLAGS without your
> Makefile nixing all of that effort.
As also indicated by Jeffrey Walton. However, I'll do only minimal 
revision of the Makefile, as required.

>
>> Achim also suggested some changes in the cygport file:
>> #SRC_URI="https://github.com/${NAME}/release/${NAME}-${VERSION}-src.tar.bz2"
>> SRC_URI="https://github.com/${NAME}/${NAME}/archive/${VERSION}.tar.gz"
>> → While it’s proper to retrieve the archive (if needed at all; why
>> does cygport refer to this if the package is locally available?)
> It's generally considered bad form to provide a cygport file that
> doesn't work standalone and the SRC_URI you provided only got me a 404.
Referring to the "release" repository was only a fallback rescue 
setting, because due to github's strange URL scheme, the working 
download URL would confuse cygport.
>
>> from the release area, and not from the separate “release” repository,
>> unfortunately it’s github URL does not include the “mintty-” prefix
>> (it’s just 2.9.9.tar.gz) which causes the source package generated by
>> cygport to be empty:
> You can rename the package after download by adding a "#new_name" to the
> SRC_URI if you must.  I usually do that for patches that have
> non-distinct names as I keep those files in a separate cache directory.
> Otherwise if the SRC_URI has downloaded a file, that will get used for
> the source package.
So cygport, referring to the download URL even if it does not download 
because the package is available locally, still enforces usage of the 
same archive format...

>
>> VERSION="2.9.9"
>> → This would need the cygport to be generated per version, but
>> apparently it’s not required.
> I generally keep cygport files under version control and I don't want to
> rename the file for each release.  YMMV.
Sure, that's why the VERSION should better not be mentioned in it, right?

>
>> As an alternative, I would accept a description how to generate a
>> debug package "manually", with tar.
> Just watch cygport --debug do it and then do the same.  But whatever you
> do, please provide a cygport file that actually works when somebody
> tries to run it.
OK, here we are at the core of the issue. I've done that and was 
surprised that the debug package basically contains copies of all source 
files. Would be easy to reproduce. If there weren't that mintty.exe.dbg 
thing. What's that and how is it generated? I couldn't derive that from 
the cygport --debug output.


Yaakov Selkowitz wrote:
>
>> Achim also suggested some changes in the cygport file:
>> #SRC_URI="https://github.com/${NAME}/release/${NAME}-${VERSION}-src.tar.bz2"
>> SRC_URI="https://github.com/${NAME}/${NAME}/archive/${VERSION}.tar.gz"
>> → While it’s proper to retrieve the archive (if needed at all; why does
>> cygport refer to this if the package is locally available?) from the
>> release area, and not from the separate “release” repository,
>> unfortunately it’s github URL does not include the “mintty-” prefix
>> (it’s just 2.9.9.tar.gz) which causes the source package generated by
>> cygport to be empty:
>>   >>> Creating source package
>> /bin/cp: cannot stat '/cygdrive/d/home/mintty/release/2.9.9.tar.gz': No
>> such file or directory
>> But apparently it's also sufficient to provide a dummy url:
>> SRC_URI="${NAME}-${VERSION}-src.tar.bz2"
> The correct value is:
>
> SRC_URI="https://github.com/${NAME}/${NAME}/archive/${VERSION}/${NAME}-${VERSION}.tar.gz"
>
> With your Makefile creating that file name instead of -src.tar.bz2.
Yeah, another construction site that I'll avoid for the next release, so 
for now I'll go with:
# proper URL for actual download:
#SRC_URI="https://github.com/${NAME}/${NAME}/archive/${VERSION}/${NAME}-${VERSION}.tar.gz"
# dummy URL with proper filename as locally available, for cygport:
SRC_URI="${NAME}-${VERSION}-src.tar.bz2"

>
>>   >>> mintty requires: bash cygwin
>> I remember some discussion that the cygwin dependency, which most
>> packages have, should not (or does not need to be) listed.
> That was years ago.  The cygwin dependency can and should be listed nowadays.
OK, where and how, please?

>
>> And in fact, mintty does not depend on bash. Why does cygport think so?
> mintheme has a /bin/sh shebang.
OK, thanks. But it could as well be dash, and it's only an optional 
helper script anyway, so it shall be ignored.

>> As an alternative, I would accept a description how to generate a debug
>> package "manually", with tar.
> Ugly.  Let cygport do this for you.
See next comment:

Björn Stabel wrote:
> On 27/03/2019 23:59, Yaakov Selkowitz wrote:
>> On Wed, 2019-03-27 at 21:02 +0100, Thomas Wolff wrote:
>>> I used to use tar rather than cygport package to generate the packages.
>>> One reason was that I didn’t want my local user/group to appear in them.
>> They won't show up like that once installed.
> Sorry for commenting from the peanut gallery, but his problem may be
> that he doesn't want to disclose his user name to anyone nosy enough to
> snoop around in the package files.
Thanks for expressing the point. Indeed, I consider this a privacy 
issue. So unless I get the information how to generate that 
mintty.exe.dbg file, I could only unpack the debug package and repackage 
it again, blowing up the production process unnecessarily. Or stay 
without debug package for another while...

Thanks for all contributions.
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -