[ANNOUNCEMENT] Updated: mintty 2.9.9

[ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

I have uploaded mintty 2.9.9 with the following changes:

Keyboard handling
   * Fixed modifyOtherKeys mode 1 to use verbatim control keys.

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz]

Thomas Wolff writes:
> I have uploaded mintty 2.9.9 with the following changes:

While you're at it, could you please stop using the release number "0"
for your packages?  That's supposed to be used for test packages only
(if you want to make an effort to convey that in the package file name).
Proper releases should start with "1".

https://cygwin.com/packaging-contributors-guide.html#updating


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

Factory and User Sound Singles for Waldorf rackAttack:
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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Steven Penny]

On Sat, 16 Mar 2019 15:00:54, Achim Gratz wrote:
> Thomas Wolff writes:
>> I have uploaded mintty 2.9.9 with the following changes:
> 
> While you're at it, could you please stop using the release number "0"
> for your packages?  That's supposed to be used for test packages only
> (if you want to make an effort to convey that in the package file name).
> Proper releases should start with "1".
> 
> https://cygwin.com/packaging-contributors-guide.html#updating

I agree. Also currently no dependencies are listed. This is incorrect as Mintty
requires at least the Cygwin DLL. Adding "bash" to "depends2" would take care
of it through child dependencies.


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Hi Achim,

Am 16.03.2019 um 15:00 schrieb Achim Gratz:
> Thomas Wolff writes:
>> I have uploaded mintty 2.9.9 with the following changes:
> While you're at it, could you please stop using the release number "0" for your packages?
I had previously explained why I used to like this (native package, no 
patches) and there had been no comments...
> That's supposed to be used for test packages only
> (if you want to make an effort to convey that in the package file name).
I don't see this documented anywhere.
> Proper releases should start with "1".
>
> https://cygwin.com/packaging-contributors-guide.html#updating
OK, I see *this* described now; I think it changed some time. Was there 
any discussion about it?
Anyway, with maybe one more vote, I'll make the change.
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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Brian Inglis]

On 2019-03-24 09:57, Thomas Wolff wrote:
> Am 16.03.2019 um 15:00 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> I have uploaded mintty 2.9.9 with the following changes:
>> While you're at it, could you please stop using the release number "0" for
>> your packages?
> I had previously explained why I used to like this (native package, no patches)
> and there had been no comments...
>> That's supposed to be used for test packages only
>> (if you want to make an effort to convey that in the package file name).
> I don't see this documented anywhere.
>> Proper releases should start with "1".
>> https://cygwin.com/packaging-contributors-guide.html#updating
> OK, I see *this* described now; I think it changed some time. Was there any
> discussion about it?
> Anyway, with maybe one more vote, I'll make the change.

It may have been informal but is now documented - please go with the flow.
Don't make us come after you with puns about fresh flavours and odours, periods
in education or loans, or finality, that your package begs for!
Let's keep this civil ;^>

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On Mar 24 16:57, Thomas Wolff wrote:
> Hi Achim,
> 
> Am 16.03.2019 um 15:00 schrieb Achim Gratz:
> > Thomas Wolff writes:
> > > I have uploaded mintty 2.9.9 with the following changes:
> > While you're at it, could you please stop using the release number "0" for your packages?
> I had previously explained why I used to like this (native package, no
> patches) and there had been no comments...
> > That's supposed to be used for test packages only
> > (if you want to make an effort to convey that in the package file name).
> I don't see this documented anywhere.
> > Proper releases should start with "1".
> > 
> > https://cygwin.com/packaging-contributors-guide.html#updating
> OK, I see *this* described now; I think it changed some time. Was there any
> discussion about it?
> Anyway, with maybe one more vote, I'll make the change.

While you're at it, a mintty-debuginfo package may be pretty helpful.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Hi Corinna,

