Re: cmus
On 14/11/2021 13.56, Jon Turney wrote: On 31/10/2021 19:00, Federico Kircheis via Cygwin-apps wrote: 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. I'm not able to reproduce the problem anymore, so I guess I must have messed up something locally when I was trying before. Please go ahead with the upload. Great, thank for letting me know
Re: cygport development
On 29/06/2020 18.04, Federico Kircheis wrote: On 6/12/20 9:55 AM, Federico Kircheis wrote: On May 29, 2020 4:38:53 AM UTC, Federico Kircheis wrote: I did not get any response to my last questions, so I hope this patch is enough. Any thought about my other arguments? Federico Ping. Any updates or comments? Is the patch ok? Ping I know it's been a while, I still would like cygport to avoid messing up unrelated directories. Are there any disadvantage stopping when cd fails? I did not get any feedback. AFAIK my patch has not been integrated and still applies to current master. Best Federico
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: cmus
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 ;)
# cmus.cygport
NAME="cmus"
VERSION=2.9.1
TAG=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${TAG}.tar.gz;
SRC_DIR="cmus-${TAG}"
DEPEND="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 CC="${CC}" CXX="${CXX}" AR="${AR}" RANLIB="${RANLIB}"
STRIP=/usr/bin/true
}
#src_install() {
# cd ${B}
# cyginstall
#}
#src_test() {
# # There is no test suite yet
# :
#}
# cmus.hint
sdesc: "cmus is a small, fast and powerful console music player for Unix-like
operating systems."
ldesc: "cmus is a lightweight ncurses music player. It supports various output
methods by using dynamically-loaded output plugins."
category: Audio
cmus
Hello to everyone,
I'm interested in becoming a package maintainer for the program cmus.
Homepage of the project is:
https://cmus.github.io/
Current release can be downloaded from
https://github.com/cmus/cmus/releases/tag/v2.9.1
It would be a new package for the cygwin distribution, but it is already
distributed on different systems, like Arch, Debian, Fedora, openSUSE,
Gentoo and many others.
More information can be found here:
* https://packages.debian.org/sid/cmus
* https://packages.gentoo.org/packages/media-sound/cmus
* https://software.opensuse.org/package/cmus
* https://pkgs.org/download/cmus
* https://www.freshports.org/audio/cmus
* https://formulae.brew.sh/formula/cmus
Currently there is no Windows port.
.hint and .cygport files are attached
Best regards
Federico Kircheis
# cmus.cygport
NAME="cmus"
VERSION=2.9.1
TAG=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 small, fast and powerful console music player for
Unix-like operating systems.
"
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"
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
}
#src_install() {
# cd ${B}
# cyginstall
#}
#src_test() {
# # There is no test suite yet
# :
#}
# neomutt.hint
sdesc: "a command line mail reader (or MUA)"
ldesc: "NeoMutt is a command line mail reader (or MUA).
It's a fork of Mutt with added features."
category: Mail
Re: [ITP] jpegoptim
Please ignore this email, it has been sent by accident. On 17/10/2021 15.58, Federico Kircheis wrote: Hello to everyone, I'm interested in becoming a package maintainer for the program jpegoptim. https://www.kokkonen.net/tjko/projects.html and https://github.com/tjko/jpegoptim are the homepages of the project. It would be a new package for the cygwin distribution, but it is already distributed on different systems, like Debian and derivatives (see for example https://packages.debian.org/sid/jpegoptim) Currently there is no Windows port (there has never been one as far as I know), therefore I would like to maintain a cygwin port, since i was able to compile and use the program without any patch. The program is licensed GPL2. Best regards Federico Kircheis
[ITP] jpegoptim
Hello to everyone, I'm interested in becoming a package maintainer for the program jpegoptim. https://www.kokkonen.net/tjko/projects.html and https://github.com/tjko/jpegoptim are the homepages of the project. It would be a new package for the cygwin distribution, but it is already distributed on different systems, like Debian and derivatives (see for example https://packages.debian.org/sid/jpegoptim) Currently there is no Windows port (there has never been one as far as I know), therefore I would like to maintain a cygwin port, since i was able to compile and use the program without any patch. The program is licensed GPL2. Best regards Federico Kircheis
Re: cygport development
On 6/12/20 9:55 AM, Federico Kircheis wrote: On May 29, 2020 4:38:53 AM UTC, Federico Kircheis wrote: I did not get any response to my last questions, so I hope this patch is enough. Any thought about my other arguments? Federico Ping. Any updates or comments? Is the patch ok? Ping
Re: cygport development
On May 29, 2020 4:38:53 AM UTC, Federico Kircheis wrote: >I did not get any response to my last questions, so I hope this patch >is >enough. > >Any thought about my other arguments? > >Federico Ping. Any updates or comments? Is the patch ok?
Re: cygport development
I did not get any response to my last questions, so I hope this patch is
enough.
Any thought about my other arguments?
Federico
On 5/17/20 7:54 PM, Federico Kircheis wrote:
Thank you for the feedback.
This patch is clearly not limited to the protection of data, as it
quotes variables that could in no way contain a space or have anything
to do with file paths.
Could you please point me to which variables are unrelated to files.
AFAIK i quoted files and arguments, which can all contain whitespace.
For example I did quote ${unpack_file_path}, but not ${unpack_cmd}.
As mentioned multiple times, using filenames
ore directories with spaces is asking for trouble, and I have no
interest in trying to support such a case.
The first commit makes sure that no information is lost while processing
file with spaces or other characters that cause globbing. This prevents
writing or modifying the wrong files, which is what happened to me.
The second commit add exit in case `cd` fails, which prevents other
errors afterwards.
Those modification do not add support for path with whitespace, as I was
still unable to compile the software, they did however prevent cygport
to delete unrelated data (or create data in the wrong location).
I'm willing to consider a
*limited* patch that makes sure that cygport doesn't do something it
shouldn't in that case, but that's about it.
Also because if the underlying tool like `make` does not support spaces,
it has no benefit.
The most minimal patch I can imagine is exiting if `cd` fails (just the
second commit).
Would you accept that?
But please also consider my other arguments.
Yaakov
PS:
A "nice" side-effect to quoting most variables that could contain white
space is that static-analyzers like shellcheck will emit less
diagnostic, making it easier to discover potential errors.
>From 9dec371efa2f4f943bdd660618a0e1d91b6cfb4a Mon Sep 17 00:00:00 2001
From: Federico Kircheis
Date: Tue, 2 Jul 2019 21:02:36 +0200
Subject: [PATCH] Exit in case `cd` fails
---
lib/src_fetch.cygpart | 2 +-
lib/src_prep.cygpart | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/src_fetch.cygpart b/lib/src_fetch.cygpart
index a273045..acea3a6 100644
--- a/lib/src_fetch.cygpart
+++ b/lib/src_fetch.cygpart
@@ -156,7 +156,7 @@ __src_fetch() {
done
# the RCS_fetch functions change PWD
- cd ${top};
+ cd ${top} || error "Unable to cd to ${top}"
for uri in ${SRC_URI} ${PATCH_URI}
do
diff --git a/lib/src_prep.cygpart b/lib/src_prep.cygpart
index 80ba8d5..fb99bfd 100644
--- a/lib/src_prep.cygpart
+++ b/lib/src_prep.cygpart
@@ -189,7 +189,7 @@ __gpg_verify() {
}
__mkdirs() {
- cd ${top};
+ cd ${top} || error "Unable to cd to ${top}";
mkdir -p ${srcdir} ${origsrcdir} ${B} ${D} ${T} ${configdir} ${logdir} ${distdir} ${patchdir} ${spkgdir};
}
@@ -286,7 +286,7 @@ __src_prep() {
local tar_patch;
local n=1;
- cd ${top};
+ cd ${top} || error "Unable to cd to ${top}";
__mkdirs;
@@ -345,7 +345,7 @@ __src_prep() {
__gpg_verify ${top}/${src_patchfile} "SOURCE PATCH";
fi
- cd ${origsrcdir};
+ cd ${origsrcdir} || error "Unable to cd to ${origsrcdir}";
for src_pkg in ${_src_orig_pkgs}
do
@@ -377,7 +377,7 @@ __src_prep() {
# cd will fail if not executable (e.g. dot2tex)
chmod +x ${origsrcdir}/${SRC_DIR};
- cd ${origsrcdir}/${SRC_DIR};
+ cd ${origsrcdir}/${SRC_DIR} || error "Unable to cd to ${origsrcdir}/${SRC_DIR}";
#v* Preparation/DISTCLEANFILES
# DESCRIPTION
@@ -404,7 +404,7 @@ __src_prep() {
if __check_function src_unpack_hook
then
__check_unstable src_unpack_hook;
- cd ${origsrcdir}/${SRC_DIR};
+ cd ${origsrcdir}/${SRC_DIR} | error "Unable to cd to ${origsrcdir}/${SRC_DIR}";
fi
for src_patch in ${_src_orig_patches}
@@ -446,7 +446,7 @@ __src_prep() {
if __check_function src_patch_hook
then
__check_unstable src_patch_hook;
- cd ${origsrcdir}/${SRC_DIR};
+ cd ${origsrcdir}/${SRC_DIR} || error "Unable to cd to ${origsrcdir}/${SRC_DIR}";
fi
__step "Preparing working source directory";
@@ -456,7 +456,7 @@ __src_prep() {
mkdir -p ${C};
ln -sfn ${C} ${workdir}/CYGWIN-PATCHES;
- cd ${S};
+ cd ${S} || error "Unable to cd to ${S}";
if [ -f ${top}/${cygwin_patchfile} ]
then
--
2.26.2
Re: cygport development
Thank you for the feedback.
This patch is clearly not limited to the protection of data, as it
quotes variables that could in no way contain a space or have anything
to do with file paths.
Could you please point me to which variables are unrelated to files.
AFAIK i quoted files and arguments, which can all contain whitespace.
For example I did quote ${unpack_file_path}, but not ${unpack_cmd}.
As mentioned multiple times, using filenames
ore directories with spaces is asking for trouble, and I have no
interest in trying to support such a case.
The first commit makes sure that no information is lost while processing
file with spaces or other characters that cause globbing. This prevents
writing or modifying the wrong files, which is what happened to me.
The second commit add exit in case `cd` fails, which prevents other
errors afterwards.
Those modification do not add support for path with whitespace, as I was
still unable to compile the software, they did however prevent cygport
to delete unrelated data (or create data in the wrong location).
I'm willing to consider a
*limited* patch that makes sure that cygport doesn't do something it
shouldn't in that case, but that's about it.
Also because if the underlying tool like `make` does not support spaces,
it has no benefit.
The most minimal patch I can imagine is exiting if `cd` fails (just the
second commit).
Would you accept that?
But please also consider my other arguments.
Yaakov
PS:
A "nice" side-effect to quoting most variables that could contain white
space is that static-analyzers like shellcheck will emit less
diagnostic, making it easier to discover potential errors.
Re: cygport development
On 10/14/19 10:55 AM, Federico Kircheis wrote:
On 13/10/2019 18.41, Achim Gratz wrote:
Federico Kircheis writes:
I've sent the patches the 14.07.19, unfortunately I still got no answer.
The cygport maintainer is rather busy with non-Cygwin related work these
days, I suppose. Anyway, one of the questions I have is why you need
these changes. Most build systems do not actually work when they
encounter a path with spaces if they use make under the hood, so fixing
cygport to grok such path locations isn't getting you much further I'd
think. Can you explain?
Yep.
I've built some software in my windows home directory.
It contains a space.
I expected it to work.
Instead of failing with a clear error message, the build process deleted
some unrelated files as it cd failed (or cd in the wrong directory, cant
remember right now).
I believe it is unacceptable to delete unrelated data.
Even if it stated that there is no intention to support path with
spaces, those scripts should fail fast and ideally with a clear error
message.
I found it easier to quote the offending variables, as not only spaces
might cause issues.
The merge request in the repository has been closed.
I'm attaching the updated patch.
>From b927688b921988c9aa7dafe9fbde9b71f96aa5c3 Mon Sep 17 00:00:00 2001
From: Federico Kircheis
Date: Tue, 2 Jul 2019 20:53:55 +0200
Subject: [PATCH 1/2] Add support for path with spaces
Quote most variables
---
bin/cygport.in | 74 +-
lib/config_registry.cygpart | 8 +--
lib/src_compile.cygpart | 2 +-
lib/src_fetch.cygpart | 30 +--
lib/src_prep.cygpart| 102 ++--
lib/syntax.cygpart | 10 ++--
6 files changed, 113 insertions(+), 113 deletions(-)
diff --git a/bin/cygport.in b/bin/cygport.in
index 12909fe..0503676 100755
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -42,7 +42,7 @@ declare -r _privsysconfdir=@sysconfdir@;
### import defined, pushd, popd
-source ${_privlibdir}/syntax.cygpart
+source "${_privlibdir}/syntax.cygpart"
###
@@ -166,7 +166,7 @@ source ${_privlibdir}/help.cygpart
# Accept --help and --version arguments without specifying a cygport file
while true
do
- case ${1} in
+ case "${1}" in
--help|-h|-\?)
__show_help;
exit 0;
@@ -204,7 +204,7 @@ do
esac
done
-declare -ar argv=(${0} ${@})
+declare -ar argv=(${0} "${@}")
declare -ir argc=$(( $# + 1 ))
# Show help if no commands are given
@@ -222,7 +222,7 @@ fi
### import check_prog and friends
-source ${_privlibdir}/check_funcs.cygpart
+source "${_privlibdir}/check_funcs.cygpart"
###
# check now for all mandatory programs
@@ -349,11 +349,11 @@ unset _autotools_CYGCLASS_ _autotools_CYGCLASS_stage1_
unset NAME VERSION RELEASE
-if [ -f ${argv[1]} ]
+if [ -f "${argv[1]}" ]
then
- eval $(grep '^NAME=' ${argv[1]})
- eval $(grep '^VERSION=' ${argv[1]})
- eval $(grep '^RELEASE=' ${argv[1]})
+ eval "$(grep '^NAME=' "${argv[1]}")"
+ eval "$(grep '^VERSION=' "${argv[1]}")"
+ eval "$(grep '^RELEASE=' "${argv[1]}")"
fi
if [ "${NAME+y}${VERSION+y}${RELEASE+y}" = "yyy" ]
@@ -371,7 +371,7 @@ declare -r PN=${PF%%-[0-9]*};
declare NAME=${PN}
declare -r PR=${PF##*-};
declare RELEASE=${PR}
-PV=$(echo ${PF} | sed -e "s/${PN}\-\(.*\)\-${PR}$/\1/");
+PV=$(echo "${PF}" | sed -e "s/${PN}\-\(.*\)\-${PR}$/\1/");
declare VERSION=${PV}
declare -r cygportfile=${PF}.cygport;
fi
@@ -395,7 +395,7 @@ _topdir=${argv[1]%/*};
if [ "x${_topdir}" = "x${argv[1]}" ]
then
- if [ -f ./${cygportfile} ]
+ if [ -f "./${cygportfile}" ]
then
_topdir=.;
else
@@ -406,7 +406,7 @@ fi
declare -r top=$(cd ${_topdir}; pwd);
unset _topdir;
-if [ ! -e ${top}/${cygportfile} ]
+if [ ! -e "${top}/${cygportfile}" ]
then
error "${cygportfile} not found.";
fi
@@ -438,7 +438,7 @@ done
unset n VALUE ARCHES VAR
### load .cygport
-source ${top}/${cygportfile} || error "could not read ${cygportfile}"
+source "${top}/${cygportfile}" || error "could not read ${cygportfile}"
###
case ${ARCH} in
@@ -448,7 +448,7 @@ esac
if defined CYGPORT_DEPEND
then
- if ! __version_at_least ${CYGPORT_DEPEND} ${_cygport_version}
+ if ! __version_at_least "${CYGPORT_DEPEND}" "${_cygport_version}"
then
error "This package requires cygport ${CYGPORT_DEPEND} or newer";
fi
@@ -511,7 +511,7 @@ declare -r uploadlog="${logdir}/${PF}-upload.log";
for _src_uri in ${SRC_URI}
do
- if [ -f ${top}/${_src_uri} ]
+ if [ -f "${top}/${_src_uri}" ]
then
_src_orig_pkgs+=" ${_src_uri}";
continue;
@@ -525,7 +525,7 @@ unset _src_uri;
for _patch_uri in ${PATCH_URI}
do
- if [ -f ${top}/${_patch_uri} ]
+ if [ -f "${top}/${_patch_uri}" ]
then
_src_orig_patches+=" ${_patch_uri}";
continue;
@@ -537,8 +537,8 @@ done
readonly
