Re: Webkitgtk maintenance

2023-09-12 Thread Yaakov Selkowitz via Cygwin-apps 
Please see: https://cygwin.com/problems.html#personal-email

This applies doubly so to former maintainers.  Redirecting to cygwin-
apps.

On Tue, 2023-09-12 at 17:11 +0200, Blandin Jean-Marie wrote:
> Dear Mr Selkowitz,
> 
> First of all, I want to apologize for the time I take from you by
> writing
> this email.
> It's about the cygwin package I put as object of this email which has
> been
> orphaned for many years.
> The fact is other packages depend on it : I'm used to programming in
> gambas3 language and as the cygwin maintainer of this package told
> me, he
> cannot update his part as long as the webkitgtk package is not
> recent.
> For sure I can imagine the large amount of time it takes to maintain
> a
> cygwin package but it is the only way AFAIK to use Linux apps on
> windows
> without admin rights.
> You seemed to step back from webkitgtk maintenance a few years ago
> and I
> would be very glad if you could tell a name to follow on because of
> the
> importance for the gambas3 community on windows.

I did not find any such discussion on the lists, so I don't know
exactly what was said.  Therefore, I'll give you as much background as
I can.

Even while I was still maintaining webkitgtk, I was stuck with what
became even then a very old version.  The reason for this is the
upstream migration to WebKit2:

https://trac.webkit.org/wiki/WebKit2

In order to support the then-new split-process model (which we now all
take for granted in browsers and browser engines), there needs to be
some form of IPC between the UI process and web process.  In WebKit2 on
*NIX this was done in a way that involved passing file descriptors over
a unix socket, which Cygwin never supported.  As such, once webkitgtk
completed its migration to WebKit2, I was unable to further update the
package.

(For a similar reason, it became impossible for anyone to update mingw-
webkitgtk in any distro because a Windows counterpart implementation to
that IPC was either never developed or just not integrated into
webkitgtk.  With Apple abandoning Safari on Windows, and Qt migrating
from QtWebKit to QtWebEngine (which is based on Chromium), there
doesn't seem to be any commercial interest in maintaining WebKit2 for
Windows.)

Therefore, this issue is currently CANTFIX until Cygwin gains support
for passing file descriptors over unix sockets (in a Linux-compatible
way), at which point a new maintainer could theoretically then try to
port a current webkitgtk version to Cygwin.  I sincerely wish luck to
whomever tries to tackle this, as it will likely be no small feat.

HTH,

-- 
Yaakov

Re: [ITP] openh264 (2.3.1)

2023-02-09 Thread Yaakov Selkowitz via Cygwin-apps 
On Mon, 2023-02-06 at 14:25 +0900, Takashi Yano via Cygwin-apps wrote:
> On Mon, 06 Feb 2023 00:16:45 -0500
> Yaakov Selkowitz via Cygwin-apps  wrote:
> 
> > On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
> > > On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
> > > > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
> > > > > I would like to propose new package openh264, which is
> > > > > a H264 video codec library. This is needed by ffmpeg
> > > > > package I had proposed, and also provided for ffmpeg-free
> > > > > package in fedora.
> > > > > 
> > > > > I already prepared the package at the following location.
> > > > > 
> > > > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
> > > 
> > > > Unfortunately, this cannot be included in the Cygwin distribution. 
> > > > Cisco's
> > > > patent license only covers binaries they distribute.  Fedora has a
> > > > special
> > > > arrangement with Cisco where they build their RPMs on Fedora
> > > > infrastructure,
> > > > but the packages are hosted by Cisco in a separate repository.
> > > 
> > > http://www.openh264.org/
> > > "Cisco has taken their H.264 implementation, and open sourced it under
> > > BSD 
> > > license terms. Development and maintenance will be overseen by a board
> > > from 
> > > industry and the open source community. Furthermore, we have provided a
> > > binary 
> > > form suitable for inclusion in applications across a number of different
> > > operating systems, and make this binary module available for download
> > > from
> > > the 
> > > Internet. We will not pass on our MPEG-LA licensing costs for this
> > > module,
> > > and 
> > > based on the current licensing environment, this will effectively make
> > > H.264
> > > free for use on supported platforms."
> > 
> > This is exactly the point.  Cisco paid for a license, but that license is
> > limited to binaries they distribute.  Unfortunately, I doubt that Cisco
> > will
> > do the same for Cygwin.
> 
> OK. How about distributing only headers as cygwin package
> for building ffmpeg?

