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