Re: Automatic announcement generation by calm

[Thomas Wolff via Cygwin-apps]

Am 08/01/2024 um 13:35 schrieb Corinna Vinschen via Cygwin-apps:

On Jan  7 16:12, Jon Turney via Cygwin-apps wrote:

This is an experimental facility, currently only available for packages
deployed from the build service [1] (that is, not for self-built packages
uploaded with 'cygport up' via sftp)

When the token "announce" is present for a build job (in addition to
"deploy"), after a successful deploy, calm will automatically generate and
send an announce email.

The mail follows a similar format to that generated by "cygport announce",
containing a list of packages and the description, with the following
addition:

* If the cygport defines the variable "ANNOUNCE", it's evaluated contents
will be appended to the generated mail.

* Otherwise, if the source package contains an ANNOUNCE file [2], it's
contents will be appended.

* Otherwise, if the source package contains a README or ${PN}.README file,
lines that look like part of a changelog, between one starting with '
${PVR}' and the next starting '', will be extracted and appended

(None of these seem like a particularly great way of doing things, but they
match some historical patterns.  As always, suggestions about improvements
are welcome.)


In accordance with our long-standing policy of treating maintainer email
addresses as private information, the mail is sent from cygwin-no-reply and
bcc'ed to the uploader.


For testing purposes, if the token "mock" (yes, I am running out of synonyms
for "test"...) is also present, the mail will be only sent to the uploader,
not the announce list.


[1] https://cygwin.com/packaging/build.html
[2] Note that this isn't currently part of the default value of CYGWIN_FILES
[3], so needs to be explicitly listed there to be included in the source
package
[3] https://cygwin.github.io/cygport/src_prep_cygpart.html#CYGWIN_FILES

:+1:

Unfortunately I started the OpenSSH 9.6 build before reading this here,
but that's some great addition.

Corinna
I'd also appreciate to prefix the mail with an "[ANNOUNCEMENT] " tag as 
for the mails forwarded from cygwin-announcement to cygwin before that 
was stopped, to enhance the overview in users' mailboxes.

Thomas

Re: Bonfire of the Packages

[Thomas Wolff via Cygwin-apps]

Am 24.09.2023 um 20:20 schrieb gstrauss via Cygwin-apps:

On Sun, Sep 24, 2023 at 01:32:59PM +0100, Jon Turney via Cygwin-apps wrote:

Generally, we have a large number of old, unmaintained packages.

The policy [1] has always been "Packages without an active maintainer may be
pulled from the distribution.", but not actively enforced (in fact prior to
2022, this used to say "are pulled", but I moderated the statement, just to
reflect reality).

I guess what's needed is an automated process which removes unmaintained
packages, after some period of time in that state.

I'm somewhat ambivalent about doing that, as they are probably of some use,
but on the hand I don't think our users are best served providing very old
packages with unknown numbers of bugs, security problems, etc., or which are
unsupported upstream.

Were the first steps to be performed by an automated process, I would
propose that the automated process mark and move packages
'pending delete' to a new category "abandoned", which is not installed
by default, but selectable in the cygwin setup.exe.  Alternatively,
'promote' the abandoned packages to "testing".  After a period of time
in "abandoned" or "testing", the packages could be removed to a holding
area, but not yet deleted, since this is the time that some people might
start to notice.  It would be nice to be able to restore packages
relatively quickly during this period.  Finally, after another period of
time passes, delete the package.

Cheers, Glenn
I have two packages that were not updated for 7 years for a while, for 
different reasons, but are still maintained.
What criteria would you have in mind? I don't think this is a reasonable 
approach.

Thomas

Re: Drop djgpp-{binutils,gcc-*,runtime} 32-bit packages

[Thomas Wolff via Cygwin-apps]

Am 24.09.2023 um 14:32 schrieb Jon Turney via Cygwin-apps:

On 08/09/2023 18:29, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Thinking we could drop the ancient (8 years) orphaned DJGPP 32-bit 
(by definition) packages; they are older than djgpp current, never 
mind beta on gcc 13; from DJ's latest Monthly Mini-FAQ summary:


 djdev-2.05 binutils-2.32 ... gcc-10.2.0 ...


Yeah, this seems like the right thing to do.
Unlike old Windows versions, MSDOS / DosBOX is still an environment 
appreciated by enthusiasts to run old games,
and having a cross-compiler for it is a nice thing. I wouldn't think 
it's harmful to keep them around.

Thomas

Re: [ITP] italic-man

[Thomas Wolff via Cygwin-apps]

Am 25.06.2023 um 15:36 schrieb Jon Turney:

On 21/06/2023 22:45, Thomas Wolff via Cygwin-apps wrote:


Am 16.02.2023 um 20:17 schrieb Thomas Wolff via Cygwin-apps:


Am 16.02.2023 um 19:59 schrieb Jon Turney:

On 21/01/2023 17:04, Thomas Wolff via Cygwin-apps wrote:
italic-man installs two scripts and hooks them into the workflow 
of the 'man' command so that the italic attribute of manual pages 
is actually displayed as italics in terminals that support it.


cygport file attached


Thanks very much for having another go at this.

I'm still not overly keen on postinstall/preremove scripts which 
modify a configuration file belonging to another package, so I 
think I'm going to defer to Achim on approving this.


Taking a step back, may I ask a couple of questions?

- Can this be done as a patch to man-db and/or groff?

(perhaps with a separate man-italic package which just contains a 
marker file which enables the functionality?)


- (If different) how would this be done in an upstreamable way?

Thanks for taking a look.
I understand your hesitation but there are a number of zp_ 
postinstall scripts around that make updates to mandb, mime db, 
desktop, various caches, maybe crontab.


There's a difference between updating a cache or db of files which 
exist on the filesystem after the package update and modifying a file 
which might be overwritten by reinstalling or updating a different 
package.


Well, yes, there could be a zp_ script for man that makes this entry 
to /etc/man_db.conf itself in the presence of the italic-man 
package. If that's desired and someone else updates man, I will 
cooperate on this.
I think the installation of italic-man does this in an upstreamable 
way except for the postinstall mechanism of course which seems to be 
different (if existent at all) everywhere.

Thomas
I've added a zp_man-db-italic.dash postinstall script as a proposal 
for man-db to address your concerns, to be found in the repository 
github.com/mintty/italic-man. However, I find not documentation about 
these zp_ things, it seems they are just all called after each setup. So 


They are briefly covered in [1].  If that's missing some details, 
please let me know and I'll see what can be done to improve it.


[1] https://cygwin.com/packaging-package-files.html#postinstall

would it actually make a difference whether the zp_ is a script of 
italic-man or of man-db? I've also added a cygport file to the 
repository so you can try the update if you like.
Still interested in your opinion about this question. Also whether it's 
OK that package italic-man provided a zp script that modified 
/etc/man_db.conf.



About your first question

- Can this be done as a patch to man-db and/or groff?
Do you mean the whole thing should not be a separate package at all 
but completely patched into man-db?


Well, yes, that would avoid all the knots caused by post-install 
scripts with uncertain ordering I'm worrying about.
I think I have addressed those uncertainties and the problem with the 
man-db patch is that man-db package maintainers would need to take up 
the issue...




Can you explain, in general terms, why this isn't a feature of stock 
man-db already?
There is option grotty -i in stock man-db but grotty is a tool deeply 
embedded in the man toolchain and there is no user-friendly documented 
way to inject this option into the toolchain, other than replacing 
grotty with a wrapper script which is effectively all my package does.




Looking forward to your opinion and that of the man-db package 
maintainer.
And yes, the hook works on Linux too, so it could be provided somehow 
upstream.


Thanks continuing to grind away at this.

Re: [ITP] italic-man

[Thomas Wolff via Cygwin-apps]

Am 16.02.2023 um 20:17 schrieb Thomas Wolff via Cygwin-apps:


Am 16.02.2023 um 19:59 schrieb Jon Turney:

On 21/01/2023 17:04, Thomas Wolff via Cygwin-apps wrote:
italic-man installs two scripts and hooks them into the workflow of 
the 'man' command so that the italic attribute of manual pages is 
actually displayed as italics in terminals that support it.


cygport file attached


Thanks very much for having another go at this.

I'm still not overly keen on postinstall/preremove scripts which 
modify a configuration file belonging to another package, so I think 
I'm going to defer to Achim on approving this.


Taking a step back, may I ask a couple of questions?

- Can this be done as a patch to man-db and/or groff?

(perhaps with a separate man-italic package which just contains a 
marker file which enables the functionality?)


- (If different) how would this be done in an upstreamable way?

Thanks for taking a look.
I understand your hesitation but there are a number of zp_ postinstall 
scripts around that make updates to mandb, mime db, desktop, various 
caches, maybe crontab.
Well, yes, there could be a zp_ script for man that makes this entry 
to /etc/man_db.conf itself in the presence of the italic-man package. 
If that's desired and someone else updates man, I will cooperate on this.
I think the installation of italic-man does this in an upstreamable 
way except for the postinstall mechanism of course which seems to be 
different (if existent at all) everywhere.

Thomas
I've added a zp_man-db-italic.dash postinstall script as a proposal for 
man-db to address your concerns, to be found in the repository 
github.com/mintty/italic-man. However, I find not documentation about 
these zp_ things, it seems they are just all called after each setup. So 
would it actually make a difference whether the zp_ is a script of 
italic-man or of man-db? I've also added a cygport file to the 
repository so you can try the update if you like.

About your first question

- Can this be done as a patch to man-db and/or groff?
Do you mean the whole thing should not be a separate package at all but 
completely patched into man-db?

Looking forward to your opinion and that of the man-db package maintainer.
And yes, the hook works on Linux too, so it could be provided somehow 
upstream.

Thomas

cygport injects unexpected parameter

[Thomas Wolff via Cygwin-apps]

I'm trying to build xterm 380 and got two problems in the cygport 
compile step:


1.
*** ERROR: could not determine the autoconf version used to generate 
./configure; perhaps set AUTOCONF_VERSION?


I don't know why a tool wants to be told its own version (or what's 
going on) but the following line in xterm.cygport seems to help:

AUTOCONF_VERSION=$( autoconf --version | sed -e "s,.* ,," -e 1q )

2.
configure: error: unrecognized option: --docdir=/usr/share/doc/xterm

This seems to be injected by the cygconf function, and the package 
configure script does not know it.


Thomas

Re: ACL

[Thomas Wolff via Cygwin-apps]

Am 21.02.2023 um 14:10 schrieb Jonathan Chapman-Moore via Cygwin-apps:

Hi,


I was wondering when ACL was going to be added to Cygwin?

It's long been available, see /bin/[gs]etfacl

Re: [ITP] italic-man

[Thomas Wolff via Cygwin-apps]

Am 16.02.2023 um 19:59 schrieb Jon Turney:

On 21/01/2023 17:04, Thomas Wolff via Cygwin-apps wrote:
italic-man installs two scripts and hooks them into the workflow of 
the 'man' command so that the italic attribute of manual pages is 
actually displayed as italics in terminals that support it.


cygport file attached


Thanks very much for having another go at this.

I'm still not overly keen on postinstall/preremove scripts which 
modify a configuration file belonging to another package, so I think 
I'm going to defer to Achim on approving this.


Taking a step back, may I ask a couple of questions?

- Can this be done as a patch to man-db and/or groff?

(perhaps with a separate man-italic package which just contains a 
marker file which enables the functionality?)


- (If different) how would this be done in an upstreamable way?

Thanks for taking a look.
I understand your hesitation but there are a number of zp_ postinstall 
scripts around that make updates to mandb, mime db, desktop, various 
caches, maybe crontab.
Well, yes, there could be a zp_ script for man that makes this entry to 
/etc/man_db.conf itself in the presence of the italic-man package. If 
that's desired and someone else updates man, I will cooperate on this.
I think the installation of italic-man does this in an upstreamable way 
except for the postinstall mechanism of course which seems to be 
different (if existent at all) everywhere.

Thomas

[ITP] italic-man

[Thomas Wolff via Cygwin-apps]

italic-man installs two scripts and hooks them into the workflow of the 
'man' command so that the italic attribute of manual pages is actually 
displayed as italics in terminals that support it.


cygport file attachedNAME=italic-man
VERSION=1.0
RELEASE=1
ARCH=noarch

SUMMARY="Enabling italic display in manual pages"
CATEGORY="Utils Doc"
HOMEPAGE=https://github.com/mintty/italic-man
DESCRIPTION="italic-man installs two scripts and hooks them into the workflow 
of the 'man' command so that the italic attribute of manual pages is actually 
displayed as italics in terminals that support it."
LICENSE="GNU GPL V3"

SRC_URI=https://github.com/mintty/$NAME/archive/$VERSION/$NAME-$VERSION.tar.gz

SRC_DIR=.

src_compile() {
:
}

src_install() {
cd $S/$NAME-$VERSION
doman italic-man.7
insinto /usr/share/${NAME}
doins grotty iroff
insinto /etc/postinstall
newins postinstall ${NAME}.sh
newins postinstall zp_${NAME}.sh
insinto /etc/preremove
newins preremove ${NAME}.sh
}

Re: [ITP] ffmpeg (5.1.2)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 16:58 schrieb Takashi Yano via Cygwin-apps:

On Fri, 20 Jan 2023 16:47:01 +0100
Thomas Wolff wrote:

Am 20.01.2023 um 16:28 schrieb Takashi Yano via Cygwin-apps:

On Fri, 20 Jan 2023 16:04:46 +0100
Thomas Wolff wrote:

Am 20.01.2023 um 11:35 schrieb Takashi Yano via Cygwin-apps:

I would like to propose new package ffmpeg which is
well known audio/video tool. ffmpeg is ported to
many linux distributions and other unix like systems
as well as widows. Since there is windows build,
the demand of cygwin port might be relatively small,
however its libraries are usefull for other softwares.

I have posted another ITP for MOC (Music On Console)
which is a ncurses based music player, whose plugin
uses ffmpeg libraries.

I have already prepared the ffmpeg package as follows.

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/

To build ffmpeg, other new packages i.e., x264, x265 and
xvidcore are required, I have proposed ITP at the same
time.


It's also missing cygswscale-6.dll which I don't find anywhere.

It should be in:

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/libffmpeg/libffmpeg-5.1.2-1.tar.xz

which is reuqired by ffmpeg-5.1.2-1.tar.xz.

OK, I had overlooked that in the ffmpeg folder.
Now I get:

C:/cygwin64/bin/ffmpeg.exe: error while loading shared libraries: ?:
cannot open shared object file: No such file or directory

Thanks for testing.

You need libSDL2_2.0_0 package installed as described in
https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/ffmpeg-5.1.2-1.hint
A first test suggests that this build may be significantly (~70%) slower 
than the native Windows build of ffmpeg, unfortunately. Do you see a 
possible reason for that and a chance to compensate?

Re: [ITP] ffmpeg (5.1.2)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 16:28 schrieb Takashi Yano via Cygwin-apps:

On Fri, 20 Jan 2023 16:04:46 +0100
Thomas Wolff wrote:

Am 20.01.2023 um 11:35 schrieb Takashi Yano via Cygwin-apps:

I would like to propose new package ffmpeg which is
well known audio/video tool. ffmpeg is ported to
many linux distributions and other unix like systems
as well as widows. Since there is windows build,
the demand of cygwin port might be relatively small,
however its libraries are usefull for other softwares.

I have posted another ITP for MOC (Music On Console)
which is a ncurses based music player, whose plugin
uses ffmpeg libraries.

I have already prepared the ffmpeg package as follows.

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/

To build ffmpeg, other new packages i.e., x264, x265 and
xvidcore are required, I have proposed ITP at the same
time.


It's also missing cygswscale-6.dll which I don't find anywhere.

It should be in:

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/libffmpeg/libffmpeg-5.1.2-1.tar.xz

which is reuqired by ffmpeg-5.1.2-1.tar.xz.

OK, I had overlooked that in the ffmpeg folder.
Now I get:

C:/cygwin64/bin/ffmpeg.exe: error while loading shared libraries: ?: 
cannot open shared object file: No such file or directory

Re: [ITP] ffmpeg (5.1.2)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 11:35 schrieb Takashi Yano via Cygwin-apps:

I would like to propose new package ffmpeg which is
well known audio/video tool. ffmpeg is ported to
many linux distributions and other unix like systems
as well as widows. Since there is windows build,
the demand of cygwin port might be relatively small,
however its libraries are usefull for other softwares.

I have posted another ITP for MOC (Music On Console)
which is a ncurses based music player, whose plugin
uses ffmpeg libraries.

I have already prepared the ffmpeg package as follows.

https://tyan0.yr32.net/cygwin/x86_64/release/ffmpeg/

To build ffmpeg, other new packages i.e., x264, x265 and
xvidcore are required, I have proposed ITP at the same
time.


It's also missing cygswscale-6.dll which I don't find anywhere.

Re: [ITA] libsndfile (1.2.0)

[Thomas Wolff via Cygwin-apps]

Am 20.01.2023 um 11:34 schrieb Takashi Yano via Cygwin-apps:

I would like to take over the maintenance of libsndfile
package which is currently orphanded. I have already
prepared the updated package at:

https://tyan0.yr32.net/cygwin/x86_64/release/libsndfile/


The archive appears to be empty.

calm hint files

[Thomas Wolff via Cygwin-apps]

Upload seems to want two hint files, which even have to be different;
one needs a homepage entry, the other must not have one, or an error 
will be reported.

Can this please be smoothed out?
Thomas

Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko)

[Thomas Wolff]

Am 15/11/2022 um 19:47 schrieb Libor Ukropec:

Dne 04.11.2022 v 14:05 Chad Dougherty napsal(a):

On 2022-11-04 08:34, Jon Turney wrote:

The second is not so clear: A package is orphaned if it's maintainer
is not responsive to queries as to if they still want to be the 
maintainer of the package.


It's undefined how many times we should ping, or how long we should 
wait for a response, but I think that the ~10 months that's elapsed 
here is more than enough!




If the prospective adopter is also proposing an update that addresses 
security vulnerabilities in the old package, I suggest that that, and 
the severity and impact of those vulnerabilities be factored into the 
timeout decision.


What I do not want to do is the violent take over, so I gave some time 
to the original owner of the python-paramiko to respond. I created a 
bug on  github.com almost 2 weeks ago and so far no reaction: 
https://github.com/wildmichael/cygwin/issues/1
As a general comment, I'd like to point out that "almost 2 weeks" is 
even less than someone's holiday time may be...


So I'd like to ask for ITA for his several packages, BUT:

the cygport is executing in "src_test" some python tests that in the 
end requires some python packages not available as cygwin packages 
(typing_extensions, mock, pytest-mock, may be others).


So should I
a) remove the test? (this is not my preference)
or
b) specify/execute in the cygport `pip3 install pkg1 pkg2 ...` - I'd 
expect that executing any stuff in the cygport is not allowed (and I 
do not want to trigger 'misuse alarm')


and additional question - how do I execute scallywag "before" the ITA 
is approved and git repo created? Can/should I use 'playground' branch 
for another package that I already maintain?


I do not see guide on cygwin.com is explaining this.

Thank you,
Libor

Re: Updated: mintty 3.6.2

[Thomas Wolff]

Am 14/11/2022 um 17:24 schrieb Achim Gratz:

Thomas Wolff writes:

I have uploaded mintty 3.6.2 with the following changes:

Shouldn't this mail have been sent to the announce list instead?

Oops. And thanks.



Regards,
Achim.

Updated: mintty 3.6.2

[Thomas Wolff]

I have uploaded mintty 3.6.2 with the following changes:

Unicode and Emoji data
  * Unicode 15.0 update.