The Fedora package includes openh264 headers and a patch which will dlopen()
libopenh264 if present.  These could be used (with the modification
libopenh264.so.N -> cygopenh264-N.dll of course) in the Cygwin package.

-- 
Yaakov

Re: [ITP] openh264 (2.3.1)

2023-02-05 Thread Yaakov Selkowitz via Cygwin-apps 
On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote:
> On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote:
> > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
> > > I would like to propose new package openh264, which is
> > > a H264 video codec library. This is needed by ffmpeg
> > > package I had proposed, and also provided for ffmpeg-free
> > > package in fedora.
> > > 
> > > I already prepared the package at the following location.
> > > 
> > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/
> 
> > Unfortunately, this cannot be included in the Cygwin distribution. 
> > Cisco's
> > patent license only covers binaries they distribute.  Fedora has a special
> > arrangement with Cisco where they build their RPMs on Fedora
> > infrastructure,
> > but the packages are hosted by Cisco in a separate repository.
> 
> http://www.openh264.org/
> "Cisco has taken their H.264 implementation, and open sourced it under BSD 
> license terms. Development and maintenance will be overseen by a board from 
> industry and the open source community. Furthermore, we have provided a
> binary 
> form suitable for inclusion in applications across a number of different 
> operating systems, and make this binary module available for download from
> the 
> Internet. We will not pass on our MPEG-LA licensing costs for this module,
> and 
> based on the current licensing environment, this will effectively make H.264
> free for use on supported platforms."

This is exactly the point.  Cisco paid for a license, but that license is
limited to binaries they distribute.  Unfortunately, I doubt that Cisco will
do the same for Cygwin.

-- 
Yaakov

Re: [ITP] faad2 (2.8.8)

2023-02-05 Thread Yaakov Selkowitz via Cygwin-apps 
On Sun, 2023-02-05 at 22:04 -0700, Brian Inglis wrote:
> On 2023-02-05 19:46, Yaakov Selkowitz via Cygwin-apps wrote:
> > On Fri, 2023-01-20 at 19:36 +0900, Takashi Yano via Cygwin-apps wrote:
> > > I would like to propose a new package FAAD2 which is
> > > a decoder library for AAC audio codec. This package
> > > is needed by the new package moc I have proposed at
> > > the same time. I have already prepared the package at:
> > > 
> > > https://tyan0.yr32.net/cygwin/x86_64/release/faad2/
> > 
> > Unfortunately, this cannot be included in the Cygwin distribution.
> 
> These packages are now GPL and available from Arch, Debian main repo, *BSD 
> ports, OpenSuSE, Slack, and more, so there may have been issues with 
> non-relocatable non-PIC assembler code, patents now
> expired/lapsed/challenged, 
> VideoLan or alternative commercial licensing, for example no commercial use 
> restrictions?
> Many codecs like these can be installed on Fedora, etc. from RPMfusion, 
> UnitedRPMs, or other repos.

Anything blocked from Fedora itself for legal reasons cannot be part of Cygwin
either.  Its inclusion in any other distro or repo is insufficient.

-- 
Yaakov

Re: [ITP] openh264 (2.3.1)

2023-02-05 Thread Yaakov Selkowitz via Cygwin-apps 
On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote:
> I would like to propose new package openh264, which is
> a H264 video codec library. This is needed by ffmpeg
> package I had proposed, and also provided for ffmpeg-free
> package in fedora.
> 
> I already prepared the package at the following location.
> 
> https://tyan0.yr32.net/cygwin/x86_64/release/openh264/

Unfortunately, this cannot be included in the Cygwin distribution.  Cisco's
patent license only covers binaries they distribute.  Fedora has a special
arrangement with Cisco where they build their RPMs on Fedora infrastructure,
but the packages are hosted by Cisco in a separate repository.

-- 
Yaakov

Re: [ITP] faad2 (2.8.8)

