Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz <Stromeko@nexgo.de>]

Thomas Wolff writes:
> 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.
> Is that possible with cygport?

PTC.  But yes, I think GNU Tar has an option to override those, cygport
is just not using it yet.

> 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.  A build
system is supposed to be able to pre-configure CFLAGS without your
Makefile nixing all of that effort.

> 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.

> 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.

>>>> 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"
>
> 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.

> RELEASE="1"
> → This does not seem to have any effect either.

???  You must have renamed the cygport file to something else, I think.

> Furthermore, cygport complains (on Windows 7 only):
> which: no gdiplus.dll in (...)
> → It’s in $WINDIR/SysWOW64/.

No idea.

>>>> 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.
> And in fact, mintty does not depend on bash. Why does cygport think so?

There likely is some script that uses bash.  Anything in your package
that uses something from a different package will create a dependency on
it (as it should).  This is not perfect and there are both false
positives and negatives, but in general it does work well enough.
Besides, bash is in Base anyway.

> 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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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