Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff <towo@towo.net>]

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