Terminal features
  * Status line area support (VT320, xterm 371), DECSSDT, DECSASD.
  * Extended multi-line host-writable status area, DECSSDT 2 N.
  * Combined sub/superscript attributes render small script (#1171).
  * Adjusted subscript position (~#1171).
  * Alternative DEC private SGRs for sub/superscript (#1171).
  * Revamp line cursor handling, size changeable by CSI ? N c (#1157, 
#1175).

  * Support DECSET 117 (DECECM, VT520).
  * Added DECARR to DECRQSS.
  * Prevent font zooming for resizing controls like CSI 8.
  * Optionally visualize margins by dimming.

Keyboard handling
  * Not suppressing user-defined KeyFunctions for keypad keys in keypad 
modes (#1161).
  * Alt+keypad-minus initiates decimal numeric input in case an 
Alt+numpad-digit key is assigned a user-defined function.


Mouse handling
  * Configurable modifiers for hovering and link opening (#1169).
  * Support super and hyper modifiers with mouse functions.
  * Fixed mouse pixel coordinates limits (DECSET 1016).

Initialisation
  * Grab focus again after showing the window, reducing focus delay for 
Windows 11 (#1113).


Configuration
  * Option OldKeyFunctionsKeypad (~#1161, not listed in manual).
  * Option OpeningMod (#1169).
  * New user-definable function reset-noask.
  * Option DimMargins, user-definable function toggle-dim-margins.
  * Option StatusLine, user-definable function toggle-status-line.
  * Background image mode '+' for combined scaling and tiling (#1180).
  * New user-definable function transparency-opaque (#1168).

Other
  * Fixed crash condition on user-defined commands (#1174).
  * Add confirm dialog to Reset triggered by menu or Alt+F8 (#1173).

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

--
Thomas

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Thomas Wolff]

Am 13.11.2022 um 23:13 schrieb Brian Inglis:

On Sun, 13 Nov 2022 18:09:19 +0100, Thomas Wolff wrote:

Am 04.11.2022 um 20:27 schrieb Corinna Vinschen:

On Nov  4 13:07, Brian Inglis wrote:

On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:

Brian Inglis writes:
Suggest that I could come up with a package grep-nowarn which can 
only

suppress the [ef]grep warnings, where the package would install
[ef]grep-nowarn, and the postinstall script could rename the
distributed shell scripts to [ef]grep-warn, and install alternatives
with -warn priority 10, -nowarn priority 20; preremove would reverse
the process.

Suggestions to accommodate -nowarn from grep package postinstall?
I could supply the same postinstall and preremove as -nowarn to 
check

for -nowarn and install or uninstall the alternative.

Sequence or timing issues to watch out for during 
postinstall/preremove?

As Corinna already said, why GNU suddenly cares so much about strict
POSIX conformance in this case is puzzling.  If anything they should
have left the decision to packagers and IMNHO the warning should 
only be

presented when POSIXLY_CORRECT is set in the environment, if at all.
The patch to the wrapper script(s) in question is trivial and several
Linux distributions have removed the warning already (if you do this,
also change the interpreter from bash to dash).  Just skip any
extra packages and do the same.
The issue does not appear to be about POSIX compliance, but that 
[ef]grep

were dropped from POSIX before 2008 and declared obsolescent, so the
maintainers appear to be looking to drop those commands/scripts.

This is a usability issue.  If upstream thinks they have to do such a
potentially destructive and backward-incompatible change for no other
reason than "is not in POSIX", they can do so, but there's no good
reason the distros who *care* for usability have to do this either.

You could perhaps reach out to Eric Blake or Jim Meyering who are 
in the GNU

grep contributor lists for rationale.

While Debian and OpenSuSE have reverted that change, Fedora has not 
in main

or rawhide.
Right, Debian and OpenSuSE revert the change and the BSDs will not 
break

e/fgrep either, obviously.  I doubt Ubuntu will do that. Fedora often
values progress, for a given value of "progress", higher than 
usability.

They will probably see lots of Bugzillas and user requests in other
forums due to this change and then ignore them.  But that doesn't mean
we have to do it.

Again: Egrep and fgrep are used in lots of scripts around the world.  A
change like this will have a massive impact for years to come.

So, again, in the name of usability, let's follow Debian and OpenSuSE
here, not Fedora, please.


@Brian, as a grep package maintainer, can you *please* make a trivial 
patch to remove the grep crap as Corinna suggested and upload an 
updated package *today*, as Jon Turney threatens to freeze the x86 
repository tomorrow?


Successfully deployed from Scallywag and announced.


Great! Thank you very much.

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Thomas Wolff]

Am 04.11.2022 um 20:27 schrieb Corinna Vinschen:

On Nov  4 13:07, Brian Inglis wrote:

On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:

Brian Inglis writes:

Suggest that I could come up with a package grep-nowarn which can only
suppress the [ef]grep warnings, where the package would install
[ef]grep-nowarn, and the postinstall script could rename the
distributed shell scripts to [ef]grep-warn, and install alternatives
with -warn priority 10, -nowarn priority 20; preremove would reverse
the process.

Suggestions to accommodate -nowarn from grep package postinstall?
I could supply the same postinstall and preremove as -nowarn to check
for -nowarn and install or uninstall the alternative.

Sequence or timing issues to watch out for during postinstall/preremove?

As Corinna already said, why GNU suddenly cares so much about strict
POSIX conformance in this case is puzzling.  If anything they should
have left the decision to packagers and IMNHO the warning should only be
presented when POSIXLY_CORRECT is set in the environment, if at all.
The patch to the wrapper script(s) in question is trivial and several
Linux distributions have removed the warning already (if you do this,
also change the interpreter from bash to dash).  Just skip any
extra packages and do the same.

The issue does not appear to be about POSIX compliance, but that [ef]grep
were dropped from POSIX before 2008 and declared obsolescent, so the
maintainers appear to be looking to drop those commands/scripts.

This is a usability issue.  If upstream thinks they have to do such a
potentially destructive and backward-incompatible change for no other
reason than "is not in POSIX", they can do so, but there's no good
reason the distros who *care* for usability have to do this either.


You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU
grep contributor lists for rationale.

While Debian and OpenSuSE have reverted that change, Fedora has not in main
or rawhide.

Right, Debian and OpenSuSE revert the change and the BSDs will not break
e/fgrep either, obviously.  I doubt Ubuntu will do that.  Fedora often
values progress, for a given value of "progress", higher than usability.
They will probably see lots of Bugzillas and user requests in other
forums due to this change and then ignore them.  But that doesn't mean
we have to do it.

Again: Egrep and fgrep are used in lots of scripts around the world.  A
change like this will have a massive impact for years to come.

So, again, in the name of usability, let's follow Debian and OpenSuSE
here, not Fedora, please.
@Brian, as a grep package maintainer, can you *please* make a trivial 
patch to remove the grep crap as Corinna suggested and upload an updated 
package *today*, as Jon Turney threatens to freeze the x86 repository 
tomorrow?

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 13.11.2022 um 17:43 schrieb Achim Gratz:

Thomas Wolff writes:

... Also I'd like to see the hopefully upcoming fix for the grep
package in the final 32 bit version.

sed -i -E 's/^(cmd|echo)/#\1/' /bin/[fe]grep
I know it's a trivial change but as Corinna suggested, it should be in 
the package.

And we shouldn't end up with a frozen repository with the current grep crap.


Regards,
Achim.

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 12.11.2022 um 17:58 schrieb Thomas Wolff:


Am 12.11.2022 um 17:08 schrieb Jon Turney:

On 11/11/2022 20:02, Thomas Wolff wrote:

Hi Achim,

Am 11.11.2022 um 20:50 schrieb Achim Gratz:

Thomas Wolff writes:

I plan to pause package uploads this coming Monday (2022-11-14),
before starting the re-organization of the package repository to
make this archive.
Although expected for a while, the exact date is now a very 
short-time

announcement. Can we have a moratorium for a short while?


So, if not now, when?
Well, first, I think it's not a good idea to change and over-interpret 
a plan in this way. The announcement for a year or so has been "cygwin 
3.4 will not support 32 bit anymore". This does not imply that the 
repository will be closed so any other package would not be allowed 
anymore to provide updates. What about security updates? Basic 
functionality?
I think a plan to freeze the repository would need a separate and 
explicit announcement, and some decent period from then.


Is this actually going to cause you problems, and if so what are they 
specifically, or is this just a case of "change is bad"?
Well I would certainly wish to upload a few more updates for mintty 
also for 32 bit, and also one other package of mine, to know their 
32-bit packages are in a good final state. Mintty 3.6.1, for instance, 
has an exotic crash condition to be fixed but I wouldn't like to make 
an upload in a hurry this weekend.
... Also I'd like to see the hopefully upcoming fix for the grep package 
in the final 32 bit version.





That moratorium is already running for more than a year:

https://cygwin.com/pipermail/cygwin/2021-October/249690.html
That message does not announce a blocking of further 32-bit package 
uploads, and not a precise date for such hard step either. So please 
let's not commit a violation of the principle of least surprise.


Sorry if this was communicated in a surprising way, but there is also 
another, important principle at work here, the principle of least 
effort, or as we might call it in this application "the principle of 
not inventing more work for Jon Turney to do".
Understood, but is it really work to just not touch the repository for 
another few weeks?

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 12.11.2022 um 17:08 schrieb Jon Turney:

On 11/11/2022 20:02, Thomas Wolff wrote:

Hi Achim,

Am 11.11.2022 um 20:50 schrieb Achim Gratz:

Thomas Wolff writes:

I plan to pause package uploads this coming Monday (2022-11-14),
before starting the re-organization of the package repository to
make this archive.

Although expected for a while, the exact date is now a very short-time
announcement. Can we have a moratorium for a short while?


So, if not now, when?
Well, first, I think it's not a good idea to change and over-interpret a 
plan in this way. The announcement for a year or so has been "cygwin 3.4 
will not support 32 bit anymore". This does not imply that the 
repository will be closed so any other package would not be allowed 
anymore to provide updates. What about security updates? Basic 
functionality?
I think a plan to freeze the repository would need a separate and 
explicit announcement, and some decent period from then.


Is this actually going to cause you problems, and if so what are they 
specifically, or is this just a case of "change is bad"?
Well I would certainly wish to upload a few more updates for mintty also 
for 32 bit, and also one other package of mine, to know their 32-bit 
packages are in a good final state. Mintty 3.6.1, for instance, has an 
exotic crash condition to be fixed but I wouldn't like to make an upload 
in a hurry this weekend.



That moratorium is already running for more than a year:

https://cygwin.com/pipermail/cygwin/2021-October/249690.html
That message does not announce a blocking of further 32-bit package 
uploads, and not a precise date for such hard step either. So please 
let's not commit a violation of the principle of least surprise.


Sorry if this was communicated in a surprising way, but there is also 
another, important principle at work here, the principle of least 
effort, or as we might call it in this application "the principle of 
not inventing more work for Jon Turney to do".
Understood, but is it really work to just not touch the repository for 
another few weeks?

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Hi Achim,

Am 11.11.2022 um 20:50 schrieb Achim Gratz:

Thomas Wolff writes:

I plan to pause package uploads this coming Monday (2022-11-14),
before starting the re-organization of the package repository to
make this archive.

Although expected for a while, the exact date is now a very short-time
announcement. Can we have a moratorium for a short while?

That moratorium is already running for more than a year:

https://cygwin.com/pipermail/cygwin/2021-October/249690.html
That message does not announce a blocking of further 32-bit package 
uploads, and not a precise date for such hard step either. So please 
let's not commit a violation of the principle of least surprise.



Regards,
Achim.

Re: Cygwin x86 end-of-life

[Thomas Wolff]

Am 11.11.2022 um 17:16 schrieb Jon Turney:

On 11/11/2022 15:50, Jon Turney wrote:


As has previously been announced, Cygwin is dropping support for x86 
Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) 
Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 
only.


Concurrent with that, updates to x86 packages will be stopped, and 
the Cygwin x86 package repository will be archived.


I plan to pause package uploads this coming Monday (2022-11-14), 
before starting the re-organization of the package repository to make 
this archive.
Although expected for a while, the exact date is now a very short-time 
announcement. Can we have a moratorium for a short while?




When package updates resume (I don't have an ETA, but I expect it will 
take a few days to attend to all the details), attempts to upload x86 
packages will be rejected with an error.


(Instructions on the special steps needed to install from that 
archive will be forthcoming, once we've worked out what they are.)


If you're using x86 Cygwin under WOW64 on a 64-bit Windows OS, please 
strongly consider moving to an x86_64 Cygwin installation.


(If you have ARM hardware, we believe that x86_64 Cygwin works 
correctly using the x86_64 emulation in Windows 11)


If you're one of the tiny percentage of Cygwin users using x86 Cygwin 
on a real x86 Windows OS, don't panic! The current installation will 
continue to run on your system. You just won't get any more updates.

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Thomas Wolff]

Am 28/10/2022 um 10:20 schrieb Corinna Vinschen:

On Oct 28 10:13, Corinna Vinschen wrote:

On Oct 28 00:49, Brian Inglis wrote:

On Thu, 27 Oct 2022 18:25:45 +0200, Corinna Vinschen wrote

On Sep 29 12:55, Brian Inglis wrote:

/usr/share/doc/grep/ChangeLog
https://git.sv.gnu.org/gitweb/?p=grep.git;a=log;h=refs/tags/v3.8

The change note below states that egrep and fgrep are deprecated

obsolescent commands, will be dropped in future, and from this release
until then, every use will show a stderr warning message, reminding you
how to change your commands and scripts:

$ egrep ...

egrep: warning: egrep is obsolescent; using grep -E
...
$ fgrep ...
fgrep: warning: fgrep is obsolescent; using grep -F
...

Please do everyone a favor and remove those warnings.  egrep and fgrep
are used abundantly in existing scripts and the user often has no choice
or no knowledge how to fix this.  If this is an upstream change, it's a
bad one, breaking backward compatibility.  Please fix this at least for
our distro.

This was released as test at the start of September, reiterated at the end
of September on this list, then promoted to current stable and announced
early October:

https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html

I was AFK from mid-September until mid-October, so I only niticed this
on my return.


I received no feedback to these notices on the announce, cygwin and apps
lists from users, maintainers, or developers.

This release is in Fedora Rawhide unpatched and targeted for Fedora 38.

Please note that these warnings are giving notice that egrep and fgrep have
been deprecated as obsolescent for 15 years and will be dropped as commands
as they have never been in POSIX, GREP_COLOR is obsolescent and treated like
GREP_COLORS, unspecified or invalid regular expression warning diagnostics
are now being issued on stderr as they will be treated as errors in future
releases, "binary file matches" messages on stderr may no longer be
suppressed, and invalid bracket expressions are now being treated as errors,
with appropriate diagnostics and exit codes.

I'm aware of that, but upstream is obviously missing the fact that
egrep and fgrep have been part of the history for so long that they
are part of the UNIX gene pool.  As I said there are scripts out
there using egrep and fgrep.  I, for one, can easily tweak the
scripts, but not every user will be able to do so, missing the
knowledge or admin privileges.

There are also the old (and I mean old) users out there who have an
ingrained habit to use egrep and fgrep since it was *always* part
of UNIX.  The warnings are really just a PITA.

Oh, and the BSDs will very certainly keep egrep and fgrep forever,
without the dreaded warnings...

I don't even understand why they are so "bad" that they have to be
removed.  What a weird idea.
I agree so much. People should submit complaint issues upstream, the 
more the better.

It's only not so easy to find a way to submit a Gnu tool bug :(

Re: LICENSE values for non-standard OSS licenses

[Thomas Wolff]

Am 11/10/2022 um 22:13 schrieb Brian Inglis:

On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote:

I'm trying to upload a new version of git-filter-repo, and took the
opportunity to set the LICENSE value in the cygport file.  The new value
looks valid according to my reading of the SPDX specification, but is
being rejected by calm.
The license for git-filter-repo is a bit complicated, because different
parts have different licenses, and several of them aren't "normal"
licenses.  The license is described at [0] and files referenced / linked
from there.
[0]: https://github.com/newren/git-filter-repo/blob/main/COPYING
I've encoded this as the somewhat verbose
    LICENSE='(MIT OR LicenseRef-inherit-git OR 
LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR 
LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) 
AND GPL-2.0-only'
From a mere Boolean perspective, this looks redundant and should be 
simplified to
    LICENSE='(MIT OR LicenseRef-inherit-git OR 
LicenseRef-inherit-libgit2) AND GPL-2.0-only'



The error I'm getting from calm is as follows:
```
ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint
ERROR: package 'git-filter-repo': errors in license expression: 
['Unknown license key(s): LicenseRef-inherit-git, 
LicenseRef-inherit-libgit2, LicenseRef-inherit-libgit2-examples']

ERROR: errors while parsing hints for package 'git-filter-repo'
ERROR: error parsing /sourceware/cygwin-staging/home/Adam 
Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint
ERROR: error while reading uploaded arch noarch packages from 
maintainer Adam Dinwoodie

SUMMARY: 5 ERROR(s)
```
So it looks like the issue is the way I've encoded the non-standard
licensing options.  "LicenseRef-"(idstring) seems to be the way to
encode this sort scenario, per [1] and [2], but that doesn't seem to be
acceptable to calm.
[1]: 
https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/

[2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
Are there any suggestions about how to resolve this?  I don't think I
can just use the standard license strings: even if we used GPL-2.0-only
in place of LicenseRef-inherit-git -- incorrect as that's the license
*currently* used by Git, but the license for git-filter-repo explicitly
incorporates any future OSS license Git might use -- that still leaves
the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0
with an exception that's not covered by any of the SPDX standard
exceptions.
For now I can just remove the LICENSE values to get the build released,
but that seems like a temporary approach at best...


To a similar issue of mine in another thread here (search license) Jon 
replied calm uses:


https://github.com/nexB/license-expression

produced by the same project/dev as scancode (which scans a codebase 
to identify licences as part of project AboutCode), which has 
registered an SPDX namespace for its own LicenceRefs available at:


https://scancode-licensedb.aboutcode.org/

which makes me believe Cygwin should use 
LicenseRef-scancode-public-domain or as referenced there 
LicenseRef-PublicDomain, and license-expression should be able to use 
the scancode list.

fuse

[Thomas Wolff]

What became of the winfsp-fuse project discussed in July 2016?
I'd like to be able to use ftpfs or sshfs in cygwin.
Thomas

Re: github password policy

[Thomas Wolff]

Am 17.08.2021 um 05:00 schrieb Brian Inglis:

On 2021-08-16 17:59, Doug Henderson via Cygwin-apps wrote:

On Mon, 16 Aug 2021 at 07:45, ASSI  wrote:


Thomas Wolff writes:

As I cannot update mintty anymore right now from the git command line,

Yes, I use SSH for all repos now.


Do. Not. Use. GitHub.

The raison raison d'être for GitHub is and always has been to subvert
the fully distributed workflow that Git was designed to provide and
replace it with their centralized lock-in "solution".


As well as GitHub for several public repos, I have used BitBucket for
several private repositories, as they allowed several, while GitHub
only allowed one. They also have a large number of add on features
around the Git repositories, aimed at lock-in.

Does anyone have online Git servers they use and can recommend? BTW, I
have done Google searches, etc. I'm looking for enthusiastic personal
endorsements.


Used the same as you, but I recently also joined Gitlab, run as a 
virtual cooperative corp, as some of my recent adopted upstreams are 
hosted there, and getting redundant release announcements is never a 
bad thing. I haven't yet added any projects there.
When I adopted mintty, I looked at several platforms and also liked 
Gitlab more, but at that time Github was the only platform that offered 
seamless migration from Google Code (where mintty was hosted before) 
including the complete issue history, which was an unbeatable advantage.




GNOME projects are now hosted there, and Alibaba, IBM, and SpaceX use 
it, but as Gitlab servers are on Google Cloud, and subject to US 
embargos like BitBucket, GitHub, and SourceForge, a European mirror 
https://framagit.org/ (part of the Framasoft non-profit network) on 
Debian infrastructure, has been set up to bypass Google and the US, as 
well as allow access to/from embargoed countries.


https://about.gitlab.com/blog/2018/05/31/welcome-gnome-to-gitlab/
https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/
https://framagit.org/explore/projects?name=gnome-=latest_activity_desc 

Re: github password policy

[Thomas Wolff]

Am 16.08.2021 um 19:59 schrieb Yaakov Selkowitz via Cygwin-apps:

On Mon, 2021-08-16 at 19:51 +0200, Thomas Wolff wrote:

Am 16.08.2021 um 16:46 schrieb Lee:

On 8/16/21, Thomas Wolff wrote:

github have changed their authentication policy not to allow passwords
anymore.
So they are asking maintainers to acquire another kind of password (a
"token"), which I did a while ago.
But they refuse to support users with the transition, there is no
"plug-and-play" howto available, except for those who are willing to
dive into details of authentication stuff and spend a few study hours on
that useless policy change.
As I cannot update mintty anymore right now from the git command line,
is any maintainer here impacted by the same issue and can help out with
some advice how to get rid of this nuisance?

ssh keys work - start here:
https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh

Thanks for the link. So I've now added my ssh key to github and
successfully tested it.
Now what? git push apparently still wants to use the old password and
reports an error.

Thanks for all hints.


Make sure the (push)url for the remote to which you wish to push is in the
form g...@github.com:NAMESPACE/PROJECT.git rather than an https:// form.

This URL scheme works for clone and push. And it works without an ssh-agent.
Thanks again
Thomas

Re: github password policy

[Thomas Wolff]

Am 16.08.2021 um 16:46 schrieb Lee:

On 8/16/21, Thomas Wolff wrote:

github have changed their authentication policy not to allow passwords
anymore.
So they are asking maintainers to acquire another kind of password (a
"token"), which I did a while ago.
But they refuse to support users with the transition, there is no
"plug-and-play" howto available, except for those who are willing to
dive into details of authentication stuff and spend a few study hours on
that useless policy change.
As I cannot update mintty anymore right now from the git command line,
is any maintainer here impacted by the same issue and can help out with
some advice how to get rid of this nuisance?

ssh keys work - start here:
https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh
Thanks for the link. So I've now added my ssh key to github and 
successfully tested it.
Now what? git push apparently still wants to use the old password and 
reports an error.

Kind regards,
Thomas


Regards
Lee

github password policy

[Thomas Wolff]

github have changed their authentication policy not to allow passwords 
anymore.
So they are asking maintainers to acquire another kind of password (a 
"token"), which I did a while ago.
But they refuse to support users with the transition, there is no 
"plug-and-play" howto available, except for those who are willing to 
dive into details of authentication stuff and spend a few study hours on 
that useless policy change.
As I cannot update mintty anymore right now from the git command line, 
is any maintainer here impacted by the same issue and can help out with 
some advice how to get rid of this nuisance?

Thanks
Thomas

Re: setup 2.906 release candidate - please test

[Thomas Wolff]

Am 17.03.2021 um 21:02 schrieb Jon Turney:


A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version)
  https://cygwin.com/setup/setup-2.906.x86.exe    (32 bit version)

Please test, and report any problems here.
I feel the need to take this occasion to woe about the terrible UI of 
setup. Two years or more ago there was a major revision, sarcastically 
accompanied by the comment the UI would have been pushed forward to the 
90s. Before that, you could simply select a package by clicking one (!) 
checkbox. Since then, you have to open a popup, scroll to the latest 
version and click that. This multiplies the effort to do selections 
significantly and it's quite a nuisance.


This is not the place for setup feature requests.
It's not a feature as it was much better before; it's a regression. Can 
we please get back a fast-usable interface?

Thomas



Changes compared to 2.905:

- If a selected site URL saved from the last run starts with 
"http://;, and an identical URL, except starting with "https://;, is 
in the current mirror list, migrate it from "http://; to "https://;.


- Propagate the value of the CYGWIN environment variable into 
post-install and pre-remove scripts (Thanks to Michael Wild for this 
patch).
  Partially addresses: 
https://cygwin.com/pipermail/cygwin/2020-August/245994.html


- Warn about unknown package names used with '--packages' or 
'--remove-packages' options.


- Move (potentially localizable) installation progress and package 
action strings to string table resource.


- Fix new warnings and build issues with gcc 10.

Re: ssh key / upload problem on new PC

[Thomas Wolff]

Am 16.03.2021 um 12:28 schrieb Adam Dinwoodie:

On Tue, 16 Mar 2021 at 11:25, Thomas Wolff wrote:

Hi,
I'm about to upload mintty 3.4.7 but I'm getting a "Host key
verification failed." error.
Trying this on a new machine; I copied the whole ~/.ssh folder from my
old machine, something that used to work in the past. It still works
from the old machine (as confirmed by fallback for uploading mintty 3.4.6).
Does anybody have an idea what might be going wrong? Do I need a new ssh
key? (But porting the key worked before...)

What happens if you do `ssh cyg...@cygwin.com`? That'll normally point
out what the error is. I expect either (a) you've managed to not copy
over your `.ssh/known_hosts` file somehow, or (b) some of the files
you've copied over have the wrong permissions; my money's on the
latter. If so, `chmod 600 ~/.ssh/*; chmod 700 ~/.ssh` will normally
get things going again.

It was rather (a) which got fixed by ssh. Thanks a lot.
Thomas

ssh key / upload problem on new PC

[Thomas Wolff]

Hi,
I'm about to upload mintty 3.4.7 but I'm getting a "Host key 
verification failed." error.
Trying this on a new machine; I copied the whole ~/.ssh folder from my 
old machine, something that used to work in the past. It still works 
from the old machine (as confirmed by fallback for uploading mintty 3.4.6).
Does anybody have an idea what might be going wrong? Do I need a new ssh 
key? (But porting the key worked before...)

Thanks
Thomas

cygport: Request to prevent loss and leak of time information

[Thomas Wolff]

Hi,
in addition to the recent request to set anonymous/generic user 
information in the tar archives,

I'd like to suggest also to apply a careful policy about timestamps:

 * Preserve timestamp information for original files: download upstream
   archive with server timestamp (wget -N / curl -R), keep its
   timestamp and that of patch and cygport files when copying to the
   staging directory for the src archive (cp -p), keep their timestamps
   when creating the archive (default).
 * Hide timestamp information for local build files: clear clock value
   when creating binary and debug archives (tar --mtime=00:00).

Kind regards,
Thomas

Re: cygport: Request a new feature in order to set owner/group names in packaged tarballs.

[Thomas Wolff]

Am 04.08.2020 um 22:34 schrieb Lemures Lemniscati via Cygwin-apps:

On Tue, 4 Aug 2020 15:46:13 +0200, Thomas Wolff

Am 04.08.2020 um 14:54 schrieb Lemures Lemniscati via Cygwin-apps:

Date: Mon, 03 Aug 2020 21:24:11 +0200
From: Achim Gratz


Lemures Lemniscati via Cygwin writes:

This is another patch, so that cygport shall make tarballs with
specified owner and group names.

Cygport patches should better go to cygwin-apps.  I've already sent a
patch that allows you to do the same thing some time ago, but it has
not been reviewed yet.

https://repo.or.cz/cygport/rpm-style.git/commitdiff/c6af2ca23aae5da3e99c70cf2b704430b929f431


Nice.

Then, how about a commit following yours.

It is much less than obvious in that older patch that you can trick the 
owner/group information into that option.
I'd appreciate a simple explicit option for that.

All right.

I've simplified options to Simplify options to CYGPORT_TAR_OPTS and
CYGPORT_TAR_EXT.

https://github.com/cygwin-lem/cygport/commit/5a502cc84b8db0b47eae8b3571d363d106e74160


This will work:

CYGPORT_TAR_OPTS="--owner=foo --group=bar" cygport baz.cygport package

And if you have tar >=1.31, these will also work:

CYGPORT_TAR_EXT=".tar.zst" cygport baz.cygport package

CYGPORT_TAR_OPTS="--owner=foo --group=bar" CYGPORT_TAR_EXT=".tar.zst" cygport 
baz.cygport package
I'd like to suggest, additionally to an explicit option, to set user and 
group by default, as it is also a privacy issue to spread the packager's 
user name out to the world in the tar archive.
In that case I'd use the project name (no version) for the user name and 
"cygwin" for the group name.

Thomas

Re: cygport: Request a new feature in order to set owner/group names in packaged tarballs.

[Thomas Wolff]

Am 04.08.2020 um 14:54 schrieb Lemures Lemniscati via Cygwin-apps:

Date: Mon, 03 Aug 2020 21:24:11 +0200
From: Achim Gratz 


Lemures Lemniscati via Cygwin writes:

This is another patch, so that cygport shall make tarballs with
specified owner and group names.

Cygport patches should better go to cygwin-apps.  I've already sent a
patch that allows you to do the same thing some time ago, but it has
not been reviewed yet.

https://repo.or.cz/cygport/rpm-style.git/commitdiff/c6af2ca23aae5da3e99c70cf2b704430b929f431


Nice.

Then, how about a commit following yours.
It is much less than obvious in that older patch that you can trick the 
owner/group information into that option.

I'd appreciate a simple explicit option for that.


https://github.com/cygwin-lem/cygport/commit/a88f1dfa3619fcf817d558761a5249b09e71cc3c

Now it is suffienct to specify CYGPORT_TAR_EXT as ".tar.zst" in order
use zstd. But it needs tar version >= 1.31.



And a next one is for making BUILD_REQUIRES a single-line list in
*src.hint files.

https://github.com/cygwin-lem/cygport/commit/7607782d3d1972aef6b88ee32f5211f21abbbcfb

Re: [ATTN MAINTAINER] mintty

[Thomas Wolff]

Am 07.06.2020 um 07:52 schrieb Achim Gratz:

Thomas Wolff writes:

If you make that the default, yes.  :-)

Or I could move the check to the About info box. Other opinions?

That is better, yes.  But again, the even better option IMHO is to have
a button on a dedicated dialog page that say "Check online on … for
updates.".  That's what LibreOffice does and they do have a configure
option to remove the whole thing when the application is under control
of the system package manager.  That is exactly the situation on Cygwin:
MinTTY is packaged and the information that Github has a new version is
useless anyway.

OK, I'm going the easy way and just change the default CheckVersionUpdate=0.
As the current notification (in the Options dialog title) is 
asynchronous (in order not to ever delay mintty by this) and 
asynchronous modification of a MessageBox (as used for the About info) 
is not possible in Windows, moving it there would have become very 
tricky anyway.

Thomas

Re: [ATTN MAINTAINER] mintty

[Thomas Wolff]

Am 06.06.2020 um 23:53 schrieb Brian Inglis:

On 2020-06-06 14:09, Achim Gratz wrote:

Thomas Wolff writes:

Am 06.06.2020 um 20:43 schrieb ASSI:

Thomas Wolff writes:

There is no such ping on each start, it's only done when you open the
Options dialog.

I don't want that to happen just because I open the options dialog
either.  So again, please remove it or put it behind a button that
clearly tells the user what is going to happen.

The version check can be disabled by setting CheckVersionUpdate=0, is
that sufficient?

If you make that the default, yes.  :-)

I can find no mention of this option or action in any announcement: could you
please ensure that new options added do not change existing behaviour as far as
possible, or are clearly documented in the ANNOUNCEMENT and NEWS as breaking
compatibility, and perhaps add a setting for this option at the bottom of the
Options/Terminal dialogue, for those users who wish to enable it.
I probably blocked it in my firewall on first use, so you might also want to
warn users that they could get a firewall prompt.

It was listed in the change log of release 2.7.5. It's just an HTTP 
request, so I doubt a firewall will speak up.
Anyway, my proposal is to move it to About, which seems to be common 
practice now (Firefox, Thunderbird).

Votes welcome.
Thomas

Re: [ATTN MAINTAINER] mintty

[Thomas Wolff]

Am 06.06.2020 um 22:09 schrieb Achim Gratz:

Thomas Wolff writes:

Am 06.06.2020 um 20:43 schrieb ASSI:

Thomas Wolff writes:

There is no such ping on each start, it's only done when you open the
Options dialog.

I don't want that to happen just because I open the options dialog
either.  So again, please remove it or put it behind a button that
clearly tells the user what is going to happen.

The version check can be disabled by setting CheckVersionUpdate=0, is
that sufficient?

If you make that the default, yes.  :-)

Or I could move the check to the About info box. Other opinions?
Thomas

Re: [ATTN MAINTAINER] mintty

[Thomas Wolff]

Am 06.06.2020 um 20:43 schrieb ASSI:

Thomas Wolff writes:

There is no such ping on each start, it's only done when you open the
Options dialog.

I don't want that to happen just because I open the options dialog
either.  So again, please remove it or put it behind a button that
clearly tells the user what is going to happen.
The version check can be disabled by setting CheckVersionUpdate=0, is 
that sufficient?

Re: [ATTN MAINTAINER] mintty

[Thomas Wolff]

Am 06.06.2020 um 13:31 schrieb ASSI:

Could you please excise the version check from mintty, at least for the
Cygwin build?  There is no legitimate reason for sending a ping to
Github on each start of mintty.
There is no such ping on each start, it's only done when you open the 
Options dialog.

Thomas

upload with "previous"

[Thomas Wolff]

I wanted to upload mintty 3.1.6 with a specific setup.hint containing
curr: 3.1.6
prev: 3.1.4
but got it wrong so the upload was "normal" instead.
I've now uploaded just the setup.hint (mintty-3.1.6-1.hint) and !ready 
files manually. Will that work or should I repeat the complete upload?

Thomas

Re: Quick query about Windows versions

[Thomas Wolff]

Am 01.04.2020 um 11:36 schrieb Corinna Vinschen:

On Mar 31 18:58, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

On 31/03/2020 17:24, ASSI wrote:

Hamish McIntyre-Bhatty via Cygwin-apps writes:

Just thought I should ask: is there a perferred version of Windows to
build packages on, or does it not matter?

Whatever supported version of Windows you use, I'd say.


I currently build on Windows 7, following the tradition of building on
the oldest supported platform, but I have no idea if this is needed with
Cygwin.

No Windows 7 system should still have the ability to connect to the
internet… so no, I don't think you should even try to build there.


Regards,
Achim.

Yep, that's why I asked. I'll upgrade the VM to Windows 10 then, if it
makes no difference to Cygwin.

None at all.  Right now we still support all versions since Windows
Vista, so any breakage building stuff on these systems is the fault
of the Cygwin core.  Other than that, Achim is right, of course :)
Unless your package would use w32api and explicitly detect the build 
system version to include more or less features depending on it...

Re: cygport upload

[Thomas Wolff]

Am 27.03.2020 um 17:27 schrieb Jon Turney:

On 27/03/2020 16:15, Thomas Wolff wrote:

Am 27.03.2020 um 16:41 schrieb Jon Turney:

On 27/03/2020 14:35, Thomas Wolff wrote:

Am 27.03.2020 um 13:21 schrieb Jon Turney:

On 27/03/2020 10:17, Thomas Wolff wrote:

How does cygport upload work?
I previously uploaded with sftp but cygport apparently runs lftp 
and it asks me for a password.


This just seems to be a thing lftp does.

If the key isn't coming from ssh-agent, it always asks for a 
passphrase. If the key doesn't have one, you can just hit enter 
(or type anything).
OK, works. Can lftp or cygport be configured so that lftp does not 
ask for a password? Or to use sftp instead?


I don't know of any configuration for lftp to turn off that 
behaviour (which is arguably a defect in lftp), but that's probably 
something you could investigate for yourself.


I am not sure why lftp is used instead of sftp, possibly it is 
insufficiently scriptable to do what cygport wants to do.



Uploading the two Unicode packages, I got this response:

ERROR: package '/sourceware/cygwin-staging/home/Thomas 
Wolff/noarch/release/unicode-cldr' is not in the package list
ERROR: package '/sourceware/cygwin-staging/home/Thomas 
Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is 
not in the package list

SUMMARY: 2 ERROR(s)


Ah, right.

I've updated cygwin-pkg-maint and made the appropriate adjustment.

There still seems to be a problem with the form of the version 
number you've chosen, however.

Yes, calm complains about

'-' in version

but 36-1 is the version format used upstream. Do I need to convert it?


Looking at http://cldr.unicode.org/index/download, I see it called 36.1
Right. The download files are provided at 
https://github.com/unicode-org/cldr where you can see release-36-1.


The fact that the upstream filename contains '36-1' alone doesn't seem 
sufficient to grant an exception.
I think I'll put something like REPOVER=${VERSION//./-} into the cygport 
file for the download then.


I am not quite clear how unicode-cldr replaces 
unicode-cldr-emoji-annotation, if we have anything which requires it 
to build, since it doesn't appear to provide the .pc file that did.

Please elaborate. I do not see any .pc file in the previous package.
The new package include /usr/share/unicode/cldr/common/annotations 
(which the previous one provided solely) and other subdirectories of 
/usr/share/unicode/cldr/common.


Maybe I am mistaken, but looking at the filelists in 
https://cygwin.com/packages/summary/unicode-cldr-emoji-annotation.html, 
package unicode-cldr-emoji-annotation contains 
/usr/share/pkgconfig/cldr-emoji-annotation.pc
I wasn't aware of that. Not sure, though, what it's good for. I'd prefer 
to go without it unless it's missed by someone.

Thomas

Re: cygport upload

[Thomas Wolff]

Am 27.03.2020 um 16:41 schrieb Jon Turney:

On 27/03/2020 14:35, Thomas Wolff wrote:

Am 27.03.2020 um 13:21 schrieb Jon Turney:

On 27/03/2020 10:17, Thomas Wolff wrote:

How does cygport upload work?
I previously uploaded with sftp but cygport apparently runs lftp 
and it asks me for a password.


This just seems to be a thing lftp does.

If the key isn't coming from ssh-agent, it always asks for a 
passphrase. If the key doesn't have one, you can just hit enter (or 
type anything).
OK, works. Can lftp or cygport be configured so that lftp does not 
ask for a password? Or to use sftp instead?


I don't know of any configuration for lftp to turn off that behaviour 
(which is arguably a defect in lftp), but that's probably something 
you could investigate for yourself.


I am not sure why lftp is used instead of sftp, possibly it is 
insufficiently scriptable to do what cygport wants to do.



Uploading the two Unicode packages, I got this response:

ERROR: package '/sourceware/cygwin-staging/home/Thomas 
Wolff/noarch/release/unicode-cldr' is not in the package list
ERROR: package '/sourceware/cygwin-staging/home/Thomas 
Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is 
not in the package list

SUMMARY: 2 ERROR(s)


Ah, right.

I've updated cygwin-pkg-maint and made the appropriate adjustment.

There still seems to be a problem with the form of the version number 
you've chosen, however.

Yes, calm complains about

'-' in version

but 36-1 is the version format used upstream. Do I need to convert it?


I am not quite clear how unicode-cldr replaces 
unicode-cldr-emoji-annotation, if we have anything which requires it 
to build, since it doesn't appear to provide the .pc file that did.

Please elaborate. I do not see any .pc file in the previous package.
The new package include /usr/share/unicode/cldr/common/annotations 
(which the previous one provided solely) and other subdirectories of 
/usr/share/unicode/cldr/common.

Thomas

Re: cygport upload

[Thomas Wolff]

Am 27.03.2020 um 13:21 schrieb Jon Turney:

On 27/03/2020 10:17, Thomas Wolff wrote:

How does cygport upload work?
I previously uploaded with sftp but cygport apparently runs lftp and 
it asks me for a password.


This just seems to be a thing lftp does.

If the key isn't coming from ssh-agent, it always asks for a 
passphrase. If the key doesn't have one, you can just hit enter (or 
type anything).
OK, works. Can lftp or cygport be configured so that lftp does not ask 
for a password? Or to use sftp instead?

Uploading the two Unicode packages, I got this response:

ERROR: package '/sourceware/cygwin-staging/home/Thomas 
Wolff/noarch/release/unicode-cldr' is not in the package list
ERROR: package '/sourceware/cygwin-staging/home/Thomas 
Wolff/noarch/release/unicode-cldr/unicode-cldr-emoji-annotation' is not in the 
package list
SUMMARY: 2 ERROR(s)

cygport upload

[Thomas Wolff]

How does cygport upload work?
I previously uploaded with sftp but cygport apparently runs lftp and it 
asks me for a password.

Thomas

Re: Putting packages up for adoption

[Thomas Wolff]

Am 20.03.2020 um 13:09 schrieb Jon Turney:

On 20/03/2020 03:47, Yaakov Selkowitz wrote:

Hello Cygwin package maintainers,

[...]

To that end, in the best interest of the community, please consider my
packages up for adoption.  I don't expect that any one person will take
all of them; some are obsolete and due for removal anyway, some should
be picked up as soon as possible, and others might just end up
bitrotting if nobody is interested in them.  However, in whatever there
is interest (or need), hopefully what is there now will serve as a
strong foundation to on which to continue to build.


It's been a pleasure working with you (since 2008!).  Thanks for all 
your hard work over the years!


I will volunteer to adopt the X.org packages (note by this I really 
mean stuff that comes from X.org, it doesn't include toolkits like Qt 
or GTK+, or desktop environments like MATE or XFCE)
I can offer to adopt xterm, unicode-ucd and 
unicode-cldr-emoji-annotation, generalizing the latter to unicode-cldr.

Thomas

ssh key fails

[Thomas Wolff]

Trying to upload mintty, my sftp access fails.
After reconfiguration of my machine, I copied over the complete ~/.ssh 
directory (which worked between completely different machines before), 
but it says

cyg...@cygwin.com: Permission denied (publickey).

Did anything change?
Thomas

Re: [ITP] italic-man

[Thomas Wolff]

Am 11.08.2019 um 00:29 schrieb Brian Inglis:

On 2019-08-10 03:07, Thomas Wolff wrote:

Am 09.08.2019 um 22:51 schrieb Brian Inglis:

On 2019-08-09 13:31, Thomas Wolff wrote:

Am 09.08.2019 um 20:56 schrieb Achim Gratz:

Jon Turney writes:

This gets a GTG from me.
I believe that according to our stated procedures additional approvals
are required, because this package is unique to cygwin.

I'm not sure I remember correctly from when the discussion went on the
first time, but wasn't there some mumbling about this partly going into
groff?  If that's still the case, remind me what this would entail and
I'll look into it.

There are multiple ways of activating the feature (also described in the man
page).
The previous strategy placed a shell script wrapper "groff" aside groff, so the
groff script and groff.exe would coexist in /bin. This was tricky to install and
particularly it reportedly did not survive a package update of groff.
The new approach does not use this wrapper anymore. Instead it redirects nroff
to the package-supplied iroff script by configuration in /etc/man_db.conf.

How are updates to man-db, /etc/man_db.conf etc. handled?
I checked the man-db postinstall script, and it does not overwrite 
man_db.conf if it exists already, so the modification will persist.

Is a permanent postinstall script provided to maintain the conf on man-db 
updates?
Not needed under the observation above. If it were, how would a 
permanent postinstall be deployed?

Thanks,
Thomas


There's also use of the undocumented LESS_TERMCAP_... with GROFF_NO_SGR env vars
(see attached - must be sourced from profile or rc) to remap bold, underline,
etc. into italic and/or colour, or whatever else you want to change, in all less
output.

So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls
should have the same effect? Cannot reproduce. And what does GROFF_NO_SGR do?

Those settings affect all *less* output, not just *man*.
Some people can't stand any colours (white on black was good enough for my
grandfather...) the same as I couldn't wait for decent fonts, graphics, and
colour support on something other than plotters, like displays and printers, and
then for files.
Options are good, to allow users to choose where and what is affected, and how.

Sorry, been messing around with colours, fonts, graphics, and SGR sequences so
much, that I can't remember what led to what. You need the reset sequences also.
Set GROFF_NO_SGR=1 to pass old bold/italic overstrikes thru for less to
colourize - looks like if GROFF_NO_SGR just exists it works:

$ LESS_TERMCAP_md=$(tput bold)$(tput setaf 4) \
LESS_TERMCAP_me=$(tput sgr0) \
LESS_TERMCAP_us=$(tput sitm)$(tput setaf 4) \
LESS_TERMCAP_ue=$(tput ritm)$(tput sgr0) \
GROFF_NO_SGR= man man

bold is also bright blue, underline is shown as italic in blue: the attached now
sets these up in the env.

Other uses of SGR sequences are in e.g.:
$ GREP_COLORS='mt=0;33;44;1;7:ln=34' grep -bnHi color ~/.bash*
which on mt matches resets SGR, then sets fg colour yellow, background blue,
enables bold, then reverses those colours, to display bold blue on bright
yellow, line numbers in green, defaulting file names to magenta, and byte counts
in blue; also e.g.:
$ \
GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'\
gcc -g -Og -Wall -Wextra -c mintty_config.c

as I run black fg text in white bg windows, and bright yellow fg warnings are
invisible; just like blue fg messages in black bg windows, most combos of
magenta and red, and many of cyan and green: those similar hues should be
unmappable pairs in any colour palette!

Re: [ITP] italic-man

[Thomas Wolff]

Am 10.08.2019 um 11:07 schrieb Thomas Wolff:

Am 09.08.2019 um 22:51 schrieb Brian Inglis:

On 2019-08-09 13:31, Thomas Wolff wrote:

Am 09.08.2019 um 20:56 schrieb Achim Gratz:

Jon Turney writes:

This gets a GTG from me.
I believe that according to our stated procedures additional 
approvals

are required, because this package is unique to cygwin.

I'm not sure I remember correctly from when the discussion went on the
first time, but wasn't there some mumbling about this partly going 
into

groff?  If that's still the case, remind me what this would entail and
I'll look into it.
There are multiple ways of activating the feature (also described in 
the man page).
The previous strategy placed a shell script wrapper "groff" aside 
groff, so the
groff script and groff.exe would coexist in /bin. This was tricky to 
install and

particularly it reportedly did not survive a package update of groff.
The new approach does not use this wrapper anymore. Instead it 
redirects nroff
to the package-supplied iroff script by configuration in 
/etc/man_db.conf.
There's also use of the undocumented LESS_TERMCAP_... with 
GROFF_NO_SGR env vars
(see attached - must be sourced from profile or rc) to remap bold, 
underline,
etc. into italic and/or colour, or whatever else you want to change, 
in all less

output.

So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls
should have the same effect? Cannot reproduce. And what does 
GROFF_NO_SGR do?

Ah, this works:
GROFF_NO_SGR= LESS_TERMCAP_us="^[[3m" LESS_TERMCAP_ue="^[[23m" man ls
no matter what the value of GROFF_NO_SGR is. Which tool in the `man` 
chain interprets the latter?


Value-added of my package:
* automatic injection into the `man` pipe
* terminal-dependent enabling, after checking the terminal type

Re: [ITP] italic-man

[Thomas Wolff]

Am 09.08.2019 um 22:51 schrieb Brian Inglis:

On 2019-08-09 13:31, Thomas Wolff wrote:

Am 09.08.2019 um 20:56 schrieb Achim Gratz:

Jon Turney writes:

This gets a GTG from me.
I believe that according to our stated procedures additional approvals
are required, because this package is unique to cygwin.

I'm not sure I remember correctly from when the discussion went on the
first time, but wasn't there some mumbling about this partly going into
groff?  If that's still the case, remind me what this would entail and
I'll look into it.

There are multiple ways of activating the feature (also described in the man 
page).
The previous strategy placed a shell script wrapper "groff" aside groff, so the
groff script and groff.exe would coexist in /bin. This was tricky to install and
particularly it reportedly did not survive a package update of groff.
The new approach does not use this wrapper anymore. Instead it redirects nroff
to the package-supplied iroff script by configuration in /etc/man_db.conf.

There's also use of the undocumented LESS_TERMCAP_... with GROFF_NO_SGR env vars
(see attached - must be sourced from profile or rc) to remap bold, underline,
etc. into italic and/or colour, or whatever else you want to change, in all less
output.

So (without my package) LESS_TERMCAP_us=$(tput sitm) man ls
should have the same effect? Cannot reproduce. And what does 
GROFF_NO_SGR do?

Re: [ITP] italic-man

[Thomas Wolff]

Am 09.08.2019 um 20:56 schrieb Achim Gratz:

Jon Turney writes:

This gets a GTG from me.

I believe that according to our stated procedures additional approvals
are required, because this package is unique to cygwin.

I'm not sure I remember correctly from when the discussion went on the
first time, but wasn't there some mumbling about this partly going into
groff?  If that's still the case, remind me what this would entail and
I'll look into it.
There are multiple ways of activating the feature (also described in the 
man page).
The previous strategy placed a shell script wrapper "groff" aside groff, 
so the groff script and groff.exe would coexist in /bin. This was tricky 
to install and particularly it reportedly did not survive a package 
update of groff.
The new approach does not use this wrapper anymore. Instead it redirects 
nroff to the package-supplied iroff script by configuration in 
/etc/man_db.conf.

Thomas

[ITP] italic-man

[Thomas Wolff]

I'm again proposing a package to enable italic display of manual pages 
(as originally intended).

I changed the deployment strategy, following comments in my previous attempt
(https://cygwin.com/ml/cygwin-apps/2017-04/msg00116.html).
A cygport file is included as suggested by Jon Turney but I haven't 
tested it as the Makefile works just fine without.

wget http://towo.net/cygwin/italic-man/italic-man-1.0-1-src.tar.xz
wget http://towo.net/cygwin/italic-man/italic-man-1.0-1.tar.xz
wget http://towo.net/cygwin/italic-man/setup.hint

Re: calm: cygwin package upload report from sourceware.org for Thomas Wolff

[Thomas Wolff]

Jon Turney wrote:

On 29/03/2019 18:11, Thomas Wolff wrote:
I've repeatedly tried to upload a new package, with the two discussed 
modifications in packaging, and the last response was this:


Am 29.03.2019 um 19:02 schrieb 
cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:
ERROR: package 'mintty' version '3.0.0-1' is most recent non-test 
version, but version '2.9.9-0' is curr:


This is because you have an existing override.hint file for mintty, 
containing:


curr: 2.9.9-0
prev: 2.9.6-0

You have to decide what you want instead of this.
I see no such .hint file in the upload area anymore. Even downloaded the 
current .hint files to check.


Brian Inglis wrote:

If used, that should be:
curr: 3.0.0-1
prev: 2.9.9-0

Check your ${P}/${P}-${V}/${P}-${V}-{R}.${ARCH}/dist/${P}/** hints and tars all
have the same ${P}-${V}-{R} i.e. mintty-3.0.0-1.

The issue may be, as explained, that 2.9.9-0 is treated as a test release.

So I'll try the .hint as you fixed...

Thomas

Re: calm: cygwin package upload report from sourceware.org for Thomas Wolff

[Thomas Wolff]

I've repeatedly tried to upload a new package, with the two discussed 
modifications in packaging, and the last response was this:


Am 29.03.2019 um 19:02 schrieb cygwin-no-re...@cygwin.com:

ERROR: package 'mintty' version '3.0.0-1' is most recent non-test version, but 
version '2.9.9-0' is curr:
ERROR: install packages from source package 'mintty' have non-unique current 
versions 3.0.0-1 (mintty-debuginfo), 2.9.9-0 (mintty)
ERROR: error while validating merged x86 packages for Thomas Wolff
ERROR: package 'mintty' version '3.0.0-1' is most recent non-test version, but 
version '2.9.9-0' is curr:
ERROR: install packages from source package 'mintty' have non-unique current 
versions 3.0.0-1 (mintty-debuginfo), 2.9.9-0 (mintty)
ERROR: error while validating merged x86_64 packages for Thomas Wolff
SUMMARY: 6 ERROR(s)

Should I upload mintty-3.0.0-1.hint files with
curr: 3.0.0.1
prev: 2.9.9.0
?

Re: calm: cygwin package upload report from sourceware.org for Thomas Wolff

[Thomas Wolff]

Am 28.03.2019 um 19:11 schrieb cygwin-no-re...@cygwin.com:

ERROR: file 'mintty-debuginfo-3.0.0-1.hint' in package 'mintty' contains '-' in 
version
ERROR: file 'mintty-debuginfo-3.0.0-1.hint' in package 'mintty' has a version 
which doesn't start with a digit
ERROR: file 'mintty-debuginfo-3.0.0-1.tar.xz' in package 'mintty' contains '-' 
in version
ERROR: file 'mintty-debuginfo-3.0.0-1.tar.xz' in package 'mintty' has a version 
which doesn't start with a digit
ERROR: error while reading uploaded arch x86 packages from maintainer Thomas 
Wolff
ERROR: file 'mintty-debuginfo-3.0.0-1.hint' in package 'mintty' contains '-' in 
version
ERROR: file 'mintty-debuginfo-3.0.0-1.hint' in package 'mintty' has a version 
which doesn't start with a digit
ERROR: file 'mintty-debuginfo-3.0.0-1.tar.xz' in package 'mintty' contains '-' 
in version
ERROR: file 'mintty-debuginfo-3.0.0-1.tar.xz' in package 'mintty' has a version 
which doesn't start with a digit
ERROR: error while reading uploaded arch x86_64 packages from maintainer Thomas 
Wolff
SUMMARY: 10 ERROR(s)

???

Re: setup 2.894 release candidate - please test

[Thomas Wolff]

Am 13.10.2018 um 20:49 schrieb Jon Turney:


A new setup release candidate is available at:

  https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version)
  https://cygwin.com/setup/setup-2.894.x86.exe    (32 bit version)

Please test and report any problems here.
There's one small but occasionally bothersome long-standing issue; may I 
ask for enhancement on this occasion:
If I click through the dialog quickly by consecutive Enter and hit one 
Enter too many, setup will be on one of the two download pages before I 
notice and will abort because initially only the "Cancel" button is 
activated as interactive default button. This could easily be prevented 
by not ever making "Cancel" the default, even when it is the only 
enabled button.

Thanks for considering
Thomas

Re: mintty should have skipped one version

[Thomas Wolff]

I think I uploaded mintty 2.9.3 with a dedicated mintty-2.9.3-0.hint file with
the first two lines
curr: 2.9.3-0
prev: 2.9.1-0
but setup still offers 2.9.2 as a choice. Did I miss the point in the upload
procedure?

Brian Inglis wrote:

Maybe use override.hint instead as described in:

https://cygwin.com/ml/cygwin-apps/2018-08/msg00047.html

where replace-versions should reference 2.9.2-?

According to https://cygwin.com/packaging-hint-files.html#override.hint,
it should be "not associated with a specific /version-release/", that's 
why I did not consider this for the use case.


Marco wrote:

In this case I prefer to remove the broken version,

OK, so how would I do that?


As mentioned by Brian, can you for the future start with revision "-1" ?
In theory we are using revison 0.x for test version pre-release.
You are one of the few starting with 0 
In contrast to many packages that are adapted from somewhere "upstream", 
cygwin is the native development environment for mintty, and is packaged 
without patches. I kind of like to express that with the -0.

mintty should have skipped one version

[Thomas Wolff]

I think I uploaded mintty 2.9.3 with a dedicated mintty-2.9.3-0.hint 
file with the first two lines

curr: 2.9.3-0
prev: 2.9.1-0

but setup still offers 2.9.2 as a choice. Did I miss the point in the 
upload procedure?

Thomas

Re: regex man-page confusion

[Thomas Wolff]

Am 17.09.2018 um 14:49 schrieb cyg Simple:

On 9/16/2018 5:52 PM, Thomas Wolff wrote:

Thanks; on the system with both packages not installed, man -w regcomp
says nothing (rather than "No manual entry...");
`manpath` reveals /usr/share/man:/cygdrive/c/Windows/SUA/usr/share/man
and in fact, the man page displayed comes from my SUA installation. But
$MANPATH is empty, so what makes cygwin `man` access the SUA man pages???


As per [1] you need to check your /etc/man_db.conf file.

I hadn't mentioned that but I had checked it, grep -i sua only found
"usually".

Found the culprit meanwhile: /cygdrive/c/Windows/SUA/usr/lib was in my
PATH. If I remove it, the SUA man page is not displayed anymore.
So the more specific question: What makes cygwin 'man' check the PATH
(not the LD_LIBRARY_PATH) to find which library and - still - why does
that lead it to SUA man pages???

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: regex man-page confusion

[Thomas Wolff]

Am 16.09.2018 um 20:13 schrieb Marco Atzeri:

Am 16.09.2018 um 19:59 schrieb Thomas Wolff:

(Sending this to cygwin-apps as I suspect it to be an installation or
packaging issue...)



I observe a confusing discrepancy between Cygwin installations on two
systems, all with cygwin 2.11.1:
On one system (both cygwin32 and cygwin64), /usr/share/man has
man3/regex.3.gz and man3p/regcomp.3p,
both pages describe functions regcomp, regexec, regerror and regfree,
but in different format (from man3, it says BSD manual).
On the other system, none of them exists, nor any other
/usr/share/man/*/reg* (MANPATH not set). But `man regcomp` nonetheless
displays a manpage, with those 4 functions and additionally wcs_regcomp
and wcs_regexec.
Can anyone resolve this weirdness?
Thanks, Thomas


regex.3.gz belongs to cygwin-doc package

https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fcygwin-doc%2Fcygwin-doc-2.11.1-1=regex.3.gz


regcomp.3p belongs man-pages-posix

https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fman-pages-posix%2Fman-pages-posix-2013-a-1=regcomp.3p


I assume one system has both packages and the other not.

As I have not the second installed, for me

$ man regcomp
No manual entry for regcomp

Regards
Marco

Thanks; on the system with both packages not installed, man -w regcomp
says nothing (rather than "No manual entry...");
`manpath` reveals /usr/share/man:/cygdrive/c/Windows/SUA/usr/share/man
and in fact, the man page displayed comes from my SUA installation. But
$MANPATH is empty, so what makes cygwin `man` access the SUA man pages???

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

regex man-page confusion

[Thomas Wolff]

(Sending this to cygwin-apps as I suspect it to be an installation or 
packaging issue...)


I observe a confusing discrepancy between Cygwin installations on two 
systems, all with cygwin 2.11.1:
On one system (both cygwin32 and cygwin64), /usr/share/man has 
man3/regex.3.gz and man3p/regcomp.3p,
both pages describe functions regcomp, regexec, regerror and regfree, 
but in different format (from man3, it says BSD manual).
On the other system, none of them exists, nor any other 
/usr/share/man/*/reg* (MANPATH not set). But `man regcomp` nonetheless 
displays a manpage, with those 4 functions and additionally wcs_regcomp 
and wcs_regexec.

Can anyone resolve this weirdness?
Thanks, Thomas

Re: Retiring setup.hint

[Thomas Wolff]

Am 25.10.2017 um 21:42 schrieb Jon Turney:


I propose that calm will stop accepting uploads containing setup.hint 
some time shortly after 2017-11-18.


This is approximately one year after the cygport release [1] which, 
stopped generating these files, so if you're using cygport >= 0.23.0, 
no action is needed.


Warnings that you need to upgrade cygport have been generated for more 
than 6 months [2].


After setup.hint uploads are disabled, any remaining setup.hint in the 
cygwin release on sourceware.org will be migrated to pvr.hint(s), as 
per [3].


[1] https://cygwin.com/ml/cygwin-announce/2016-11/msg00078.html
[2] https://cygwin.com/ml/cygwin-apps/2017-04/msg00024.html
[3] https://cygwin.com/ml/cygwin-apps/2016-09/msg00025.html
I would appreciate to see some explanation about this. Why the change 
and what are package maintainers expected to do?
If calm can simply "rename setup.hint to pvr.hint", what's the purpose 
of all this?

Thomas

Re: [ITP] man-italic

[Thomas Wolff]

Hi Jon,

Am 19.04.2017 um 20:38 schrieb Jon Turney:

On 28/09/2016 20:46, Thomas Wolff wrote:

The man-italic wrapper scripts enable italic display in manual pages
(where italic is specified in the page) in terminals supporting 
italic mode.


wget http://towo.net/cygwin/man-italic/man-italic-0.9-0.tar.bz2
wget http://towo.net/cygwin/man-italic/man-italic-0.9-src.tar.bz2
wget http://towo.net/cygwin/man-italic/setup.hint


This seems to have fallen through the cracks and been completely 
forgotten.  Sorry about that.

Fine you noticed anyway:)

Looking at this, I see that this is not a cygport package.  While this 
is something which has been done historically, and I know it may seen 
overkill for something this small, it's something I'm very reluctant 
to see in new packages.
As you say, overkill; I've fiddled around with cygport a few times 
already and I can't say I'm happy with it. While it seems to be 
powerful, especially basic use isn't documented in a basic way... Would 
you have a pattern for a script-only package for me, or even ready-to-use?



The license which applies to the original work here needs to be stated.
Checking the package contributor's guide, a license does not seem to be 
strictly necessary, so I thought for a simple thing it could go as 
public domain implicitly. But if you prefer, I'll attach a gnu to it.


It would be helpful if the description clarified that what this does 
is "show italic text in man pages properly as italic, rather than as 
underlined"
You mean the sdesc one-liner, not ldesc? I'd like to include the 
"enabling" aspect because the package does not do the actual display 
itself and does not need to be invoked as a tool, like:
sdesc: "Enabling proper italic display of italic text in man pages, 
rather than underlined"

OK?


That said, this works and is pretty cool. Nice!
Thanks. Would that be a "GTG" after sorting out the issues, or are still 
3 supporters needed as there used to be?


Thomas

Re: Obsolete dependency report, 2017-Mar-24

[Thomas Wolff]

Hi Yaakov,

Am 24.03.2017 um 19:35 schrieb Yaakov Selkowitz:
A few packages have been uploaded recently which require maintainers 
to update or rebuild their packages.  For those which are related to 
Python, please be sure to use the latest cygport and review the many 
changes therein.


algol68g Thomas Wolff
...
Not sure what this mail means. This package does not have a python 
dependency. It's not obsolete either.

Thomas

Re: network installation failed, new diagnostics

[Thomas Wolff]

Am 16.01.2017 um 14:00 schrieb Corinna Vinschen:

On Jan 15 23:49, Thomas Wolff wrote:

Concerning https://cygwin.com/ml/cygwin-apps/2016-07/msg00021.html,
I have some new insights; first, I tried with a range of older versions of
setup.exe (from the cygwin time machine) but all failed, so its not a
regression as I had speculated.

Then I tried to run setup.exe without elevation, by elevating before
(running mintty as adminstrator). So I noted (and could have checked this
earlier...) that the involved network mounts were not fully established:

mount (unelevated):
L:/TGI/cygwin7 on / type ntfs (binary,auto)
L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto)
...

mount (elevated):
//141.64.144.100/Labormaterial/TGI/cygwin7 on / type ntfs (binary,auto)
...

After fixing the mount:
net use L: '\\141.64.144.100\Labormaterial'

setup.exe works as expected.

Not being familiar with details of Windows permission stuff and
user-specific mounts myself, does this help to analyse and maybe even fix
the situation?

This is an UAC issue, not a Cygwin setup issue.  When elevating, the
mounts are not propagated to the elevated processes.  There's a
documented registry value enabling the supposedly dangerous propagation
of mount point to elevated processes, but I don't knowe it off the top
of my head.  You may want to search MSDN.
On my home systems, mounts are not propagated at all, I wouldn't expect 
setup to work then, agreed.
However, on that lab systems, the mounts are kind of half-way propagated 
to elevated mode.
They and visible and accessible using the network path (cd 
//141.64.144.100/Labormaterial/TGI; ...).
Now setup.exe apparently has remembered the network path for the Local 
Package Directory which appears as \\141... in the respective setup.exe 
screen, and in fact it does all the downloading to that directory, it 
just fails during later installation which corresponds to the Root 
Directory path appearing in drive format (L:...) in the respective 
setup.exe screen.
I'm just thinking if setup.exe would handle the Root Directory path in 
the same way as it handles the Local Package Directory path, the setup 
should work in that case.

--
Thomas

network installation failed, new diagnostics

[Thomas Wolff]

Concerning https://cygwin.com/ml/cygwin-apps/2016-07/msg00021.html,
I have some new insights; first, I tried with a range of older versions 
of setup.exe (from the cygwin time machine) but all failed, so its not a 
regression as I had speculated.


Then I tried to run setup.exe without elevation, by elevating before 
(running mintty as adminstrator). So I noted (and could have checked 
this earlier...) that the involved network mounts were not fully 
established:


mount (unelevated):
L:/TGI/cygwin7 on / type ntfs (binary,auto)
L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto)
...

mount (elevated):
//141.64.144.100/Labormaterial/TGI/cygwin7 on / type ntfs (binary,auto)
...

After fixing the mount:
net use L: '\\141.64.144.100\Labormaterial'

setup.exe works as expected.

Not being familiar with details of Windows permission stuff and 
user-specific mounts myself, does this help to analyse and maybe even 
fix the situation?

Thanks
Thomas

[ITP] man-italic

[Thomas Wolff]

The man-italic wrapper scripts enable italic display in manual pages
(where italic is specified in the page) in terminals supporting italic mode.

wget http://towo.net/cygwin/man-italic/man-italic-0.9-0.tar.bz2
wget http://towo.net/cygwin/man-italic/man-italic-0.9-src.tar.bz2
wget http://towo.net/cygwin/man-italic/setup.hint

Thomas

Re: [PATCH setup] (Usability improvement) Implement half-second wait for user to finish typing before searching packages

[Thomas Wolff]

Am 02.08.2016 um 11:22 schrieb Corinna Vinschen:

On Aug  1 23:17, Ronald Ramos wrote:

commit 357c1e7576586349efb8514dc9d8d03950e225ee
Author: Ronald Ramos 
Date:   Mon Aug 1 23:05:44 2016 -0400

 * proppage.h (PropertyPage)
 New member OnTimerMessage (delegates similarly to OnMouseWheel)

 * proppage.cc
 (DialogProc) Added handling of WM_TIMER

 * choose.h (ChooserPage)
 (OnTimerMessage) New function prototype
 (timer_id) New member variable
 Added DEFINE-ed default values for timer_id and search timer delay
 Reorganized private members for consistency

 * choose.cc
 (constructor) Initialize timer_id
 (OnMessageCmd) Replaced search-refresh with a SetTimer
 (OnSearchTimer) New; contains search-refresh removed from
OnMessageCmd

Neat!  Applied.  Personally I would rather see a shorter timeout like,
say, 300ms, but I guess we shouldn't take for granted that everybody is
typing fast.  Even with 500ms timeout it's now much more convenient than
the old "search after each keypress" method.
I agree with Corinna. Great enhancement, but 300ms should be a good 
trade-off for unpatient people...

Thomas

network installation access rights/ACL issues

[Thomas Wolff]

Hi Corinna,
any ideas about this network installation problem? I sent the requested 
ACL infos:

https://cygwin.com/ml/cygwin-apps/2016-06/msg00084.html
I'll be in that lab again on Monday, in case you may ask for further 
diagnostics.

Thomas

Re: Network installation still fails, Windows 7 only

[Thomas Wolff]

Am 21.06.2016 um 14:04 schrieb Corinna Vinschen:

On Jun 21 09:01, Thomas Wolff wrote:

I had recently reported that an old network installation problem, that had
been resolved meanwhile, reappeared:
https://cygwin.com/ml/cygwin-apps/2015-12/msg00012.html

As an additional observation, on the same machine, there is also a virtual
machine running Windows XP. From that, I can use setup.exe and seamlessly
update cygwin which is then also available in the Windows 7 host
environment. Running setup.exe from Windows 7 directly still fails with the
described symptoms.

There must be something weird about interpretation of access rights using
the Windows 7 API.
As an idea, perhaps someone familiar with setup.exe could check whether at
any place access is rejected due to interpretation of access rights without
actually trying the access?

Setup usually doesn't explicitely check access, it only sets ACLs
POSIX-like.  How does the ACL look like (icacls *and* getfacl output,
please) it complains about?



Windows 7:

$ getfacl /etc
# file: /etc
# owner: Administratoren
# group: Domänen-Benutzer
user::rwx
group::r-x
group:SYSTEM:rwx
group:Benutzer:r-x
group:Professoren:rwx
group:Mitarbeiter:rwx
group:Lehrbeauftragte:rwx
mask:rwx
other:r-x
default:user::rwx
default:group::---
default:group:SYSTEM:rwx
default:group:Benutzer:r-x
default:group:Professoren:rwx
default:group:Mitarbeiter:rwx
default:group:Lehrbeauftragte:rwx
default:mask:rwx
default:other:r-x

$ getfacl 'L:\TGI\cygwin'
# file: L:\TGI\cygwin
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::r-x
other:r-x

$ getfacl 'L:\TGI\cygwin/var/log/setup.log'
# file: L:\TGI\cygwin/var/log/setup.log
# owner: wolff
# group: Domänen-Benutzer
user::rw-
group::r--
other:r--

$ getfacl 'H:\'
# file: H:\
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::r-x
other:r-x

$ getfacl 'H:\tmp'
# file: H:\tmp
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::r-x
other:r-x

$ icacls L:/TGI/cygwin/etc
L:/TGI/cygwin/etc VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
  NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
  ERSTELLER-BESITZER:(I)(OI)(CI)(IO)(F)
  VORDEFINIERT\Benutzer:(I)(OI)(CI)(RX)
  Jeder:(I)(OI)(CI)(RX)
  DIGITALLABOR\Professoren:(I)(OI)(CI)(M,DC)
  DIGITALLABOR\Mitarbeiter:(I)(OI)(CI)(M,DC)
  DIGITALLABOR\Lehrbeauftragte:(I)(OI)(CI)(M,DC)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler 
aufgetreten.

$ icacls L:/TGI/cygwin/var/log/setup.log
L:/TGI/cygwin/var/log/setup.log VORDEFINIERT\Administratoren:(I)(F)
NT-AUTORITŽT\SYSTEM:(I)(F)
VORDEFINIERT\Benutzer:(I)(RX)
Jeder:(I)(RX)
DIGITALLABOR\Professoren:(I)(M,DC)
DIGITALLABOR\Mitarbeiter:(I)(M,DC)
DIGITALLABOR\Lehrbeauftragte:(I)(M,DC)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler 
aufgetreten.

$ icacls H:/
H:/ VORDEFINIERT\Administratoren:(OI)(CI)(F)
NT-AUTORITŽT\SYSTEM:(OI)(CI)(F)
ERSTELLER-BESITZER:(OI)(CI)(IO)(M,DC)
DIGITALLABOR\Mitarbeiter:(OI)(CI)(M,DC)
DIGITALLABOR\wolff:(OI)(CI)(M,DC)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler 
aufgetreten.

$ icacls H:/tmp
H:/tmp VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
   NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
   DIGITALLABOR\wolff:(I)(M,DC)
   ERSTELLER-BESITZER:(I)(OI)(CI)(IO)(M,DC)
   DIGITALLABOR\Mitarbeiter:(I)(OI)(CI)(M,DC)
   DIGITALLABOR\wolff:(I)(OI)(CI)(IO)(M,DC)

1 Dateien erfolgreich verarbeitet, bei 0 Dateien ist ein Verarbeitungsfehler 
aufgetreten.



Virtual Windows XP:

$ getfacl /etc
# file: /etc
# owner: Administratoren
# group: Domänen-Benutzer
user::rwx
group::r-x
group:SYSTEM:rwx
group:Benutzer:r-x
group:Professoren:rwx
group:Mitarbeiter:rwx
group:Lehrbeauftragte:rwx
mask:rwx
other:r-x
default:user::rwx
default:group::---
default:group:SYSTEM:rwx
default:group:Benutzer:r-x
default:group:Professoren:rwx
default:group:Mitarbeiter:rwx
default:group:Lehrbeauftragte:rwx
default:mask:rwx
default:other:r-x

$ getfacl L:/TGI/cygwin
# file: L:/TGI/cygwin
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::r-x
other:r-x

$ getfacl L:/TGI/cygwin/var/log/setup.log
# file: L:/TGI/cygwin/var/log/setup.log
# owner: wolff
# group: Domänen-Benutzer
user::rw-
group::r--
other:r--

$ getfacl H:/
# file: H:/
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::r-x
other:r-x

$ getfacl H:/tmp
# file: H:/tmp
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::r-x
other:r-x

$ cacls L:/TGI/cygwin
L:\TGI\cygwin VORDEFINIERT\Administratoren:(OI)(CI)F
  NT-AUTORITŽT

Network installation still fails, Windows 7 only

[Thomas Wolff]

I had recently reported that an old network installation problem, that 
had been resolved meanwhile, reappeared:

https://cygwin.com/ml/cygwin-apps/2015-12/msg00012.html

As an additional observation, on the same machine, there is also a 
virtual machine running Windows XP. From that, I can use setup.exe and 
seamlessly update cygwin which is then also available in the Windows 7 
host environment. Running setup.exe from Windows 7 directly still fails 
with the described symptoms.


There must be something weird about interpretation of access rights 
using the Windows 7 API.
As an idea, perhaps someone familiar with setup.exe could check whether 
at any place access is rejected due to interpretation of access rights 
without actually trying the access?


--
Thomas

Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0

[Thomas Wolff]

Am 11.05.2016 um 00:11 schrieb Yaakov Selkowitz:

Package Maintainers,

cygport 0.22.0 is on its way to the mirrors.  With this release, and
thanks to Jon Turney's continuing work on calm (the replacement for
upset which generates setup.ini), packages marked ARCH=noarch will be
uploaded once under the /noarch/release hierarchy instead of into each
of /x86/release and /x86_64/release.  This change is intended to save
disk space and bandwidth for both sourceware and our mirrors.

A package should be marked ARCH=noarch IF AND ONLY IF *all*
subpackages thereof do not contain anything compiled with the *native*
gcc, and the file contents are (or can be) 100% identical for x86 and
x86_64. Examples include, but are not limited to, packages which
contain only:

* documentation;
* scripts;
* fonts;
* icon themes;
* other runtime data;
* C/C++ headers without a library;
* libraries for cross-compiler toolchains.
* pure Lua/Perl/Python/Ruby/Tcl modules without C/C++ bindings.

I wonder why this list or this action does not include all the source
packages, which might even save more disk space than all the others
together.
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

cmp missing from base

[Thomas Wolff]

Hi,
after a recent fresh installation of cygwin, I was surprised that `cmp` 
was missing, which is part of the traditional Unix base commands.

I think the diffutils package should be part of the base installation.
Kind regards,
Thomas

upload failed - "calm messages"??

[Thomas Wolff]

I have uploaded mintty 2.3.4, using the same upload script as before, but received a mail from 
cygwin-no-re...@cygwin.com titled "calm messages for Thomas Wolff [...]" telling me 
"no setup.hint in /sourceware/cygwin-staging/home/Thomas Wolff/x86/release/mintty but files: 
mintty-2.3.4-0.tar.xz, mintty-2.3.4-0-src.tar.xz".
Have the rules changed?
Thomas

Re: [ANNOUNCEMENT] xdg-utils 1.1.1-2

[Thomas Wolff]

Hi Yaakov,

* xdg-utils-1.1.1-2
As I understand, this package is not exclusively intended for XWin, for 
example mintty was integrated too at your request.
So I think it should not come in the category "X11" alone, but also in 
"Utils" or even "Shells" (like chere).

Thomas

Re: Removing cygwin32-*, cygwin64-*

[Thomas Wolff]

Am 09.02.2016 um 23:48 schrieb Andrew Schulman:

Is anyone using the cygwin32- and/or cygwin64-* cross-compiling
toolchain for anything besides cross-building cygwin itself?  I would
like to remove most of these from the distro if at all possible.

FWIW, I've tried to cross-compile some of my packages between i386 and x86_64,
and it's never worked. The build always fails for one reason or another that I
can't solve.  So I gave up and no, I don't use them any more.
For a package maintainer, it's not only easier, but also useful for 
testing, to simply install cygwin-32 and -64 in parallel.

No need for cross-building.
What about the mingw cross-compiling packages? Are they any good for 
(never tried)?

Thomas

Re: network installation problems (again)

[Thomas Wolff]

Am 02.01.2016 um 09:21 schrieb D. Boland:

Thomas Wolff wrote:

Am 01.01.2016 um 09:44 schrieb D. Boland:

Thomas Wolff wrote:

Hi,
I am again having problems to install cygwin on a network drive. 
It's in the same network I had similar problems before:

http://cygwin.com/ml/cygwin-apps/2009-11/msg00034.html
which were then resolved after a while.
The client machines are now new, running Windows 7. Domain server 
is the old one.
My description log of actions and popup errors is attached below. 
There was no way to install on the network. I could install to the 
C: drive and move that over to the network where it would then run.




Happy new year, y'all!

You shouldn't try to install Cygwin on a network share and execute 
it locally. That's like installing and running Linux on a Samba share.


If you want to use a single Cygwin distro on all computers in your 
network, you should install it on the target host, including the 
openssh daemon. Then on the client machines, you use Putty to log on 
to the host.
I need Cygwin on the network clients, not on a server (and this has 
been working for years, just with occasional install problems).
Also (if I understand your first sentence correctly), I did not try 
to install centrally for client use, but to install on a client for 
that client's use, just on a network drive. And in fact that's the 
only option on that system which is a lab network and the local (C:) 
drives are cleared after each reboot.

--
Thomas

So you're kind of hacking into your lab computers, right? :-) I 
noticed something in your original output:


---
Fehler
---
Directory H:\tmp does not exist, would you like me to create it?
---
Ja   Nein
---

And:

---
Cygwin Setup
---
Cannot open log file L:\TGI\cygwin/var/log/setup.log for writing
---
OK
---

That's strange. Setup tries to install on different disks. Does the 
network share change each time you log on?
No. Install target is in L:\TGI while H:\tmp is the temp directory for 
downloaded packages.
I hope they don't interfere. I can try to put both on the same drive but 
I would be surprised if that makes a difference.

Thomas

network installation problems (again)

[Thomas Wolff]

Hi,
I am again having problems to install cygwin on a network drive. It's in 
the same network I had similar problems before:

http://cygwin.com/ml/cygwin-apps/2009-11/msg00034.html
which were then resolved after a while.
The client machines are now new, running Windows 7. Domain server is the 
old one.
My description log of actions and popup errors is attached below. There 
was no way to install on the network. I could install to the C: drive 
and move that over to the network where it would then run.


Kind regards,
Thomas

setup has not remembered the download server since previous failed attempt

While
Installing
_autorebase-001002-1
/etc/

---
File extraction error
---
Unable to extract /etc/ -- corrupt package?

---
OK
---

Clicking OK, while
Installing
_autorebase-001002-1
/etc/postinstall/

---
File extraction error
---
Unable to extract /etc/postinstall/ -- corrupt package?

---
OK
---

Clicking OK, while
Installing
_autorebase-001002-1
/etc/postinstall/0p_000_autorebase.dash

---
Error writing file
---
Unable to extract /etc/postinstall/0p_000_autorebase.dash

The file is in use or some other error occurred.

Please stop all Cygwin processes and select "Retry", or select "Continue" to go 
on anyway (the file will be updated after a reboot).

---
Wiederholen   Abbrechen
---

Clicking Continue, it hangs flickering at:

Installing
_autorebase-001002-1
/etc/postinstall/0p_000_autorebase.dash
---



If I select an existing directory as Local Package Directory:
---
Fehler
---
Directory H:\tmp does not exist, would you like me to create it?
---
Ja   Nein
---

Clicking Yes:
---
Cygwin Setup
---
Couldn't create directory H:\tmp, sorry.  (Is drive full or read-only?)
---
OK
---


Attempting a fresh install behaves similarly,
and doesn't even create the root directory.


Sometimes:
---
Cygwin Setup
---
Cannot open log file L:\TGI\cygwin/var/log/setup.log for writing
---
OK
---


Other issues on that machine:

$ unxz cygwin1-20151112.dll.xz
unxz: cygwin1-20151112.dll: Kann Datei Gruppe nicht setzen: Permission denied
unxz: cygwin1-20151112.dll: Kann Zugriffsrechte nicht setzen: Permission denied

$ ls -l mined.exe
-rwxrwx---+ 1 wolff Domänen-Benutzer 7490140 16. Nov 12:09 mined.exe
$ getfacl mined.exe
# file: mined.exe
# owner: wolff
# group: Domänen-Benutzer
user::rwx
group::---
group:SYSTEM:rwx
group:Administratoren:rwx
group:Mitarbeiter:rwx
mask:rwx
other:---
$ uname -a
CYGWIN_NT-6.1-WOW DSY30 2.0.4(0.287/5/3) 2015-06-09 12:20 i686 Cygwin
$ LC_ALL=C chmod u+x mined.exe
chmod: changing permissions of 'mined.exe': Permission denied

Re: [PATCH mintty] Add an XWin XDG menu entry

[Thomas Wolff]

On 08.07.2015 01:40, Michael DePaulo wrote:

On Tue, Jul 7, 2015 at 4:00 PM, Thomas Wolff t...@towo.net wrote:

Am 07.07.2015 um 13:47 schrieb Yaakov Selkowitz:

On Tue, 2015-07-07 at 11:47 +0200, Thomas Wolff wrote:

On 07.07.2015 01:12, Yaakov Selkowitz wrote:

---
Thomas, could you please ship a new release with this patch ASAP?

Are you sure this is desired? Mintty isn't related to X Windows;

Well, not for a full X desktop, and that's the reason for the
OnlyShowIn.  But within the context of a multiwindow session it makes
sense to provide this option.

OK, anyone else to approve this? Sorry I'm asking but some people might
think it's alien in an X menu.
(Would that addition actually pass without a mintty dependency on xdg?
Otherwise, since mintty is in cygwin-base, xdg itself could also include the
entry.)
Thomas

I think this makes sense because:
...
Convinced. According to 
file:///C:/cygwin/usr/share/doc/cygport/manual.html#robo164 ,
Categories and Additional_Fields parameters should be colon-separated, 
so I would put:
  make_desktop_entry mintty Cygwin Terminal utilities-terminal 
System:Terminal Emulator  OnlyShowIn=X-Cygwin
-- about the icon, shouldn't mintty's own icon be used here? How would 
it be passed to cygport, does it need to be installed first?

Thomas

Re: [PATCH mintty] Add an XWin XDG menu entry

[Thomas Wolff]

Am 07.07.2015 um 13:47 schrieb Yaakov Selkowitz:

On Tue, 2015-07-07 at 11:47 +0200, Thomas Wolff wrote:

On 07.07.2015 01:12, Yaakov Selkowitz wrote:

---
Thomas, could you please ship a new release with this patch ASAP?

Are you sure this is desired? Mintty isn't related to X Windows;

Well, not for a full X desktop, and that's the reason for the
OnlyShowIn.  But within the context of a multiwindow session it makes
sense to provide this option.
OK, anyone else to approve this? Sorry I'm asking but some people might 
think it's alien in an X menu.
(Would that addition actually pass without a mintty dependency on xdg? 
Otherwise, since mintty is in cygwin-base, xdg itself could also include 
the entry.)

Thomas

Re: [PATCH mintty] Add an XWin XDG menu entry

[Thomas Wolff]

On 07.07.2015 01:12, Yaakov Selkowitz wrote:

---
Thomas, could you please ship a new release with this patch ASAP?
Are you sure this is desired? Mintty isn't related to X Windows; it 
could be listed in its menu anyway, but... one more opinion?

Thomas

  cygwin/mintty.cygport | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/cygwin/mintty.cygport b/cygwin/mintty.cygport
index 35ee031..26f5423 100644
--- a/cygwin/mintty.cygport
+++ b/cygwin/mintty.cygport
@@ -32,4 +32,6 @@ src_install() {
doman docs/mintty.1
dodoc COPYING LICENSE.Oxygen LICENSE.PuTTY
dodoc cygwin/README cygwin/setup.hint
+
+  make_desktop_entry mintty Cygwin Terminal utilities-terminal System;TerminalEmulator 
 OnlyShowIn=X-Cygwin;
  }

Re: SSH key for upload access

[Thomas Wolff]

Am 29.03.2015 um 18:42 schrieb Achim Gratz:

Thomas Wolff writes:

Hmm, so why does lftp ask me for a password?

Because you get bumped to the SSH connection only after you've connected
via password-less login.

Thanks for the hint but I have no idea what that means. And I hope I
don't have to be a security expert just to upload a package.

Create the following bookmark in lftp (yes,
that colon after cygwin is important) to avoid the password prompt:

cygwin  sftp://cygwin:@cygwin.com

Again, thanks, but I don't want to dig into lftp configuration just to
upload my package.

Anyway, it has worked now with cygwin sftp after explicitly using the -i
option. (I had previously tried to upload from a Linux box.)

Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com

Re: SSH key for upload access

[Thomas Wolff]

Am 29.03.2015 um 15:43 schrieb Yaakov Selkowitz:

On Sun, 2015-03-29 at 13:22 +0200, t...@towo.net wrote:

Name: Thomas Wolff
Package: mined
 BEGIN SSH2 PUBLIC KEY 
Comment: 2048-bit RSA, converted from OpenSSH by root@MyBookLive
B3NzaC1yc2EBIwAAAQEAwMSnVCjNhyiGNhBC/+uPheB4BgG+n7RVmVMiBUJkIy
19fDeLc+0bWgzKLEXl00e0KytGgz6gS3sbDYfv8Ukh9eAnQ9iev31fZmb2UpmXtJCpQHrK
tT3kT3FME+sDX3zYCnpXyOGUP0v0DwUSbRdsMyzH3YKw8XJ60b2gi5PX1wTENR0L4fnXUr
+3Wya4jXUR5d5Az7/Yn9HrBc68qogHn+TwBFZUhXMtlcThKoRBA7160Td7sUeTc1FoqvlD
saneqqnZCgX0qhWZp9V+eNHMnMkNoSwhdDtM+7IRI0doTI7BlzLbiZp1mZOUNWDtdaZwIn
Jbtk5T/FDLw+VIQQWmcQ==
 END SSH2 PUBLIC KEY 

This key is already registered.

Hmm, so why does lftp ask me for a password?
And why does sftp silently crash after 2 seconds:
sftp cyg...@cygwin.com
Connecting to cygwin.com...
sftp dir
!packages  x86x86_64
sftp put x86/mined-2015.25-0.tar.xz x86/release/mined/
Uploading x86/mined-2015.25-0.tar.xz to
/x86/release/mined/mined-2015.25-0.tar.xz
x86/mined-2015.25-0.tar.xz  0%0 0.0KB/s   --:--
ETAConnection closed

Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com

Re: Updated: dialog-1.2-20150225-1

[Thomas Wolff]

On 03.03.2015 00:20, Yaakov Selkowitz wrote to cygwin-announce:

The following packages have been updated in the Cygwin distribution:

* dialog-1.2-20150225-1
* libdialog12-1.2-20150225-1
* libdialog-devel-1.2-20150225-1

Dialog is a script-interpreter which provides a set of widgets for
in-terminal dialogs.  Widgets are objects whose appearance and behavior
can be customized.


From the man page:

EXAMPLES
   The  dialog sources contain several samples of how to use the 
different
   box options and how they look.  Just take a  look  into the  
directory

   samples/ of the source.
This is not really helpful for a package. Examples should go into 
/usr/share/dialog, please.

--
Thomas

Re: [ANNOUNCEMENT] Updated: dialog-1.2-20150225-1

[Thomas Wolff]

Yaakov Selkowitz wrote to cygwin-announce:

The following packages have been updated in the Cygwin distribution:

* dialog-1.2-20150225-1
* libdialog12-1.2-20150225-1
* libdialog-devel-1.2-20150225-1

Dialog is a script-interpreter which provides a set of widgets for
in-terminal dialogs.  Widgets are objects whose appearance and behavior
can be customized.


From the man page:

EXAMPLES
   The  dialog sources contain several samples of how to use the
different
   box options and how they look.  Just take a  look  into the
directory
   samples/ of the source.

This is not really helpful for a package. Examples should go into
/usr/share/dialog, please.
--
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
http://www.avast.com

Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2

[Thomas Wolff]

On 26.02.2015 23:56, David Stacey wrote:

On 26/02/2015 11:58, Thomas Wolff wrote:

On 25.02.2015 21:34, David Stacey wrote:

On 25/02/2015 07:27, Thomas Wolff wrote:

Am 19.02.2015 um 00:05 schrieb David Stacey:

The following package has been updated in the Cygwin distribution:

* mscgen-0.20-2

Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.

This release has been built with libgd3 and three patches from 
Fedora.

Please rebuild the package with
configure --with-freetype
so the font selection option -F can be used.


I tried rebuilding with '--with-freetype'. mscgen builds but always 
exits with an error code. This is because gdImageStringFT() always 
returns the string 'Could not set character size'. By default, the 
code is trying to use the 'helvetica' font. I have a goodly 
selection of font packages installed. Any ideas?
I had similar problems until I found out how to configure fonts. This 
is very poorly documented.
With /etc/fonts/fonts.conf pointing to ~/.fonts, it is actually 
sufficient to link your font directory to ~/.fonts
and you can address all fonts contained therein (including 
subfolders) by their name like in

mscgen -T png -F Droid Sans


I'm not sure you need to edit /etc/fonts/fonts.conf.
No, because it already lists ~/.fonts which gives a user an easy 
opportunity to make his/her favourite fonts available without digging 
into fontconfig (if only this option were documented...).


By default, this includes /usr/share/fonts, so any font therein should 
be accessible to mscgen. You would only need to do this if you wanted 
to use fonts in non-standard locations - such as those from 
texlive-collection-fontsextra.


I wonder if this is a problem with font types? 'fc-match helvetica' 
matches a PCF font, and that might explain the error, if libgd3 is 
trying to scale a bitmap font. But a TrueType Font such as 'Luxi Sans' 
works. Should I just patch mscgen so that the default font is a 
TrueType font?

That might be a good idea.
Be sure to include a dependency to the font package you choose for default,
e.g. font-bh-ttf for Luxi Sans,
or font-bitstream-vera-ttf for Bitstream Vera Sans;
font-cantarell-otf for Cantarell is also a good choice.
(I'd suggest not to choose a default from a texlive font package because 
they are too big for a dependency.)

--
Thomas

Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2

[Thomas Wolff]

Am 26.02.2015 um 12:58 schrieb Thomas Wolff:

On 25.02.2015 21:34, David Stacey wrote:

On 25/02/2015 07:27, Thomas Wolff wrote:

Am 19.02.2015 um 00:05 schrieb David Stacey:

The following package has been updated in the Cygwin distribution:

* mscgen-0.20-2

Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.

This release has been built with libgd3 and three patches from Fedora.

Please rebuild the package with
configure --with-freetype
so the font selection option -F can be used.


I tried rebuilding with '--with-freetype'. mscgen builds but always 
exits with an error code. This is because gdImageStringFT() always 
returns the string 'Could not set character size'. By default, the 
code is trying to use the 'helvetica' font. I have a goodly selection 
of font packages installed. Any ideas?
I had similar problems until I found out how to configure fonts. This 
is very poorly documented.
With /etc/fonts/fonts.conf pointing to ~/.fonts, it is actually 
sufficient to link your font directory to ~/.fonts
and you can address all fonts contained therein (including subfolders) 
by their name like in

mscgen -T png -F Droid Sans

and with
fc-list :* family style
you can list all available fonts with the name and style properties that
work in mscgen -F, where only one of multiple style names shall be used:
mscgen -T png -F Comic Sans MS:style=Fett

A patch to include these hints in the manual page would be good, the 
upstream project does not seem to be active.

--
Thomas

Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2

[Thomas Wolff]

On 25.02.2015 21:34, David Stacey wrote:

On 25/02/2015 07:27, Thomas Wolff wrote:

Am 19.02.2015 um 00:05 schrieb David Stacey:

The following package has been updated in the Cygwin distribution:

* mscgen-0.20-2

Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.

This release has been built with libgd3 and three patches from Fedora.

Please rebuild the package with
configure --with-freetype
so the font selection option -F can be used.


I tried rebuilding with '--with-freetype'. mscgen builds but always 
exits with an error code. This is because gdImageStringFT() always 
returns the string 'Could not set character size'. By default, the 
code is trying to use the 'helvetica' font. I have a goodly selection 
of font packages installed. Any ideas?
I had similar problems until I found out how to configure fonts. This is 
very poorly documented.
With /etc/fonts/fonts.conf pointing to ~/.fonts, it is actually 
sufficient to link your font directory to ~/.fonts
and you can address all fonts contained therein (including subfolders) 
by their name like in

mscgen -T png -F Droid Sans

(Somehow by removing this font configuration, I cannot reproduce the 
'Could not set...' errors anymore I had yesterday - weird.)

--
Thomas

Re: [ANNOUNCEMENT] Updated: mscgen-0.20-2

[Thomas Wolff]

Am 19.02.2015 um 00:05 schrieb David Stacey:

The following package has been updated in the Cygwin distribution:

* mscgen-0.20-2

Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.

This release has been built with libgd3 and three patches from Fedora.

Please rebuild the package with
configure --with-freetype
so the font selection option -F can be used.
--
Thomas

Re: HEADSUP MAINTAINERS: flat upload layout

[Thomas Wolff]

Am 15.08.2014 19:21, schrieb Yaakov Selkowitz:

On Tue, 2014-08-12 at 10:59 +0200, Corinna Vinschen wrote:

On Aug 12 09:45, Thomas Wolff wrote:

While revising the upload structure, please consider folding out the source
package (e.g. into no-arch/ or src/) because it's not a convincing burden to
have to upload the same package twice.

Yes, that's something we should certainly contemplate medium-term.

upset doesn't like having the same package in multiple locations, so I'm
not sure if the -src packages can be separate.

?? This doesn't seem to address what I was suggesting.
Right now, the srce packages for x86 and x86_64 *have* to be separate, 
although they are identical.
And the simple ftp server doesn't even support the ln (hard link) option 
that sftp and lftp provide,
much to my annoyance when I first uploaded a new package myself and 
wanted to optimise the procedure, considering my slow upload link (of a 
typical asymmetric subscriber line, maybe you have different access in 
your country and don't care...).

Thomas


However, what I did suggest earlier was to have a separate
noarch/release hierarchy for entirely noarch packages, which would
prevent having to upload noarch twice:

http://www.cygwin.com/ml/cygwin-apps/2013-03/msg00126.html

I do this with Ports and it works quite well, but then again I'm the
only one uploading there.


Yaakov





---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com

Re: HEADSUP MAINTAINERS: flat upload layout

[Thomas Wolff]

Am 12.08.2014 01:45, schrieb Yaakov Selkowitz:
In order to better manage upload permissions, effective immediately, 
each and every current primary/source package has its own directory 
directly underneath $arch/release.  Those packages that were 
previously nested have been moved accordingly, for example:


x86/release/db/*
x86/release/singular/*
$arch/release/ghostscript/ghostscript-fonts-*/
...

So please remember when you upload from now on, all packages go 
straight into $arch/release/.
While revising the upload structure, please consider folding out the 
source package (e.g. into no-arch/ or src/) because it's not a 
convincing burden to have to upload the same package twice.

Thanks
Thomas

Re: [ATTN maintainer] mined

[Thomas Wolff]

Am 18.07.2014 06:39, schrieb Achim Gratz:

The mined directory for both architectures contain temporary files that
apparently sftp has left there (they have the suffix SftpXFR.PID I
think).  These should be removed, but maybe the transfer script that
moves the files from the upload area could be extended to ignore or
delete such files so they never get distributed to the mirrors.
I had some troubles during my first upload attempts with sftp. I will 
report on details later (after holidays...).

Thomas

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com

SSH key for upload access

[Thomas Wolff]

Name: Thomas Wolff
Package: mined
 BEGIN SSH2 PUBLIC KEY 
Comment: 2048-bit RSA, converted by demsn702@3T29LQ1 from OpenSSH
B3NzaC1yc2EDAQABAAABAQCeec0gY9huCNMQkWo1x74lqS+YjKXYC/SNHGaEYE
I4u2+ZuDCNeP4Ednvs+E0gpJ8ilEcJMP0MYsnJvngRkQTC9fY++f0XU1cUpJKYwcIFap0I
91XYXJMC4B/qVCzmq7CWUwwZ1GRsblRBpoCXQdOt4vziT43eqXOBQe+vxF1vnRndjCgBmh
8pxx8VaRB7dVX+ctsxFQDJiyg5gfvRautpUU0hZy0MmNsPxf8GXdnsbnDHo8LCLMRZ/MOE
VHWG2DSGPrO2nm3jUwQbj+VddCcR9j2KbGNOw/yq7QpxDNdIlXUJRa5/J195BgVZthLKWw
QaAP8ShJYGHCWlNlJzfVSl
 END SSH2 PUBLIC KEY 

Re: Please upload: mined-2014.24-0

[Thomas Wolff]

On 07.06.2014 01:58, Yaakov Selkowitz wrote:

On 2014-06-06 18:24, Thomas Wolff wrote:

Am 06.06.2014 20:18, schrieb Yaakov Selkowitz:

On 2014-06-06 13:00, Thomas Wolff wrote:

Please upload the release update package for mined:


Please note that we have a new upload system:

https://sourceware.org/cygwin-apps/package-upload.html

Thanks, Yaakov; another few question not (yet) in the FAQ:

- After sending an (updated) SSH key, how long would I have to wait 
until access works? (The howto says it's handled automatically but it 
doesn't work after 15 min).


- How could access from different machines be set up? (which would 
typically generate unique keys...)


- Why is the identical src package expected to appear twice in different 
directories? (I hope the hard link option of sftp is supported - once it 
works - so at least upload can be shortcut but still..)


Thanks
Thomas

SSH key for upload access

[Thomas Wolff]

Name: Thomas Wolff
Package: mined
 BEGIN SSH2 PUBLIC KEY 
Comment: 2048-bit RSA, converted from OpenSSH by root@MyBookLive
B3NzaC1yc2EBIwAAAQEAwMSnVCjNhyiGNhBC/+uPheB4BgG+n7RVmVMiBUJkIy
19fDeLc+0bWgzKLEXl00e0KytGgz6gS3sbDYfv8Ukh9eAnQ9iev31fZmb2UpmXtJCpQHrK
tT3kT3FME+sDX3zYCnpXyOGUP0v0DwUSbRdsMyzH3YKw8XJ60b2gi5PX1wTENR0L4fnXUr
+3Wya4jXUR5d5Az7/Yn9HrBc68qogHn+TwBFZUhXMtlcThKoRBA7160Td7sUeTc1FoqvlD
saneqqnZCgX0qhWZp9V+eNHMnMkNoSwhdDtM+7IRI0doTI7BlzLbiZp1mZOUNWDtdaZwIn
Jbtk5T/FDLw+VIQQWmcQ==
 END SSH2 PUBLIC KEY 

Re: Please upload: mined-2014.24-0

[Thomas Wolff]

Am 10.06.2014 20:25, schrieb Yaakov Selkowitz:

On 2014-06-10 06:46, Thomas Wolff wrote:

On 07.06.2014 01:58, Yaakov Selkowitz wrote:

Please note that we have a new upload system:

https://sourceware.org/cygwin-apps/package-upload.html

Thanks, Yaakov; another few question not (yet) in the FAQ:

- After sending an (updated) SSH key, how long would I have to wait
until access works? (The howto says it's handled automatically but it
doesn't work after 15 min).


This is actually what it says:


Requests are handled manually and are acknowledged publicly in response
to email to the cygwin-apps mailing list.


When you see that ack, then you may upload.
Ah, I was confused by the sentence two paragraphs above It is read by a 
program... so I thought it was fully automatic, sorry. So I'll be 
patient...

Thanks, Thomas

Please upload: mined-2014.24-0

[Thomas Wolff]

Please upload the release update package for mined:


# setup
wget http://towo.net/mined/cygwin/setup.hint

# cygport
wget http://towo.net/mined/cygwin/mined.cygport
# or
wget http://towo.net/mined/cygwin/mined-2014.24-0.cygport

# src
wget http://towo.net/mined/cygwin/mined-2014.24-0-src.tar.bz2

# bin 32 bit
wget http://towo.net/mined/cygwin/32/mined-2014.24-0.tar.bz2
# bin 64 bit
wget http://towo.net/mined/cygwin/64/mined-2014.24-0.tar.bz2


Thank you,
Thomas Wolff