Am 24.03.2019 um 19:19 schrieb Corinna Vinschen:
> On Mar 24 16:57, Thomas Wolff wrote:
>> Hi Achim,
>>
>> Am 16.03.2019 um 15:00 schrieb Achim Gratz:
>>> Thomas Wolff writes:
>>>> I have uploaded mintty 2.9.9 with the following changes:
>>> While you're at it, could you please stop using the release number "0" for your packages?
>> I had previously explained why I used to like this (native package, no
>> patches) and there had been no comments...
>>> That's supposed to be used for test packages only
>>> (if you want to make an effort to convey that in the package file name).
>> I don't see this documented anywhere.
>>> Proper releases should start with "1".
>>>
>>> https://cygwin.com/packaging-contributors-guide.html#updating
>> OK, I see *this* described now; I think it changed some time. Was there any
>> discussion about it?
>> Anyway, with maybe one more vote, I'll make the change.
> While you're at it, a mintty-debuginfo package may be pretty helpful.
Sorry, I neither know how to make use of such a package nor how to 
generate it or what it contains.
But I'd take a patch:)
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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Mar 25 00:36, Thomas Wolff wrote:
> Hi Corinna,
> 
> Am 24.03.2019 um 19:19 schrieb Corinna Vinschen:
> > On Mar 24 16:57, Thomas Wolff wrote:
> > > Hi Achim,
> > > 
> > > Am 16.03.2019 um 15:00 schrieb Achim Gratz:
> > > > Thomas Wolff writes:
> > > > > I have uploaded mintty 2.9.9 with the following changes:
> > > > While you're at it, could you please stop using the release number "0" for your packages?
> > > I had previously explained why I used to like this (native package, no
> > > patches) and there had been no comments...
> > > > That's supposed to be used for test packages only
> > > > (if you want to make an effort to convey that in the package file name).
> > > I don't see this documented anywhere.
> > > > Proper releases should start with "1".
> > > > 
> > > > https://cygwin.com/packaging-contributors-guide.html#updating
> > > OK, I see *this* described now; I think it changed some time. Was there any
> > > discussion about it?
> > > Anyway, with maybe one more vote, I'll make the change.
> > While you're at it, a mintty-debuginfo package may be pretty helpful.
> Sorry, I neither know how to make use of such a package nor how to generate
> it or what it contains.

It's autogenerated if you compile and link with -g and refrain from
stripping your executables with -s.  Cygport checks by itself if
debug symbols are available, moves them to /usr/lib/debug and
strips your executable afterwards.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz]