2023-02-05 Thread Yaakov Selkowitz via Cygwin-apps 
On Fri, 2023-01-20 at 19:36 +0900, Takashi Yano via Cygwin-apps wrote:
> I would like to propose a new package FAAD2 which is
> a decoder library for AAC audio codec. This package
> is needed by the new package moc I have proposed at
> the same time. I have already prepared the package at:
> 
> https://tyan0.yr32.net/cygwin/x86_64/release/faad2/

Unfortunately, this cannot be included in the Cygwin distribution.

-- 
Yaakov

Re: gnulib m4/threadlib.m4 bug crashing package tests

2021-11-25 Thread Yaakov Selkowitz via Cygwin-apps 
On Thu, 2021-11-25 at 11:26 -0500, Ken Brown via Cygwin-apps wrote:
> On 9/29/2021 7:46 PM, Brian Inglis wrote:
> > There is a gnulib bug in threadlib.m4 from at least serial 29 to serial
> > 31 that incorrectly configures Cygwin support of weak references.
> > 
> > This leads to SIGSEGV stack smashing crashes with no backtrace
> > @ 0x1 or 0x0005 etc. normally during tests.
> > 
> > Akim Demaille on bug-bison referred the issue to bug-gnulib where
> > Bruno Haible diagnosed and patched the problem to appear in
> > m4/threadlib.m4 serial 32:
> > 
> > * m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on
> > Cygwin
> > https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html
> > [gl_cv_have_weak="guessing no"]
> > 
> > The patch has now been applied to bison, wget, and wget2, and I have
> > attached my patches for the copies in those packages, in case anyone
> > else has this issue in their (mainly GNU) packages which may incorporate
> > by 
> > inclusion recently updated gnulib m4 macros used in autotools builds.
> 
> Thanks, Brian.
> 
> I'm writing to reinforce this warning.  I just spent 2 days trying to debug 
> mysterious texinfo crashes that were caused by this bug.  I could have saved
> a 
> lot of time if I had remembered your email and had checked the gnulib
> version 
> being used by texinfo.
> 
> For anyone else who bumps into this, gdb and strace are of no use in
> debugging 
> this crash.  I finally thought to look at the stackdump file, and the second
> address from the top was in a gnulib file.  That was the key clue.

Add gl_cv_have_weak=no to cygconf?

-- 
Yaakov

Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg

2021-10-01 Thread Yaakov Selkowitz via Cygwin-apps 
On Wed, 2021-09-29 at 22:15 -0600, Brian Inglis wrote:
> Hi folks,
> 
> Autotools needs m4 macros in autoreconf-archive to config for gcov and 
> other dependencies or build fails with e.g.
> 
> "configure.ac:33: error: possibly undefined macro: AX_CODE_COVERAGE
>     If this token and others are legitimate, please use m4_pattern_allow.
>     See the Autoconf documentation."
> 
> CI scallywag setup does not install nor does cygport nor autoconf 
> require autoconf-archive so packages have to include in BUILD_REQUIRES.
> 
> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that 
> would be the more appropriate place for an autoconf-archive requirement, 
> otherwise cygport would have to require it, which is not so obvious.

autoconf-archive would be a build requirement of the package whose
configure.ac references the AX_* macro, not of the autotools themselves.

-- 
Yaakov

-- 
Yaakov

Re: github password policy

2021-08-16 Thread 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.

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.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

Re: [PATCH cygport] Update xorg.cygclass URLs [GOLDSTAR]

2021-04-05 Thread Yaakov Selkowitz via Cygwin-apps 
On Tue, 2021-01-05 at 15:06 +0100, Achim Gratz wrote:
> Yaakov Selkowitz via Cygwin-apps writes:
> > In fact, there are probably a bunch of other http: which could be
> > converted to https: at this point.  I would suggest anyone who does
> > that (in separate commit(s)) should get a gold star.
> 
> The patch series from Lem plus another handful of cleanups is available
> at:
> 
> https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/URL-updates

Thank you Lem for the patches, and Achim for gathering them together on a
branch.  It was surely tedious work, but necessary and much appreciated. 
These are (finally!) merged, can we get some gold stars please?

-- 
Yaakov

Re: [ANNOUNCEMENT] Updated: python packages

