RE: Dropping various support in future releases - what about Mingw?
> -Original Message- > From: Brian Inglis > Sent: Sunday, October 31, 2021 11:23 AM > > Perhaps someone could explain why Cygwin maintains, builds, and > distributes Mingw tools and libraries, instead of that being done by the > Mingw project(s) about which I know little? > > As we will be dropping Windows versions and 32 bit support in future > releases, should we also be looking at dropping the Mingw packages we > maintain, build, and distribute, but do not appear to use, except for > building other Mingw packages? > > Supporting the two Mingw variations on packages sometimes takes as much > work as the Cygwin packages, as parts of the toolchains and libraries > may have different versions and dependencies. > > I basically build, check, and distribute those, but know little about > using them to check they work, so no idea whether they work or not. > > I have had little success in getting the Mingw dual arch build process > working to any useful extent, and no response to questions about that, > which I may have buried at the end of my other verbiage on this list. Kyle, Thoughts? > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in binary units and prefixes, physical quantities in SI.] -- Jason Pyeron | Architect PD Inc| Certified SBA 8(a) 10 w 24th St | Certified SBA HUBZone Baltimore, MD | CAGE Code: 1WVR6 .mil: jason.j.pyeron@mail.mil .com: jpye...@pdinc.us tel : 202-741-9397
Re: [ATTN MAINTAINERS] OpenSSL 1.0 dependencies
Andrew Schulman via Cygwin-apps writes: > Are you sure about lftp? AFAIK it only uses libssl1.1: It's a false positivie due to a previous version still using libopenssl100. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: cmus
On 31/10/2021 16.29, Jon Turney wrote:
On 23/10/2021 19:01, Federico Kircheis via Cygwin-apps wrote:
On 23/10/2021 17.39, Oliver Schoede wrote:
On Fri, 22 Oct 2021 15:06:46 +0200
Federico Kircheis via Cygwin-apps
wrote:
Hello to everyone,
I'm interested in becoming a package maintainer for the program cmus.
Very cool! My go-to music player, been using it for years, also in
Cygwin. ;) It's actually one of the reasons I started using it, knew it
from Linux and there being no port, building it on Windows turned out
easier in Cygwin. There was no WSL yet. An actual package is another
story of course, but if there's a problem and I could possibly be of any
help feel free to ask.
Looks like you appended the wrong .hint file.
Best regards,
Oliver
Let me try it again with the attachment...
Cool to know I'm not the only one using it under Windows :)
I did not notice any issue, but I'm just a casual user, thank you for
proposing to help, I'll keep it in mind ;)
Thanks.
I've added 'cmus' to your list of packages.
A few small comments on the cygport:
# cmus.cygport
NAME="cmus"
VERSION=2.9.1
TAG=2.9.1
Why not just use ${VERSION} throughout?
Good point
RELEASE=1
SUMMARY="cmus is a small, fast and powerful console music player for
Unix-like operating systems."
DESCRIPTION="cmus is a lightweight ncurses music player. It supports
various output methods by using dynamically-loaded output plugins."
CATEGORY="Audio"
HOMEPAGE="https://cmus.github.io/;
SRC_URI="https://github.com/cmus/cmus/archive/v${TAG}.tar.gz;
SRC_DIR="cmus-${TAG}"
DEPEND="libncurses-devel libmad-devel libvorbis-devel flac-devel"
DEPEND is deprecated, please use BUILD_REQUIRES instead
Ah, did not know it.
IF it's deprecated, unless I did not see it, is there any type of
warning when executing cygport?
If not, it would be a nice addition, so that automatically packagers are
aware of it.
BUILD_REQUIRES is a much better name, I'm going to use it immediately.
REQUIRES="libncursesw10 libmad0 libvorbis flac"
PKG_NAMES="cmus"
src_compile() {
lndirs
cd ${B}
sh ./configure \
CONFIG_MAD=y CONFIG_VORBIS=y CONFIG_FLAC=y \
prefix=/usr bindir=/usr/bin libdir=/usr/lib datadir=/usr/share
mandir=/usr/share/man
cygmake CC="${CC}" CXX="${CXX}" AR="${AR}" RANLIB="${RANLIB}"
STRIP=/usr/bin/true
I'm not sure any of these env vars are needed (and something here seems
to cause me some problem with "undefined reference to `xstrndup'" when
linking)
I have to admit that I've copy-pasted the cygmake line from another
cygport, probably also in that other package it's not necessary.
I've built (modulo errors) the packages in a "clean" environment, ie a
cygwin installation where I installed with setupx.exe
gcc,gdb,cygport,calm and the BUILD_REQUIRES packages.
I rechecked, and could not find anything related to xstrndup.
Could you share the exact error message?
I've dropped all the env vars and it does not seem to make any difference.
}
#src_install() {
Please drop these commented out lines.
# cd ${B}
# cyginstall
#}
#src_test() {
# # There is no test suite yet
# :
#}
I've reattached the cygport file, everything seems to work as before.
Before uploading, I would like to see the error you have, if possible.
# cmus.cygport
NAME="cmus"
VERSION=2.9.1
RELEASE=1
SUMMARY="cmus is a small, fast and powerful console music player for Unix-like
operating systems."
DESCRIPTION="cmus is a lightweight ncurses music player. It supports various
output methods by using dynamically-loaded output plugins."
CATEGORY="Audio"
HOMEPAGE="https://cmus.github.io/;
SRC_URI="https://github.com/cmus/cmus/archive/v${VERSION}.tar.gz;
SRC_DIR="cmus-${VERSION}"
BUILD_REQUIRES="libncurses-devel libmad-devel libvorbis-devel flac-devel"
REQUIRES="libncursesw10 libmad0 libvorbis flac"
PKG_NAMES="cmus"
src_compile() {
lndirs
cd ${B}
sh ./configure \
CONFIG_MAD=y CONFIG_VORBIS=y CONFIG_FLAC=y \
prefix=/usr bindir=/usr/bin libdir=/usr/lib datadir=/usr/share
mandir=/usr/share/man
cygmake
}
Re: [ITP] libxcvt
On 31.10.2021 13:34, Jon Turney wrote: libxcvt is a new dependency of the forthcoming X server 21. libxcvt is a library providing a standalone version of the X server implementation of the VESA CVT standard timing modelines generator. for me you can go on. In the past we have automatically accepted new packages that are needed as dependecy for future versions of an existing package Regards Marco
Re: cmus
On 23/10/2021 19:01, Federico Kircheis via Cygwin-apps wrote:
On 23/10/2021 17.39, Oliver Schoede wrote:
On Fri, 22 Oct 2021 15:06:46 +0200
Federico Kircheis via Cygwin-apps
wrote:
Hello to everyone,
I'm interested in becoming a package maintainer for the program cmus.
Very cool! My go-to music player, been using it for years, also in
Cygwin. ;) It's actually one of the reasons I started using it, knew it
from Linux and there being no port, building it on Windows turned out
easier in Cygwin. There was no WSL yet. An actual package is another
story of course, but if there's a problem and I could possibly be of any
help feel free to ask.
Looks like you appended the wrong .hint file.
Best regards,
Oliver
Let me try it again with the attachment...
Cool to know I'm not the only one using it under Windows :)
I did not notice any issue, but I'm just a casual user, thank you for
proposing to help, I'll keep it in mind ;)
Thanks.
I've added 'cmus' to your list of packages.
A few small comments on the cygport:
# cmus.cygport
NAME="cmus"
VERSION=2.9.1
TAG=2.9.1
Why not just use ${VERSION} throughout?
RELEASE=1
SUMMARY="cmus is a small, fast and powerful console music player for Unix-like
operating systems."
DESCRIPTION="cmus is a lightweight ncurses music player. It supports various output
methods by using dynamically-loaded output plugins."
CATEGORY="Audio"
HOMEPAGE="https://cmus.github.io/;
SRC_URI="https://github.com/cmus/cmus/archive/v${TAG}.tar.gz;
SRC_DIR="cmus-${TAG}"
DEPEND="libncurses-devel libmad-devel libvorbis-devel flac-devel"
DEPEND is deprecated, please use BUILD_REQUIRES instead
REQUIRES="libncursesw10 libmad0 libvorbis flac"
PKG_NAMES="cmus"
src_compile() {
lndirs
cd ${B}
sh ./configure \
CONFIG_MAD=y CONFIG_VORBIS=y CONFIG_FLAC=y \
prefix=/usr bindir=/usr/bin libdir=/usr/lib datadir=/usr/share
mandir=/usr/share/man
cygmake CC="${CC}" CXX="${CXX}" AR="${AR}" RANLIB="${RANLIB}"
STRIP=/usr/bin/true
I'm not sure any of these env vars are needed (and something here seems
to cause me some problem with "undefined reference to `xstrndup'" when
linking)
}
#src_install() {
Please drop these commented out lines.
# cd ${B}
# cyginstall
#}
#src_test() {
# # There is no test suite yet
# :
#}
Dropping various support in future releases - what about Mingw?
Perhaps someone could explain why Cygwin maintains, builds, and distributes Mingw tools and libraries, instead of that being done by the Mingw project(s) about which I know little? As we will be dropping Windows versions and 32 bit support in future releases, should we also be looking at dropping the Mingw packages we maintain, build, and distribute, but do not appear to use, except for building other Mingw packages? Supporting the two Mingw variations on packages sometimes takes as much work as the Cygwin packages, as parts of the toolchains and libraries may have different versions and dependencies. I basically build, check, and distribute those, but know little about using them to check they work, so no idea whether they work or not. I have had little success in getting the Mingw dual arch build process working to any useful extent, and no response to questions about that, which I may have buried at the end of my other verbiage on this list. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
RE: [ITP] aide 0.17.3
> -Original Message- > From: Jon Turney > Sent: Sunday, October 31, 2021 8:48 AM > > On 29/09/2021 15:27, Jason Pyeron wrote: > >> -Original Message- > >> From: Jason Pyeron > >> Sent: Friday, July 30, 2021 10:34 AM > >> > >> AIDE - Advanced Intrusion Detection Environment > >> > >> https://github.com/aide/aide/ > >> > >> It is a GPL v2 tool for monitoring file system changes. > >> > >> There was no (mature?) Windows open source solution until AIDE was built > >> and tested for > >> Cygwin. This fills a long standing gap in needs. > >> > >> Closed source alternative - Trip Wire. > >> > >> It is packaged and shipped with most Linux distributions - I am most > >> familiar with the > >> RHEL packaging. > >> > >> I have built and tested the most recent stable and development versions. > >> > >> I will track the development versions for test package releases. > >> > >> Category Security. > >> > >> Thoughts? > > > > There has been no response. It has been in test locally for 2 months now. > > > > May I push the cygport to git and provide a test release? > > > > Upstream has expressed willingness to review/track patches, if needed. > > > > Hi, > > Thanks for offering to package and maintain this package, and apologies > for the delay in responding. > > Notwithstanding [1] (which needs updating), I look for 2 things in an ITP: > > - a statement that the software uses an acceptable open-source license GPL v2, mentioned in the above original email. > - the cygport file (as an attachemnt or link) so it can be reviewed and > tested The attached (with required patch) has been in testing on multiple windows servers since late July. They can also be reviewed on github [2]. > > If you're still interested in progressing this, please provide the > cygport file for discussion. > > [1] https://cygwin.com/packaging-contributors-guide.html#submitting Interested, very interested. I am on the aide developers list to track updates, bugs, and patches. v/r, Jason Pyeron 2: https://github.com/pdinc-oss/aide/tree/cygport -- Jason Pyeron | Architect PD Inc| Certified SBA 8(a) 10 w 24th St | Certified SBA HUBZone Baltimore, MD | CAGE Code: 1WVR6 .mil: jason.j.pyeron@mail.mil .com: jpye...@pdinc.us tel : 202-741-9397 aide.cygport Description: Binary data diff --git a/include/util.h b/include/util.h index aaff780..d3472fa 100644 --- a/orig/include/util.h +++ b/patched/include/util.h @@ -21,6 +21,7 @@ #ifndef _UTIL_H_INCLUDED #define _UTIL_H_INCLUDED +#include "config.h" #include #include #include
Re: [ITP] aide 0.17.3
On 29/09/2021 15:27, Jason Pyeron wrote: -Original Message- From: Jason Pyeron Sent: Friday, July 30, 2021 10:34 AM AIDE - Advanced Intrusion Detection Environment https://github.com/aide/aide/ It is a GPL v2 tool for monitoring file system changes. There was no (mature?) Windows open source solution until AIDE was built and tested for Cygwin. This fills a long standing gap in needs. Closed source alternative - Trip Wire. It is packaged and shipped with most Linux distributions - I am most familiar with the RHEL packaging. I have built and tested the most recent stable and development versions. I will track the development versions for test package releases. Category Security. Thoughts? There has been no response. It has been in test locally for 2 months now. May I push the cygport to git and provide a test release? Upstream has expressed willingness to review/track patches, if needed. Hi, Thanks for offering to package and maintain this package, and apologies for the delay in responding. Notwithstanding [1] (which needs updating), I look for 2 things in an ITP: - a statement that the software uses an acceptable open-source license - the cygport file (as an attachemnt or link) so it can be reviewed and tested If you're still interested in progressing this, please provide the cygport file for discussion. [1] https://cygwin.com/packaging-contributors-guide.html#submitting
[ITP] libxcvt
libxcvt is a new dependency of the forthcoming X server 21. libxcvt is a library providing a standalone version of the X server implementation of the VESA CVT standard timing modelines generator. It is packaged for Fedora etc. (see [1]) cygport file: https://github.com/jon-turney/libxcvt-cygport/blob/master/libxcvt.cygport CI: https://cygwin.com/cgi-bin2/jobs.cgi?id=3463 license: MIT [1] https://repology.org/project/libxcvt/versions
