This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: mintty 2.9.9
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