2021-02-09 Thread Yaakov Selkowitz via Cygwin 
On Tue, 2021-02-09 at 21:31 +, Jon Turney wrote:
> On 22/01/2021 21:37, Marco Atzeri via Cygwin-announce via Cygwin wrote:
> > Several python packages have been promoted from test to stable
> > 
> [...]
> > python{36,37,38}-lxml-4.6.2-1
> 
> Marco,
> 
> I noticed something a bit odd, which I'm not sure is expected or not.
> 
> If I install 'python3-lxml', I get 'python36-lxml', which doesn't do me 
> much good with 'python3' installed (which gets me python3.8 currently).

When I changed the packaging scheme from pythonX-* to pythonXY-*, 3.6 was the
"3" version at the time, and the python3-* created alongside python36-* were
only meant to be upgrade helpers from that point forward.

-- 
Yaakov

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: dblatex needs update

2021-02-03 Thread Yaakov Selkowitz via Cygwin-apps 
On Wed, 2021-02-03 at 16:49 -0500, Ken Brown via Cygwin-apps wrote:
> dblatex (still shown as maintained by Yaakov) is currently broken because it
> was built for python2 but its shebang points to python.
> 
> I could do a quick non-maintainer upload to fix the shebang, but maybe
> someone wants to adopt it and rebuild it for python3.

Please note that the version currently in Cygwin is not Py3 compatible; the
latest upstream version should be though.

-- 
Yaakov

Re: [PATCH cygport] Update xorg.cygclass URLs

2020-12-02 Thread Yaakov Selkowitz via Cygwin-apps 
On Tue, 2020-12-01 at 15:47 +, Jon Turney wrote:
> Update xorg.cygclass URLs since xorg.freedesktop.org now permanently
> redirects to www.x.org
> ---
>  cygclass/xorg.cygclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thanks, comments inline.

> diff --git a/cygclass/xorg.cygclass b/cygclass/xorg.cygclass
> index 47686e8..1665439 100644
> --- a/cygclass/xorg.cygclass
> +++ b/cygclass/xorg.cygclass
> @@ -141,13 +141,13 @@ SUMMARY="X.Org ${ORIG_PN} component"
>  #
>  #o* xorg.cygclass/HOMEPAGE (xorg)
>  #  DEFINITION
> -HOMEPAGE="http://xorg.freedesktop.org/;
> +HOMEPAGE="https://www.x.org/;

OK.

>  #
>  #o* xorg.cygclass/SRC_URI (xorg)
>  #  DESCRIPTION
>  #  Download location of the release tarball.
>  #
> -SRC_URI="http://xorg.freedesktop.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.bz2;
> +SRC_URI="http://www.x.org/releases/individual/${xorg_cat}/${ORIG_PN}-${PV}.tar.bz2;
^^^
https://

With that change, please proceed.

In fact, there are probably a bunch of other http: which could be
converted to https: at this point.  I would suggest anyone who does
that (in separate commit(s)) should get a gold star.

-- 
Yaakov

Re: [PATCH] Use automake (v3)

2020-12-02 Thread Yaakov Selkowitz via Cygwin-patches 
On Wed, 2020-12-02 at 18:03 +, Jon Turney wrote:
> On 02/12/2020 17:05, Corinna Vinschen via Cygwin-patches wrote:
> > On Dec  2 15:36, Jon Turney wrote:
> > > On 01/12/2020 09:18, Corinna Vinschen wrote:
> > > > What bugs me is that the mingw executables are built in
> > > > utils/mingw,
> > > > but the object files are still in utils.  Any problem
> > > > generating the
> > > > object files in utils/mingw, too?
> > > 
> > > Not easily.
> > > 
> > > This behaviour can be turned off by not using the 'subdir-
> > > objects' automake
> > > option.
> > > 
> > > But then automake warns that option is disabled (since it's going
> > > to be the
> > > default in future).
> > 
> > So why not just move the mingw source files to utils/mingw, too?
> 
> There's probably some scope for doing that, but not in all cases, as 
> some files are built multiple times with different compilers and/or
> flags.
> 
> e.g. path.cc is built with a cygwin compiler and -DFSTAB as part of 
> mount, with a MinGW compiler as part of cygcheck, and with a MinGW 
> compiler and -DTESTSUITE as part of path-testsuite.