[-- Attachment #1: Type: text/plain, Size: 174 bytes --]

Thomas Wolff writes:
> Sorry, I neither know how to make use of such a package nor how to
> generate it or what it contains.
> But I'd take a patch:)

As you wish…


[-- Attachment #2: mintty.cygport --]
[-- Type: application/octet-stream, Size: 1408 bytes --]

NAME=mintty
VERSION="2.9.9"
RELEASE="1"
CATEGORY="Base Shells"
SUMMARY="Cygwin Terminal – terminal emulator with native Windows look and feel"
DESCRIPTION="Mintty is a terminal emulator for Cygwin. It is based on code
from PuTTY 0.60 by Simon Tatham and team, and features from xterm.

Features include:
* Xterm-compatible terminal emulation.
* Full Unicode support.
* Native Windows user interface that tries to keep things simple.
* Graphical options dialog. Options stored in a text file.
* Drag & drop and copy & paste of text, files and folders.
* Extensive mouse support.
* Window transparency."

HOMEPAGE="http://mintty.github.io/"
SRC_URI="https://github.com/${NAME}/${NAME}/archive/${VERSION}.tar.gz"

DEPEND="gcc-core make"

RESTRICT=postinst_doc

src_compile() {
  lndirs
  cd ${B}
  cygmake
}

src_install() {
  cd ${B}
  dobin bin/mintty.exe
  doman docs/mintty.1
  dodoc COPYING LICENSE.Oxygen LICENSE.PuTTY
  dodoc cygwin/README cygwin/setup.hint
  dobin tools/mintheme

  insinto /usr/share/mintty/lang
  doins lang/*.pot lang/*.po
  insinto /usr/share/mintty/themes
  doins themes/*
  insinto /usr/share/mintty/icon
  doins icon/wsl.ico

  for i in 16 24 32 48 64 256
  do
    insinto /usr/share/icons/hicolor/${i}x${i}/apps
    newins icon/hi${i}-apps-mintty.png mintty.png
  done
  make_desktop_entry mintty "Cygwin Terminal" mintty "System;TerminalEmulator" "" "OnlyShowIn=X-Cygwin;"
}

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: mintty.src.patch --]
[-- Type: text/x-patch, Size: 699 bytes --]

--- origsrc/mintty-2.9.9/src/Makefile	2019-03-16 07:13:38.000000000 +0100
+++ src/mintty-2.9.9/src/Makefile	2019-03-25 10:29:57.918318000 +0100
@@ -94,7 +94,7 @@ ifneq ($(platform), msys)
   # some nested functions) as they cause some security software to choke
   SECUR=-Wtrampolines
 endif
-CFLAGS := -std=gnu99 -include std.h -Wall -Wextra -Wundef -Werror $(SECUR)
+CFLAGS += -std=gnu99 -include std.h -Wall -Wextra -Wundef -Werror $(SECUR)
 
 ifeq ($(shell VER=`$(CC) -dumpversion`; expr $${VER%.*} '>=' 4.5), 1)
   CFLAGS += -mtune=atom
@@ -117,8 +117,7 @@ ifdef DEBUG
   CFLAGS += -g
 else
   CPPFLAGS += -DNDEBUG
   CFLAGS += -fomit-frame-pointer -O2
-  LDFLAGS += -s
 endif
 
 ifdef DMALLOC

[-- Attachment #4: Type: text/plain, Size: 203 bytes --]



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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds


[-- Attachment #5: Type: text/plain, Size: 219 bytes --]


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 25.03.2019 um 19:12 schrieb Achim Gratz:
> Thomas Wolff writes:
>> Sorry, I neither know how to make use of such a package nor how to
>> generate it or what it contains.
>> But I'd take a patch:)
> As you wish…
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?

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

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"

VERSION="2.9.9"
→ This would need the cygport to be generated per version, but 
apparently it’s not required.
RELEASE="1"
→ This does not seem to have any effect either.

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

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

As an alternative, I would accept a description how to generate a debug 
package "manually", with tar.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz]

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Jeffrey Walton]

On Wed, Mar 27, 2019 at 4:36 PM Achim Gratz <Stromeko@nexgo.de> wrote:
> ...
> > 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.

Also of interest is GNU Coding Standards, 7.2.3 Variables for
Specifying Commands
(https://www.gnu.org/prep/standards/html_node/Command-Variables.html):

If there are C compiler options that must be used for proper
compilation of certain files, do not include them in CFLAGS. Users
expect to be able to specify CFLAGS freely themselves. Instead,
arrange to pass the necessary options to the C compiler independently
of CFLAGS, by writing them explicitly in the compilation commands or
by defining an implicit rule, like this:

    CFLAGS = -g
    ALL_CFLAGS = -I. $(CFLAGS)
    .c.o:
            $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<

Do include the ‘-g’ option in CFLAGS, because that is not required for
proper compilation. You can consider it a default that is only
recommended. If the package is set up so that it is compiled with GCC
by default, then you might as well include ‘-O’ in the default value
of CFLAGS as well.

Put CFLAGS last in the compilation command, after other variables
containing compiler options, so the user can use CFLAGS to override
the others.

Jeff

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Steven Penny]

On Wed, 27 Mar 2019 21:02:47, Thomas Wolff wrote:
>  >>> 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?

Uh, Mintty definitely *does* depend on Bash, what makes you think it doesnt?
As a simple test case, rename Bash and try to run Mintty. You get this:

Failed to run '/bin/bash': No such file or directory
/bin/bash: Exit 126.


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Yaakov Selkowitz]

On Wed, 2019-03-27 at 15:51 -0700, Steven Penny wrote:
> On Wed, 27 Mar 2019 21:02:47, Thomas Wolff wrote:
> >  >>> 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?
> 
> Uh, Mintty definitely *does* depend on Bash, what makes you think it doesnt?
> As a simple test case, rename Bash and try to run Mintty. You get this:
> 
> Failed to run '/bin/bash': No such file or directory
> /bin/bash: Exit 126.

"Only" if /bin/bash is your preferred shell.  Granted, that's the
default, and what most users would want anyway, but that is not
strictly speaking a mintty dependency.  As I mentioned in my response,
the auto-detected dependency on bash is from mintheme.

--
Yaakov



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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Steven Penny]

On Wed, 27 Mar 2019 19:09:07, Yaakov Selkowitz wrote:
> "Only" if /bin/bash is your preferred shell.  Granted, that's the
> default, and what most users would want anyway, but that is not
> strictly speaking a mintty dependency.  As I mentioned in my response,
> the auto-detected dependency on bash is from mintheme.

Mintty requires some shell, hopefully that point cannot be argued.

Having said that, Bash is the obvious candidate as its the only login shell
installed by default.

While adding Bash as a dependency could be somewhat misleading, It would argue
it is more misleading to say that it requires no shell, which is the current
state of affairs.

Cheers


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Yaakov Selkowitz]

On Wed, 2019-03-27 at 18:12 -0700, Steven Penny wrote:
> On Wed, 27 Mar 2019 19:09:07, Yaakov Selkowitz wrote:
> > "Only" if /bin/bash is your preferred shell.  Granted, that's the
> > default, and what most users would want anyway, but that is not
> > strictly speaking a mintty dependency.  As I mentioned in my response,
> > the auto-detected dependency on bash is from mintheme.
> 
> Mintty requires some shell, hopefully that point cannot be argued.

We don't have virtual dependencies though, so there's no real way to
express that.

> Having said that, Bash is the obvious candidate as its the only login shell
> installed by default.

Which is exactly why I'm *not* concerned about this being listed
explicitly.

> While adding Bash as a dependency could be somewhat misleading, It would argue
> it is more misleading to say that it requires no shell, which is the current
> state of affairs.

I obviously disagree.

--
Yaakov



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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Brian Inglis]

On 2019-03-27 19:12, Steven Penny wrote:
> On Wed, 27 Mar 2019 19:09:07, Yaakov Selkowitz wrote:
>> "Only" if /bin/bash is your preferred shell.  Granted, that's the
>> default, and what most users would want anyway, but that is not
>> strictly speaking a mintty dependency.  As I mentioned in my response,
>> the auto-detected dependency on bash is from mintheme.
> 
> Mintty requires some shell, hopefully that point cannot be argued.
> 
> Having said that, Bash is the obvious candidate as its the only login shell
> installed by default.
> 
> While adding Bash as a dependency could be somewhat misleading, It would argue
> it is more misleading to say that it requires no shell, which is the current
> state of affairs.

Both dash and bash are in Base, installed by default, and both are login shells,
while dash requires only cygwin1.dll to run, and can be used during setup,
before other libraries or utilities are installed.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Steven Penny]

On Wed, 27 Mar 2019 20:44:44, Brian Inglis wrote:
> Both dash and bash are in Base, installed by default, and both are login
> shells, while dash requires only cygwin1.dll to run, and can be used during
> setup, before other libraries or utilities are installed.

Yeah, I did not mean to say login shell. I am not sure the proper way to phrase
it, so i will just put it like this:

Dash is good for writing scripts, personally I prefer it over Bash. However it
is garbage as an interactive shell. It does not even support readline, and that
is fine because its role is to be a fast shell for scripts.

That is why I did not include it before. I would add that your mail is not on
topic. The point of my email was not "Bash should be the dep", it was "some
shell should be a dep".


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 28.03.2019 um 04:42 schrieb Steven Penny:
> On Wed, 27 Mar 2019 20:44:44, Brian Inglis wrote:
>> Both dash and bash are in Base, installed by default, and both are login
>> shells, while dash requires only cygwin1.dll to run, and can be used 
>> during
>> setup, before other libraries or utilities are installed.
>
> ...
>
>  "some shell should be a dep".
Mintty can be used to run any command-line application directly (like 
top, your editor, ...), a shell is not needed.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Steven Penny]

On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote:
> Mintty can be used to run any command-line application directly (like 
> top, your editor, ...), a shell is not needed.

That may be true, the by default Mintty is configure to load Bash. So it is
disingenuous so simply say that it does not require a shell, unless you want to
change the default to load "top" as you said.


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Brian Inglis]

On 2019-03-28 05:36, Steven Penny wrote:
> On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote:
>> Mintty can be used to run any command-line application directly (like top,
>> your editor, ...), a shell is not needed.
> 
> That may be true, the by default Mintty is configure to load Bash. So it is
> disingenuous so simply say that it does not require a shell, unless you want to
> change the default to load "top" as you said.

I found it useful to create a mintty info alias xinfo c.f. xman; likewise to
launch cygwin32 and WSL distro commands or terms in windows from Cygwin64/X.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

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

Dependancy Hell (was Re: [ANNOUNCEMENT] Updated: mintty 2.9.9)

[Chris Wagner]

On 2019-03-28 7:36 am, Steven Penny wrote:
> On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote:
>> Mintty can be used to run any command-line application directly (like 
>> top, your editor, ...), a shell is not needed.
> 
> That may be true, the by default Mintty is configure to load Bash. So 
> it is
> disingenuous so simply say that it does not require a shell, unless you 
> want to
> change the default to load "top" as you said.
> 

I think that part of the issue is that there is no clear definition of a 
dependancy.  I encounter questionable dependancies all the time from 
Cygwin Setup.  If I try to install the wrong thing, there is a whole 
ecosystem of packages that come with it that I don't want.  I just don't 
install that thing I wanted and live without it or get it another way.

Likewise there are dependancies that are merely advisory and the package 
works just fine without it.

I think that a package should only be listed as a dependancy if the 
upstream package will not even run without it.  Things like library 
packages.  Even if it provides core functionality, if the main package 
will run, it's not a dependancy.  Dependancy hell is one of the few 
things I don't like about Cygwin.


Thanks.


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz]

Thomas Wolff writes:
> Mintty can be used to run any command-line application directly (like
> top, your editor, ...), a shell is not needed.

Your _package_ has a dependency to the shell by way of including a shell
script.  If you so desperately want to get rid of it (even though it's
always installed anyway since it is in Base), then you need to split
this shell skript out into it's own (sub-)package file.  The dependency
on the main package will be dropped amnd moves to the new sub-package.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Yaakov Selkowitz]

On Wed, 2019-03-27 at 21:02 +0100, Thomas Wolff wrote:
> Am 25.03.2019 um 19:12 schrieb Achim Gratz:
> > Thomas Wolff writes:
> > > Sorry, I neither know how to make use of such a package nor how to
> > > generate it or what it contains.
> > > But I'd take a patch:)
> > As you wish…
> 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.

> Is that possible with cygport?

Not currently, PTC.

> 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

That's because you are still overriding CFLAGS with := (the first
time).

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

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.

> VERSION="2.9.9"
> → This would need the cygport to be generated per version, but 
> apparently it’s not required.
> RELEASE="1"
> → This does not seem to have any effect either.

Only because of how you handle your cygport build, which is *much* more
complicated than it should be.

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

Actually, it's a side-by-side assembly under $WINDIR/WinSxS/ on Win7
x64.  In any case, that can be ignored.

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

> And in fact, mintty does not depend on bash. Why does cygport think so?

mintheme has a /bin/sh shebang.

> As an alternative, I would accept a description how to generate a debug 
> package "manually", with tar.

Ugly.  Let cygport do this for you.

--
Yaakov



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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Björn Stabel]

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.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz]

Björn Stabel writes:
> 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.

Not tested, but something like

env TAR_OPTIONS="--user=0 --group=0" cygport ...

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 28.03.2019 um 18:40 schrieb Achim Gratz:
> Björn Stabel writes:
>> 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.
> Not tested, but something like
>
> env TAR_OPTIONS="--user=0 --group=0" cygport ...
>
> should do it.
In fact that seems to work, although there is no TAR_OPTIONS documented 
in the manual page.
But meanwhile I've solved the issue otherwise already.
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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz]

Thomas Wolff writes:
> In fact that seems to work, although there is no TAR_OPTIONS
> documented in the manual page.

The already much too long manual page does tell you to consult the info
manual right at the top, does it not?


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 28.03.2019 um 19:21 schrieb Achim Gratz:
> Thomas Wolff writes:
>> In fact that seems to work, although there is no TAR_OPTIONS
>> documented in the manual page.
> The already much too long manual page does tell you to consult the info
> manual right at the top, does it not?
I do not like the dual chaos of manual vs info pages, and I'm maybe a 
bit old-fashioned to insist that manual pages should be complete, but 
isn't that their purpose?
Kind regards
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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Achim Gratz]

Thomas Wolff writes:
> I do not like the dual chaos of manual vs info pages, and I'm maybe a
> bit old-fashioned to insist that manual pages should be complete, but
> isn't that their purpose?

You are barking up the wrong tree, but if you're that bothered by it,
you can file an RFE or bug report with upstream that you miss the
"ENVIRONMENT VARIABLES" section on their man page.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 28.03.2019 um 20:47 schrieb Achim Gratz:
> Thomas Wolff writes:
>> I do not like the dual chaos of manual vs info pages, and I'm maybe a
>> bit old-fashioned to insist that manual pages should be complete, but
>> isn't that their purpose?
> You are barking up the wrong tree, but if you're that bothered by it,
> you can file an RFE or bug report with upstream that you miss the
> "ENVIRONMENT VARIABLES" section on their man page.
Hi Achim, I didn't mean to bark, just to explain why I hadn't seen the 
TAR_OPTIONS, hope that's alright.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

On Mar 28 09:43, Thomas Wolff wrote:
> 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.

If your repo is on github anyway it would be much simpler to define
the source as a git repo.  Rather than SRC_URI, just use something
like this:

GIT_URI="https://github.com/mintty/mintty.git" # Just as example
# Either...
GIT_TAG="your release tag"
# ...or...
GIT_REV="matching sha1-hash"
inherit git

> Sure, that's why the VERSION should better not be mentioned in it, right?

No, the VERSION and RELEASE fields define how tohe package is called
when you do `cygport package'.

Did you read Cygwin's Package Contributor's Guide?

https://cygwin.com/packaging-contributors-guide.html

It's really not that complicated to do it right.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Jeffrey Walton]

On Thu, Mar 28, 2019 at 4:44 AM Thomas Wolff <towo@towo.net> wrote:
> ...
> 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...

A potential solution is, add another user to your system named cygwin.
When you build you packages use the cygwin user. The debug information
will reference your cygwin user, and not your real user account.

Jeff

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 28.03.2019 um 15:02 schrieb Jeffrey Walton:
> On Thu, Mar 28, 2019 at 4:44 AM Thomas Wolff <towo@towo.net> wrote:
>> ...
>> 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...
> A potential solution is, add another user to your system named cygwin.
> When you build you packages use the cygwin user. The debug information
> will reference your cygwin user, and not your real user account.
Thanks for the suggestion, but there are other solutions meanwhile. 
Also, you would have to remember to switch user everytime, which may 
take a while, and it's not even possible to create user accounts on 
everybody's machine.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Vince Rice]

> On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
> 
>> A potential solution is, add another user to your system named cygwin.
>> When you build you packages use the cygwin user. The debug information
>> will reference your cygwin user, and not your real user account.
> Thanks for the suggestion, but there are other solutions meanwhile. Also, you would have
> to remember to switch user everytime, which may take a while, and it's not even possible
> to create user accounts on everybody's machine.

You're the only one that needs to remember, and it's only your machine that would need the
the user account. Other people building the package don't have the same … requirements …
you do. They're not distributing what they build. They would just use the cygport and be done
with it.

(Not selling the solution as I have no opinion on it, just pointing out that neither of those
objections are really a problem.)
--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 28.03.2019 um 19:16 schrieb Vince Rice:
>> On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
>>
>>> A potential solution is, add another user to your system named cygwin.
>>> When you build you packages use the cygwin user. The debug information
>>> will reference your cygwin user, and not your real user account.
>> Thanks for the suggestion, but there are other solutions meanwhile. Also, you would have
>> to remember to switch user everytime, which may take a while, and it's not even possible
>> to create user accounts on everybody's machine.
> You're the only one that needs to remember, and it's only your machine that would need the
> the user account. Other people building the package don't have the same … requirements …
> you do. They're not distributing what they build. They would just use the cygport and be done
> with it.
>
> (Not selling the solution as I have no opinion on it, just pointing out that neither of those
> objections are really a problem.)
What I wanted to point out with my last objection is that some people 
may not be able to create an account as they like, in an enterprise 
environment.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Vince Rice]

> On Mar 28, 2019, at 1:33 PM, Thomas Wolff wrote:
> 
> Am 28.03.2019 um 19:16 schrieb Vince Rice:
>>> On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
>>> 
>>>> A potential solution is, add another user to your system named cygwin.
>>>> When you build you packages use the cygwin user. The debug information
>>>> will reference your cygwin user, and not your real user account.
>>> Thanks for the suggestion, but there are other solutions meanwhile. Also, you would have
>>> to remember to switch user everytime, which may take a while, and it's not even possible
>>> to create user accounts on everybody's machine.
>> You're the only one that needs to remember, and it's only your machine that would need the
>> the user account. Other people building the package don't have the same … requirements …
>> you do. They're not distributing what they build. They would just use the cygport and be done
>> with it.
>> 
>> (Not selling the solution as I have no opinion on it, just pointing out that neither of those
>> objections are really a problem.)
> What I wanted to point out with my last objection is that some people may not be able to create an account as they like, in an enterprise environment.

And what I was pointing out is that nobody but you needs to. This whole thread is about trying
to solve *your* problem, not someone else's. As I said, if I built mintty, I would just use cygport
and be done with it. I don't care about user information, because I'm not distributing the package.
--
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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Thomas Wolff]

Am 28.03.2019 um 19:38 schrieb Vince Rice:
>> On Mar 28, 2019, at 1:33 PM, Thomas Wolff wrote:
>>
>> Am 28.03.2019 um 19:16 schrieb Vince Rice:
>>>> On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
>>>>
>>>>> A potential solution is, add another user to your system named cygwin.
>>>>> When you build you packages use the cygwin user. The debug information
>>>>> will reference your cygwin user, and not your real user account.
>>>> Thanks for the suggestion, but there are other solutions meanwhile. Also, you would have
>>>> to remember to switch user everytime, which may take a while, and it's not even possible
>>>> to create user accounts on everybody's machine.
>>> You're the only one that needs to remember, and it's only your machine that would need the
>>> the user account. Other people building the package don't have the same … requirements …
>>> you do. They're not distributing what they build. They would just use the cygport and be done
>>> with it.
>>>
>>> (Not selling the solution as I have no opinion on it, just pointing out that neither of those
>>> objections are really a problem.)
>> What I wanted to point out with my last objection is that some people may not be able to create an account as they like, in an enterprise environment.
> And what I was pointing out is that nobody but you needs to. This whole thread is about trying
> to solve *your* problem, not someone else's. As I said, if I built mintty, I would just use cygport
> and be done with it. I don't care about user information, because I'm not distributing the package.
It's a bit strange that you're telling my that *you* don't care about 
*my* information.
I'm trying to raise some awareness about privacy on this occasion (which 
is quite a topic nowadays) and if you don't care, you don't need to comment.

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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Steven Penny]

On Thu, 28 Mar 2019 22:33:48, Thomas Wolff wrote:
> It's a bit strange that you're telling my that *you* don't care about 
> *my* information.
> I'm trying to raise some awareness about privacy on this occasion (which 
> is quite a topic nowadays) and if you don't care, you don't need to comment.

Yeah, he does.

What he has said is exactly right: the problems you are describing will only
be consequential to the maintainer, IE *you*.

As he very correctly put, anyone else building is likely doing so
*for themselves*, hence negating any privacy concern. Unless you are summoning
George Orwell:

If you want to keep a secret, you must also hide it from yourself.


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

Re: [ANNOUNCEMENT] Updated: mintty 2.9.9

[Andrey Repin]

Greetings, Thomas Wolff!

> Am 16.03.2019 um 15:00 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> I have uploaded mintty 2.9.9 with the following changes:
>> While you're at it, could you please stop using the release number "0" for your packages?
> I had previously explained why I used to like this (native package, no 
> patches) and there had been no comments...
>> That's supposed to be used for test packages only
>> (if you want to make an effort to convey that in the package file name).
> I don't see this documented anywhere.
>> Proper releases should start with "1".
>>
>> https://cygwin.com/packaging-contributors-guide.html#updating
> OK, I see *this* described now; I think it changed some time. Was there 
> any discussion about it?
> Anyway, with maybe one more vote, I'll make the change.

I think it was made official with last rewrite of Setup's version matching
algorithm. Some 3 to 5 years ago.
You can tell full official Cygwin release by -1 added to the relevant
upstream version tag. Preliminary/test releases are marked with -0.x.


-- 
With best regards,
Andrey Repin
Sunday, March 24, 2019 23:53:41

Sorry for my terrible english...


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