Then something like:

$ cat > winsup/utils/mingw/path.cc <<_EOF
#define MINGW // whatever is needed here...
#include "../path.cc"
_EOF

??

-- 
Yaakov

Re: Request for review: anthy 9100h+0.4 (Re: Update of packages by non-maintainer)

2020-06-03 Thread Yaakov Selkowitz via Cygwin-apps 
On Thu, 2020-06-04 at 01:20 +0900, Yasuhiro KIMURA wrote:
> From: Yasuhiro KIMURA 
> > So I gave up to use override.hint and decided to change version number
> > to "9100h+0.4". It works fine with all of cygport, mksetupini and
> > setup-x86_64.
> 
> Anyway version number issue has sloved. So I would like to request for
> review of anthy 9100h+0.4.

Not ready yet; see comments inline.

> * As for cygwin local patch, 9100h-no-undefined.patch is changed to
>   make it fit to new source tree. Others are removed.
[snip]
> * Add "MAKEOPTS=-j1" because parallel make causes build error.

That's the whole purpose of the exeext patch, to fix parallel make. 
Before you remove patches, you first need to understand what the patch
does, why it was needed, and see if it still is or not.  If you don't
know, then you should be asking rather than just dropping them.

> PKG_NAMES="${NAME} lib${NAME}0 lib${NAME}-common lib${NAME}-devel 
> emacs-${NAME}"
[snip]
> libanthy0_REQUIRES="libanthy-common"
> libanthy0_CONTENTS="usr/bin/cyganthy*.dll"

This is wrong; most of the DLLs will be -1.dll, so this needs to be
libanthy1 (but see below!!).

> 9100h-no-undefined.patch:

This looks mostly fine, except:

> --- origsrc/anthy-0.4/src-util/Makefile.am  2019-07-05 11:37:13.0 
> +0900
> +++ src/anthy-0.4/src-util/Makefile.am  2020-05-23 00:59:26.155191100 +0900
> @@ -26,5 +26,6 @@
>  libanthyinput_la_SOURCES = input.c rkconv.c rkhelper.c\
>   rkconv.h rkmap.h rkhelper.h
>  libanthyinput_la_LIBADD = ../src-main/libanthy.la
> +libanthyinput_la_LDFLAGS = -no-undefined
>  
>  pkgdata_DATA = typetab dic-tool-usage.txt

This should probably have -version-info flag as well upstream,
otherwise you'll have conflicts with libanthy0 and libanthy1.  

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

Re: [PATCH] cygwin: doc: Add keywords for ACE order issues

2020-05-12 Thread Yaakov Selkowitz via Cygwin-patches 
On Tue, 2020-05-12 at 22:49 +0200, David Macek via Cygwin-patches
wrote:
> Windows Explorer shows a warning with Cygwin-created DACLs, but putting
> the text of the warning into Google doesn't lead to the relevant Cygwin
> docs.  Let's copy the warning text into the docs in the hopes of helping
> confused users.
> 
> Latest inquiry: 
> 
> Signed-off-by: David Macek 
> ---
>  winsup/doc/ntsec.xml | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/winsup/doc/ntsec.xml b/winsup/doc/ntsec.xml
> index 08a33bdc6c..b94cdd9a97 100644
> --- a/winsup/doc/ntsec.xml
> +++ b/winsup/doc/ntsec.xml
> @@ -2163,7 +2163,10 @@ preferred order.
>  the Windows Explorer insists to rearrange the order of the ACEs to
>  canonical order before you can read them. Thank God, the sort order
>  remains unchanged if one presses the Cancel button.  But don't even
> -think of pressing OK...
> +think of pressing OK...  For the sake
> +of people searching for this explanation, let's note that the Explorer
> +warning says "The permissions on ... are incorrectly orderer, which may
> +cause some entries to be ineffective."
>  
>  Canonical ACLs are unable to reflect each possible combination
>  of POSIX permissions. Example:

The wording seems awkward.  Why not quote the text of the warning
directly earlier in the paragraph, e.g.:

Unfortunately, the security tab in the file properties dialog of
the Windows Explorer will pop up a warning stating: "The permissions on
... are incorrectly ordered, which may cause some entries to be
ineffective."  Pressing the Cancel button will leave the order
unchanged, but pressing OK will cause Windows to canonicalize the order
of the ACEs, thereby invalidating POSIX compatibility.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

Re: [PATCH cygport 0/2] Add provides: and conflicts:

2020-04-06 Thread Yaakov Selkowitz via Cygwin-apps 
On Sun, 2020-04-05 at 15:17 +0100, Jon Turney wrote:
> It seems I missed updating the check that all the expected package files 
> exist for source package hints.
> 
> Patch attached (without this upload isn't permitted when there's no 
> pvr.tar.xz, as no corresponding hint exists, only pvr-src.tar.xz and 
> it's hint).

Thanks, pushed to master.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

[PATCH htdocs] Move Yaakov to inactive status

2020-03-20 Thread Yaakov Selkowitz via Cygwin-apps 
Signed-off-by: Yaakov Selkowitz 
---
 donations.html  | 13 -
 faq/faq.html|  4 
 who.html|  5 -
 xfree/contributors.html |  9 -
 4 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/donations.html b/donations.html
index 9c80e026..7dbf7ed5 100755
--- a/donations.html
+++ b/donations.html
@@ -54,19 +54,6 @@ who work on the Cygwin DLL itself.
 google ranking vultures.
   
 
-Yaakov Selkowitz
-
-https://www.paypal.com/cgi-bin/webscr; method="post" 
target="_top">
-
-
-https://www.paypalobjects.com/en_US/i/btn/btn_donate_SM.gif; border="0" 
name="submit" alt="PayPal - The safer, easier way to pay online!">
-https://www.paypalobjects.com/en_US/i/scr/pixel.gif; width="1" height="1">
-
-
-The dedicated package maintainer of many Cygwin packages and author of the 
cygport packaging tool.
-Donations are accepted in CAD; please note the https://www.google.ca/search?q=USD+200+in+CAD;>current exchange rates.
-
-
 Jon Turney
 
 https://www.paypal.com/cgi-bin/webscr; method="post">
diff --git a/faq/faq.html b/faq/faq.html
index 3a56375c..5c373b5d 100644
--- a/faq/faq.html
+++ b/faq/faq.html
@@ -79,10 +79,6 @@ Corinna Vinschen is the current project lead. Corinna is a 
senior Red Hat
 engineer. Corinna is responsible for the Cygwin library and maintains a couple
 of packages, for instance OpenSSH, OpenSSL, and a lot more.
 
-Yaakov Selkowitz is another Red Hat engineer working on the Cygwin project.
-He's the guy behind the current build and packaging system and maintains by
-far the most packages in the Cygwin distribution.
-
 Jon Turney is developer and maintainer of the Cygwin X server and a couple
 of related packages.
 
diff --git a/who.html b/who.html
index 6bda6526..39d879bd 100755
--- a/who.html
+++ b/who.html
@@ -26,11 +26,6 @@ Corinna is a senior https://www.redhat.com/;>Red 
Hat engineer.
 Corinna is responsible for such important subsystems as security,
 networking, and internationalization.
 
-Yaakov Selkowitz maintains a large number of Cygwin packages, and
-is the primary author of the cygport packaging tool.
-Yaakov is also a http://x.cygwin.com/;>Cygwin/X
-lead.
-
 Jon Turney is a project lead for http://x.cygwin.com/;>Cygwin/X
 and is responsible for improvements to the X server.
 He has also contributed several improvements to setup.
diff --git a/xfree/contributors.html b/xfree/contributors.html
index 31fc6efe..090dfc0e 100755
--- a/xfree/contributors.html
+++ b/xfree/contributors.html
@@ -29,11 +29,6 @@
 
 
 
-
-   http://sourceware.org/cygwinports/;>Yaakov
-   Selkowitz (project leader, release 
manager)
-   
-
 
http://www.dronecode.org.uk;>Jon 
Turney (XWin developer)

@@ -133,6 +128,10 @@
 Benjamin Riefenstahl (icon work)
 
 
+
+   Yaakov Selkowitz (project leader, release manager)
+   
+
 
 Suhaib M. Siddiqi (creator and original leader
 of the project)
-- 
2.24.1