cygport - get package dependencies
Takashi Yano wrote: Furthermore, you do not need to add ffmpeg to "REQUIRES" because the cmus package itself does not really depend on ffmpeg package even though it depends libavcodec, libavformat, libavutil and libswresample. I was already told once that I probably can leave REQUIRES out. Currently I'm using it for setting up a minimal test environment where I install only the packages listed in REQUIRES. Can cygport give me that information if I do not write any REQUIRES? Last time I asked the answer was no, and thus I decided to keep it to ease testing on my side. Without REQUIRES line, "cygport cmus all" with above patch gives me: cmus requires: cygwin libao4 libavcodec61 libavformat61 libavutil59 libcddb2 libcdio18 libcdio_cdda2 libdiscid0 libFLAC12 libiconv2 libmad0 libmodplug1 libmpcdec7 libncursesw10 libopusfile0 libpulse0 libswresample5 libvorbisfile3 libwavpack1 I guess this is as you expect (if libav* are free from clang dependency), isn't it? Yes, it looks good. I'll drop the REQUIRES the next time I'll upload a package then. Hello, I have a feature request/question for the cygport maintainer (not sure how those are normally handled) cygport reports the required packages, but only after building the application. My workflow is normally the following one: Setup the cygwin environment for building and testing, download the sources, then in an offline environment, build and test. Since "cygport cmus all" reports the required dependencies only after building, I have some difficulties in taking advantage of the listed packages... I could imagine to have a "minimal cygwin environment" for executing "cygport cmus enlist-dependencies", and from the output create one cygwin environment for building, and one for testing, but if it needs to build the application, I do not see how to use it for bootstrapping an offline environment. I could move the REQUIRES from the cygport file to somewhere else and use it only myself, but at that point, why not use the REQUIRES? -- 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
Interaction with non-cygwin programs
I've lately updated Windows to the latest version, and cygwin too (I had something previous to 3.0). I've read that interaction with non-cygwin programs should be better because of the console-helper. But in my daily usage the integration is worse, programs like tmux or even less seems to have more issues than before. For example /cygdrive/c/Program\ Files/TortoiseSVN/bin/svn log | less used to work correctly. Currently if I press arrow down or up less does not scroll up or down anymore and "ESC[" appears briefly at the top-left of the console. Of course i could install subversion inside cygwin, as svn log | less works without issues, but it's just an example. git, adb, and other programs trigger the same behavior. Also less is not the only program, tmux for example has similar issues. I believe the underlying issue is console-helper but I'm not sure how I could test it, as I did, for example, not find how I could disable it, or if the issue is already known. I'm able to reproduce the issue on a clean machine, so it should not be a configuration issue on my side. -- 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: Interaction with non-cygwin programs
On 10/24/20 8:10 PM, Brian Inglis wrote: On 2020-10-24 09:04, Federico Kircheis via Cygwin wrote: I've lately updated Windows to the latest version, and cygwin too (I had something previous to 3.0). I've read that interaction with non-cygwin programs should be better because of the console-helper. But in my daily usage the integration is worse, programs like tmux or even less seems to have more issues than before. For example /cygdrive/c/Program\ Files/TortoiseSVN/bin/svn log | less used to work correctly. Currently if I press arrow down or up less does not scroll up or down anymore and "ESC[" appears briefly at the top-left of the console. Of course i could install subversion inside cygwin, as svn log | less works without issues, but it's just an example. git, adb, and other programs trigger the same behavior. Also less is not the only program, tmux for example has similar issues. I believe the underlying issue is console-helper but I'm not sure how I could test it, as I did, for example, not find how I could disable it, or if the issue is already known. I'm able to reproduce the issue on a clean machine, so it should not be a configuration issue on my side. I think setting CYGWIN=disable_pcon in your user or system environment should disable it: search for that setting for more information. Thank you, setting CYGWIN to disable_pcon as environment variable did the trick with, I'll observe in the next days if all my issues are really gone. Unfortunately it seems that it is only possible to set this variable globally, correct? It is not possible, for example, to set it from bash only for some processes. AFAIK I cannot have both /cygdrive/c/Program\ Files/TortoiseSVN/bin/svn log | less and /cygdrive/c/Program\ Files/Python/Python39/python working correctly, as the first works with CYGWIN=disable_pcon and the second not. -- 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: Interaction with non-cygwin programs
On 10/24/20 9:35 PM, Brian Inglis wrote: On 2020-10-24 13:11, Federico Kircheis via Cygwin wrote: On 10/24/20 8:10 PM, Brian Inglis wrote: On 2020-10-24 09:04, Federico Kircheis via Cygwin wrote: I've lately updated Windows to the latest version, and cygwin too (I had something previous to 3.0). I've read that interaction with non-cygwin programs should be better because of the console-helper. But in my daily usage the integration is worse, programs like tmux or even less seems to have more issues than before. For example /cygdrive/c/Program\ Files/TortoiseSVN/bin/svn log | less used to work correctly. Currently if I press arrow down or up less does not scroll up or down anymore and "ESC[" appears briefly at the top-left of the console. Of course i could install subversion inside cygwin, as svn log | less works without issues, but it's just an example. git, adb, and other programs trigger the same behavior. Also less is not the only program, tmux for example has similar issues. I believe the underlying issue is console-helper but I'm not sure how I could test it, as I did, for example, not find how I could disable it, or if the issue is already known. I'm able to reproduce the issue on a clean machine, so it should not be a configuration issue on my side. I think setting CYGWIN=disable_pcon in your user or system environment should disable it: search for that setting for more information. Thank you, setting CYGWIN to disable_pcon as environment variable did the trick with, I'll observe in the next days if all my issues are really gone. Unfortunately it seems that it is only possible to set this variable globally, correct? It is not possible, for example, to set it from bash only for some processes. AFAIK I cannot have both /cygdrive/c/Program\ Files/TortoiseSVN/bin/svn log | less and /cygdrive/c/Program\ Files/Python/Python39/python working correctly, as the first works with CYGWIN=disable_pcon and the second not. I doubt it, but you could try if it could work using e.g. $ alias wpython='CYGWIN="" /cygdrive/c/Program\ Files/Python/Python39/python' $ wpython ... No, unfortunately it does not work... It's a shame, but I think I'll leave pcon disabled at the moment... or is there anything else I could try? AFAIK pcon is relatively new, so I'm hoping that it will mature soon enough. -- 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: Interaction with non-cygwin programs
On 25/10/2020 11.12, Takashi Yano wrote: On Sat, 24 Oct 2020 17:04:59 +0200 Federico Kircheis via Cygwin wrote: I've lately updated Windows to the latest version, and cygwin too (I had something previous to 3.0). I've read that interaction with non-cygwin programs should be better because of the console-helper. But in my daily usage the integration is worse, programs like tmux or even less seems to have more issues than before. For example /cygdrive/c/Program\ Files/TortoiseSVN/bin/svn log | less used to work correctly. Currently if I press arrow down or up less does not scroll up or down anymore and "ESC[" appears briefly at the top-left of the console. Of course i could install subversion inside cygwin, as svn log | less works without issues, but it's just an example. git, adb, and other programs trigger the same behavior. Also less is not the only program, tmux for example has similar issues. I believe the underlying issue is console-helper but I'm not sure how I could test it, as I did, for example, not find how I could disable it, or if the issue is already known. I'm able to reproduce the issue on a clean machine, so it should not be a configuration issue on my side. Could you please try cygwin latest snapshot? https://cygwin.com/snapshots/ Thank you, tried and it seems to work. I could notice only one minor issue: when making changing the terminal size with "Wind+arrow"with /cygdrive/c/Program\ Files/TortoiseSVN/bin/svn log | less less does not seem to acknowledge the new terminal size, while svn log | less does. If using the mouse and resizing the terminal by hand, both commands seem to behave the same. -- 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
[ANNOUNCEMENT] Updated: jpegoptim-1.5.1-1
Version 1.5.1-1 of jpegoptim has been uploaded. jpegoptim is an utility for optimizing jpeg files. It provides lossless optimization (based on optimizing the Huffman tables) and "lossy" optimization based on setting maximum quality factor. On GitHub it is possible to find the changelog for the new release: https://github.com/tjko/jpegoptim/releases Federico -- 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
[ANNOUNCEMENT] Updated: jpegoptim-1.5.2-1
Version jpegoptim-1.5.2-1 of jpegoptim has been uploaded. jpegoptim is an utility for optimizing jpeg files. It provides lossless optimization (based on optimizing the Huffman tables) and "lossy" optimization based on setting maximum quality factor. On GitHub it is possible to find the changelog for the new release: https://github.com/tjko/jpegoptim/releases Federico -- 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
[ANNOUNCEMENT] Updated: nnn-4.7-1
Version nnn-4.7-1 of nnn has been uploaded. nnn is a full-featured terminal file manager On GitHub it is possible to find the changelog for the new release: https://github.com/jarun/nnn/releases/ Federico -- 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
[ANNOUNCEMENT] Updated: nnn-4.8-1
Version 4.8-1 of nnn has been uploaded. nnn is a full-featured terminal file manager On GitHub it is possible to find the changelog for the new release: https://github.com/jarun/nnn/releases/ Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20230512-1
Version 20230512-1 of neomutt has been uploaded. neomutt is a command line mail reader. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: jpegoptim-1.5.4-1
Version 1.5.4-1 of jpegoptim has been uploaded. jpegoptim is an utility for optimizing jpeg files. It provides lossless optimization (based on optimizing the Huffman tables) and "lossy" optimization based on setting maximum quality factor. On GitHub it is possible to find the changelog for the new release: https://github.com/tjko/jpegoptim/releases Federico -- 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
Analyze dependencies of a cygwin package
Hello to everyone, yesterday I've uploaded a new cmus package, with some optional features enabled. Today, through setup.exe, I noticed that now cmus brings clang as dependency. Is there something I can use for analyzing transitive dependencies of a package? It does not make sense for an audio player to bring a compiler as dependency, and would like to remove the offending dependency. Best Federico -- 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: Analyze dependencies of a cygwin package
On 21/06/2024 09.52, Mark Geisert via Cygwin wrote: On 6/20/2024 11:21 PM, Federico Kircheis via Cygwin wrote: Hello to everyone, yesterday I've uploaded a new cmus package, with some optional features enabled. Today, through setup.exe, I noticed that now cmus brings clang as dependency. Is there something I can use for analyzing transitive dependencies of a package? It does not make sense for an audio player to bring a compiler as dependency, and would like to remove the offending dependency. Try the cygcheck-dep tool, downloadable through setup.exe. It was created to answer questions just like this. Recommended :-). ..mark Thank you, very useful. Still some questions, as I might be me holding it wrong. First; is it expected that I need admin rights to execute it? mkdir: cannot create directory ‘/var/cache/cygcheck-dep’: Permission denied /usr/bin/cygcheck-dep: unable to create cache directory: /usr/bin/cygcheck-dep: /var/cache/cygcheck-dep Can't it use /tmp or some other location for caching data? After my first run as admin, after 2 minutes, I got following output cygcheck-dep -r cmus bzip2: /var/cache/cygcheck-dep/cygwin/x86_64/setup.bz2: data integrity (CRC) error in data You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. /usr/bin/cygcheck-dep: failed to check integrity of downloaded file: /usr/bin/cygcheck-dep: /var/cache/cygcheck-dep/cygwin/x86_64/setup.bz2 /usr/bin/cygcheck-dep: you may try to run with -c option to use cached file from previous download Might have been a spurious error, because after a rerun (without -c) I did not get that error anymore. Third run; are all those warnings expected? cygcheck-dep -R cmus # /usr/bin/cygcheck-dep: # warning: not available package version: # failed to parse file record of # 'version:' for the following packages: #( gdb-multiarch libcoordgen2 libcoordgen3 libgnat12 libgnat13 liblua5.4 libwx_baseu3.1-devel libwx_baseu3.1_5 libwx_gtk2u3.1-devel libwx_gtk2u3.1_5 libwx_gtk3u3.1-devel libwx_gtk3u3.1_5 mingw64-i686-openssl-debuginfo mingw64-x86_64-openssl-debuginfo python39-imaging python39-imaging-tk python39-wx tzdata-posix tzdata-right wxWidgets3.1-debuginfo wxWidgets3.1-doc ) # /usr/bin/cygcheck-dep: # warning: extraneous installed packages with unknown dependencies: # the following installed packages are not present # in Cygwin standard distribution: #( libdialog14 ) # /usr/bin/cygcheck-dep: # warning: unknown package names: # the following encountered package names does not match # any available or installed package (use -M switch to get details): #( python27 python-avogadro python2-avogadro gstreamer1.0-plugins-ugly-free-mad _update-info-dir libedit libexpat1-devel gmp-doc libMagickCore6 libncursesw-devel rdiff-debuginfo mate-themes-extras emacs-mercurial mercurial-convert mercurial-gui mercurial-highlight mingw64-i686-libgd mingw64-x86_64-libgd ncursesw ncursesw-demo octave-octcdf perl-Parse-CPAN-Meta perl-File-Slurp-Unicode perl-Locale-gettext perl-LWP net-snmp-perl perl-Term-ReadKey perl-Gnome2 perl-Gnome2-Canvas perl-Gnome2-GConf perl-Gnome2-Rsvg perl-Gnome2-VFS perl-Gnome2-Vte perl-Gnome2-Wnck perl-Gtk2 perl-Gtk2-GladeXML perl-Gtk2-Notify perl-Gtk2-SourceView2 perl-Gtk2-Spell perl-Gtk2-Unique perl-Gtk2-WebKit kde-wallpapers procps procps-debuginfo python2-cairo-devel python3-dbus-debuginfo python-cv python2_cv2 python-magic python2-magic python-speechd python-zbar python-pypdf python-odf python-pyqt5-devel python-sip-devel rpm-doc rxvt-unicode-X-debuginfo ksnapshot-debuginfo font-unifont-misc font-unifont-ttf xfce4-mixer xfce4-mixer-debuginfo transfig-debuginfo _windows(>=6.3) cygwin(>=3.5.0-0) emacs-bin gcc11 perl5_036 ruby_32 cygwin(>=3.5.0)) # /usr/bin/cygcheck-dep: # warning: missing required dependencies: # the following packages are not installed, but are required as dependencies # for some installed packages (use -m switch to get details): #( _windows(>=6.3) cygwin(>=3.5.0-0) emacs-bin gcc11 perl5_036 ruby_32 cygwin(>=3.5.0) ) cmus: recursively requires ( ... a lot of packages ... ) otherwise, the ouput of "recursively requires" was helpful, but only limited; I could see clang as dependency, but not why. I used "cygcheck-dep -n clang" and followed the dependency chain manually; I hoped that "cygcheck-dep -R cmus" would have showed something like a tree structure. But here comes the important question. How can I use cygcheck-dep for a package that has not been uploaded yet? I would like to avoid uploading a new package, and verify afterwards if everything looks fine or not. -- 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: Analyze dependencies of a cygwin package
On 21/06/2024 09.52, Mark Geisert via Cygwin wrote: On 6/20/2024 11:21 PM, Federico Kircheis via Cygwin wrote: Hello to everyone, yesterday I've uploaded a new cmus package, with some optional features enabled. Today, through setup.exe, I noticed that now cmus brings clang as dependency. Is there something I can use for analyzing transitive dependencies of a package? It does not make sense for an audio player to bring a compiler as dependency, and would like to remove the offending dependency. Try the cygcheck-dep tool, downloadable through setup.exe. It was created to answer questions just like this. Recommended :-). ..mark After some investigation, it seems that ffmeg hash clang (which has gcc) as dependency in its chain. I would consider it a bug, although not critical. It seems that most libraries have bash as a dependency, for example libmad0: recursively requires ( bash cygwin libgcc1 libiconv2 libintl8 libncursesw10 libreadline7 libzstd1 terminfo zlib0 _windows(>=6.3) ) libvorbis: recursively requires ( ) flac: recursively requires ( bash cygwin libFLAC12 libgcc1 libiconv2 libintl8 libncursesw10 libogg0 libreadline7 libzstd1 terminfo zlib0 _windows(>=6.3) ) libopusfile0: recursively requires ( bash ca-certificates crypto-policies cygwin libffi6 libgcc1 libiconv2 libintl8 libncursesw10 libogg0 libopus0 libp11-kit0 librea dline7 libssl1.1 libtasn1_6 libzstd1 p11-kit p11-kit-trust terminfo zlib0 _windows(>=6.3) ) libsamplerate0: recursively requires ( bash cygwin libgcc1 libiconv2 libintl8 libncursesw10 libreadline7 libzstd1 terminfo zlib0 _windows(>=6.3) ) libwavpack1: recursively requires ( bash cygwin libgcc1 libiconv2 libintl8 libncursesw10 libreadline7 libzstd1 terminfo zlib0 _windows(>=6.3) ) libcdio_paranoia2: recursively requires ( bash cygwin libcdio18 libcdio_cdda2 libgcc1 libiconv2 libintl8 libncursesw10 libreadline7 libzstd1 terminfo zlib0 _windows( >=6.3) ) libmpcdec7: recursively requires ( bash cygwin libgcc1 libiconv2 libintl8 libncursesw10 libreadline7 libzstd1 terminfo zlib0 _windows(>=6.3) ) libcddb: recursively requires ( bash cygwin libcddb2 libcdio18 libgcc1 libiconv2 libintl8 libncursesw10 libreadline7 libzstd1 terminfo zlib0 _windows(>=6.3) ) libdiscid: recursively requires ( bash cygwin libdiscid0 libgcc1 libiconv2 libintl8 libncursesw10 libreadline7 libzstd1 terminfo zlib0 _windows(>=6.3) ) Again, it seems like a bug, but since so many libraries have bash as a dependency, could it be that cygcheck-dep incorrectly adds it? -- 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: Analyze dependencies of a cygwin package
On 22/06/2024 02.29, Takashi Yano via Cygwin wrote: On Sat, 22 Jun 2024 07:22:42 +0900 Takashi Yano wrote: Hi Federico, On Fri, 21 Jun 2024 19:35:32 +0200 Federico Kircheis wrote: After some investigation, it seems that ffmeg hash clang (which has gcc) ^^ as dependency in its chain. I would consider it a bug, although not critical. Do you mean "ffmpeg has clang as dependency"? That's right thing. ffmpeg depends on clang indirectly as follows. ffmpeg depends on libavfilter10. libavfilter10 depends on libOpenCL1. libOpenCL1 depends on libpocl2. libpocl2 depends on clang. pocl uses Clang as an OpenCL C frontend and LLVM for the kernel compiler implementation, and as a portability layer. Yes, that is what I meant with ffmpeg has (not hash, there was a typo sorry) clans as dependency in its chain (and not directly). I do not know this libraries well enough to say if every dependency in the chain makes sense or not, but the chain as a whole surprised me. The final effect was having an audio player bringing two C compilers (clang depends on gcc) as dependency... At least for one of my setups, having clang/gcc was problematic, and it needs to download a lot of data... ffmpeg, as far as I've could see, on Debian does not seem to depend transitively on clang. BTW, I looked into cmus.cygport of 2.11.0-2 and noticed that you need to patch for configure to enable ffmpeg plugin as attached. With ffmpeg plugin, many of audio formats get supported by cmus. Oh, thanks, I'll give it a more detailed look later. As I do not want to bring some compilers as dependencies, I will not apply it at the moment. Furthermore, you do not need to add ffmpeg to "REQUIRES" because the cmus package itself does not really depend on ffmpeg package even though it depends libavcodec, libavformat, libavutil and libswresample. Yes, ffmpeg came as transitive dependency, I did not add it directly. If I remember correctly, one chain looked more or less like clang -> libpocl2 -> libOpenCL1 -> libavfilter10 -> ffmpeg -> libavcodec61 -> cmus Maybe, you do not have to add any of packages to "REQUIRES" because dependencies are added automatically by cygport in most cases. I was already told once that I probably can leave REQUIRES out. Currently I'm using it for setting up a minimal test environment where I install only the packages listed in REQUIRES. Can cygport give me that information if I do not write any REQUIRES? Last time I asked the answer was no, and thus I decided to keep it to ease testing on my side. Best Federico -- 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: Analyze dependencies of a cygwin package
On 22/06/2024 10.17, Takashi Yano via Cygwin wrote: On Sat, 22 Jun 2024 07:36:19 +0200 Federico Kircheis wrote: ffmpeg, as far as I've could see, on Debian does not seem to depend transitively on clang. ffmpeg on fedora is built with opencl-enabled. https://src.fedoraproject.org/rpms/ffmpeg/blob/rawhide/f/ffmpeg.spec#_702 I just followed to it. However, cygwin's OpenCL (ocl-icd) suppourts only pocl as backend which depends on clang. Therefore, on the second thought, enabling opencl for ffmpeg has more disadvantages than advantages. I'll release ffmpeg 7.0.1-2 which disables opencl. I was already told once that I probably can leave REQUIRES out. Currently I'm using it for setting up a minimal test environment where I install only the packages listed in REQUIRES. Can cygport give me that information if I do not write any REQUIRES? Last time I asked the answer was no, and thus I decided to keep it to ease testing on my side. Without REQUIRES line, "cygport cmus all" with above patch gives me: cmus requires: cygwin libao4 libavcodec61 libavformat61 libavutil59 libcddb2 libcdio18 libcdio_cdda2 libdiscid0 libFLAC12 libiconv2 libmad0 libmodplug1 libmpcdec7 libncursesw10 libopusfile0 libpulse0 libswresample5 libvorbisfile3 libwavpack1 I guess this is as you expect (if libav* are free from clang dependency), isn't it? Yes, it looks good. I'll drop the REQUIRES the next time I'll upload a package then. -- 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
cygport - avoid stripping binaries
Hello, it seems that cygport always strip binaries, but I have one program that when stripped does not work correctly. As far as I've understood https://cygwin.github.io/cygport/compilers_cygpart.html#robo759 I should be able to set something like STRIP=/usr/bin/true and then stripping should be a no-op, but it did not work, the binaries in the install folder are still stripped. Any hints? Best Federico -- 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: cygport - avoid stripping binaries
On 06/11/2021 18.30, Corinna Vinschen via Cygwin wrote:
On Nov 6 15:31, Federico Kircheis via Cygwin wrote:
it seems that cygport always strip binaries, but I have one program that
when stripped does not work correctly.
Out of curiosity, what program is that? And why does it require the
symbols to be present in the executable?
Corinna
Hi Corinna,
it's pari-gp the program I'm having trouble packaging.
If I compile it manually, without cygport, then I'm able to execute it.
If I use cygport, then the program misbehaves.
I've noticed that cygport strips the binaries, so I thought that could
be the issue.
Also setting
RESTRICT="strip" and STRIP=/usr/bin/true
seems to strip some information compared to the manually built binary.
Best
Federico
PS:
Why does cygport strip binaries by default?
Doesn't it generally makes harder to debug issues?
If stripping removes unused data I would actually expect the compiler to
not generate it, and if the data is used
Is it a common practice for GNU/Linux distribution to strip binaries
when creating packages?
# pari.cygport
NAME="pari"
VERSION=2.13.3
RELEASE=1
SUMMARY="add summary"
DESCRIPTION="add description"
CATEGORY="Mail" #FIXME, find category
HOMEPAGE="https://pari.math.u-bordeaux.fr";
SRC_URI="https://pari.math.u-bordeaux.fr/pub/pari/unix/pari-${VERSION}.tar.gz";
SRC_DIR="pari-${VERSION}"
# for documentation needs latex (pdflatex for creating pdf)
BUILD_REQUIRES="libncurses-devel libreadline-devel libgmp-devel"
REQUIRES="libreadline libgmp10"
PKG_NAMES="pari"
src_compile() {
lndirs
cd ${B}
sh ./Configure \
--prefix=/usr
cygmake gp
}
src_install() {
cd ${B}
cyginstall
}
src_test() {
cygmake bench
}
--
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: cygport upload seems to ignore SSH_KEY
On 05/11/2024 17.01, Brian Inglis via Cygwin wrote: On 2024-11-05 04:19, Andrew Schulman via Cygwin wrote: On 2024-11-04 12:20, Federico Kircheis via Cygwin wrote: up until recently I've uploaded packages the following way export SSH_KEY=/path/to/id_rsa; cygport /path/to/file.cygport upload but today I got the following error cd: Fatal error: max-retries exceeded I've fixed it by copying my key in the .ssh folder cp $SSH_KEY ~/.ssh/id_rsa cygport /path/to/file.cygport upload So it is not blocking me, but I wanted to know if this was a known bug, or if I am the only one experiencing it. See https://cygwin.github.io/cygport/cygport_conf.html#SSH_KEY or /usr/share/doc/cygport/html/manual/cygport_conf.html#SSH_KEY SSH_KEY DESCRIPTION Path to the SSH private key corresponding to the public key registered for uploading on sourceware. You'll need to set this if your private key isn't already loaded into a running ssh-agent(1), and it doesn't have one of the expected file names such as ~/.ssh/id_rsa. Also, setting this allows cygport to determine if a passphrase is needed to decrypt the key, and only prompt you for a passphrase if it's needed. Otherwise, you'll be prompted for a passphrase every time you upload. Instead of `ssh-agent` and `ssh-add`, you can use `keychain` in your login profile, which allows cross-session sharing, across X and terminal sessions, and logouts, for example: $ eval `/usr/bin/keychain --noask --eval ~/.ssh/id_rsa` then $ keychain ~/.ssh/id_rsa I haven't used cygport up in a long time - I use git push now, and let scallywag build the packages Is this workflow described somewhere? It sounds interesting. - but this does seem like new wrong behavior. Surely he shouldn't have to use keychain to get cygport to work? According to the docs, as you cited, his method should work. Using keychain is just a way of setting up, persisting, and sharing ssh-/gpg-agent sessions, so keys are kept available in long running agent sessions, across login sessions, without requesting passphrase input for some period. Likely the issue could be permissions on his alternate location key file and directory/path, as libraries and clients are getting pickier about security issues and vulnerabilities, and openssh was recently updated, although cygport should diagnose any failures. The message itself appears likely to have come from `lftp` invoked by `cygport ... upload` /usr/share/cygport/lib/pkg_upload.cygpart failing to authenticate a connection, for some reason? Yes, the error message comes from lftp, because when cd is executed it tries to connect (apparently multiple times instead of erroring out immediately, a the beginning I thought it was simply hanging). So far it seems that it should work, I'll try to gather other information next time. I also did a chmod/chwon on the file to ensure that the permission where correct. The file with the permission unchanged worked without issues when moved in ~/.ssh. -- 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: cygport upload seems to ignore SSH_KEY
On 05/11/2024 18.29, ASSI via Cygwin wrote: Federico Kircheis via Cygwin writes: I also did a chmod/chown on the file to ensure that the permission where correct. The file with the permission unchanged worked without issues when moved in ~/.ssh. Whatever directory that file resides in must be readable only by the owner or SSH will not use it. Regard, Achim. Mhm, that could be it. I did not try to modify the permission of the directory. -- 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
cygport upload seems to ignore SSH_KEY
Hello, up until recently I've uploaded packages the following way export SSH_KEY=/path/to/id_rsa; cygport /path/to/file.cygport upload but today I got the following error cd: Fatal error: max-retries exceeded I've fixed it by copying my key in the .ssh folder cp $SSH_KEY ~/.ssh/id_rsa cygport /path/to/file.cygport upload So it is not blocking me, but I wanted to know if this was a known bug, or if I am the only one experiencing it. Best Federico -- 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
Conflict between tmux and cygwin
It seems there is a conflict betwene some tmux functionalities and cygwin. In tmux it is possible to open a new windows with "tmux new-window -c $NEW_WD", the new shell should be located at "$NEW_WD", but it seems not to work with cygwin; th new shell is always openeed at ~ I thought I had it working years ago, and assumed it was a tmux specific bug on cygwin, as tmux on Linux work as expected, thus I hacked around the issue by making aliases and adding cd commands. Today I found https://github.com/tmux/tmux/issues/3283, and I can confirm that the CHERE_INVOKING functionality is causing the issue. I would like to avoid to change the provided /etc/profile to avoid conflicts during upgrades, but I would also like to have tmux work correctly out-of-the-box, like on all other platforms. Is there some way to reach such status? Best Federico -- 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
cygpath and unc paths
Hello, was it considered to add a flag to cygpath to output a path in unc format? For example, the folder C:\test. cannot be accessed from many Windows applications (powershell and cmd included) because of the trailing dot, while cygwin has no issue creating, accessing and deleting such files/folders. Using an unc path \\?\C:\test. solves the issue for some programs, but cygpath currently misses an option for creating such path. Notice that creating a dos path leads to an error. -- 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: cygpath and unc paths
On 09/12/2024 12.46, Corinna Vinschen via Cygwin wrote: On Dec 6 13:23, Federico Kircheis via Cygwin wrote: Hello, was it considered to add a flag to cygpath to output a path in unc format? No. But it wouldn't be much work. It would be very nice if it ever happens. For example, the folder C:\test. cannot be accessed from many Windows applications (powershell and cmd included) because of the trailing dot, while cygwin has no issue creating, accessing and deleting such files/folders. Using an unc path \\?\C:\test. solves the issue for some programs, but cygpath currently misses an option for creating such path. As a workaround you can just prepend the long path prefix: echo -n '\\?\'; cygpath ... Which is what I'm doing, plus special-casing 1) root path, like C:\ , because for whatever reason \\?\C:\ is not valid, it has to be a subfolder (and trying to trick it with \\?\C:\\ does not work either). 2) unmounted network drives (\\server\path) I'm not sure how a --unc should handle those cases. For all things I have in mind, not appending \\?\ is preferred, but someone might expect a hard error. Either way, it is another reason why it makes sense for cygpath to handle those cases, currently I have to parse it's output before prepending '\\?\'. Notice that creating a dos path leads to an error. I don't understand. Creating which DOS path with which application? I meant that it is not possible to create a DOS path to C:\test., thus using a dos path is not a viable workaround to unc: > cd 'C:/test.' > cygpath -ws . cygpath: cannot create short name of . -- 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: cygpath and unc paths
On 09/12/2024 14.17, Corinna Vinschen via Cygwin wrote: On Dec 9 13:47, Federico Kircheis via Cygwin wrote: On 09/12/2024 12.46, Corinna Vinschen via Cygwin wrote: On Dec 6 13:23, Federico Kircheis via Cygwin wrote: Hello, was it considered to add a flag to cygpath to output a path in unc format? No. But it wouldn't be much work. It would be very nice if it ever happens. For example, the folder C:\test. cannot be accessed from many Windows applications (powershell and cmd included) because of the trailing dot, while cygwin has no issue creating, accessing and deleting such files/folders. Using an unc path \\?\C:\test. solves the issue for some programs, but cygpath currently misses an option for creating such path. As a workaround you can just prepend the long path prefix: echo -n '\\?\'; cygpath ... Which is what I'm doing, plus special-casing 1) root path, like C:\ , because for whatever reason \\?\C:\ is not valid, it has to be a subfolder (and trying to trick it with \\?\C:\\ does not work either). In which scenario? \\?\C:\ is just the same as \??\C:\ in NT speak, and that's a perfectly valid directory path. I've never seen \??\C:\. My test case, from powershell (which I do definitively _not_ know well enough, otherwise I wouldn't be using cygwin) was cd C:\ # success cd \\?\C:\ # fail cd C:\windows # success cd \\?\C:\windows # success and repeat the same operation with dir instead of ls. The error message is that the "value of argument path is not valid" I did some further testing: no amount of quoting (with ", ' and `) helps, also replacing \ with / does not change any outcome. For cd, the parameter -literal makes a difference cd -literal \\?\C:\ # success for dir, I did not find anything yet. So I guess you are correct, although support from basic tools (cd and dir at least) seems very suboptimal... 2) unmounted network drives (\\server\path) Yeah, those have a different prefix: \\?\UNC\server\share I'm not sure how a --unc should handle those cases. For all things I have in mind, not appending \\?\ is preferred, but someone might expect a hard error. Either way, it is another reason why it makes sense for cygpath to handle those cases, currently I have to parse it's output before prepending '\\?\'. I'll take a look. Notice that creating a dos path leads to an error. I don't understand. Creating which DOS path with which application? I meant that it is not possible to create a DOS path to C:\test., thus using a dos path is not a viable workaround to unc: cd 'C:/test.' cygpath -ws . cygpath: cannot create short name of . Don't use -s, it's just for the old short name style of DOS paths. Nobody should actually need this nowadays, and sometimes short paths don't even exist. It's a functionality inside the FS driver, afaik, and it can be switched off in the system. In your example, standard filenames work: $ cd /cygdrive/c $ mkdir test. $ cd test. $ cygpath -ws . cygpath: cannot create short name of C:\test. $ cygpath -wa . C:\test. Yes, -wa works; I wanted to point out that DOS paths are not a viable workaround. I could have left it out from my first mail, we agree no need to iterate further ;) -- 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: env and PATH
Iterating and invoking an external program (cygpath) for every path takes some time. Depends on actual use case, it may be just a single invocation for entire list. I'm currently not on Windows, you mean it is possible to convert C:\Windows;C:\Windows\system32; to /cygdrive/c/windows:/cygdrive/c/windows/system32 (or equivalent with /proc) with one invocation of cygpath? If that is the option --path (just read from the documentation, I did not notice it before, and did not try it, I will do it in the next days) then I suppose the performance issue I mentioned would be a non-issue. Although I would still have preferred to be able to tell env to use the variable as-is, just like all the others. Confirmed, with --path it is possible to convert the Windows PATH to a cygwin PATH, that then gets converted to a Windows PATH again when invoking a Windows program. One binary call is obviously much faster than iterating every element in PATH and converting them one by one, which makes it a viable solution. -- 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: cygpath and unc paths
This way, you're testing command interpreter, not WinApi.
The command interpreter has its own ideas about what you can and can not use
with it.
Yes, after I saw it works with "-literal" I convinced my self it is a
bug in PowerShell (I guess they strip the trailing \, but who knows).
But then I noticed that:
* cd \\?\C:\Windows\; cd .. also fails (another bug in PowerShell?)
* the "-d" parameter of Windows Terminal has a very similar issue
* FindFirstFile (thus WinApi) documents that it does not work with the
root directory ("Prepending the string "\\?\" does not allow access to
the root directory", from
https://docs.microsoft.com/windows/win32/api/fileapi/nf-fileapi-findfirstfilew)
So even if \\?\C:\ is a valid path (and to me it still looks like a
valid one), support seems to be scarce or at least inconsistent with the
tools provided by Microsoft.
and repeat the same operation with dir instead of ls.
The error message is that the "value of argument path is not valid"
F.e. Far manager works just fine with `goto:\\?\C:\`. More or less.
Yes, Far was the only tool (except cygwin) that worked with every path
I've tested; in this particular case, far \\?\C:\ opens the correct
directory.
--
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: cygport upload seems to ignore SSH_KEY
On 05/11/2024 18.31, Federico Kircheis wrote: On 05/11/2024 18.29, ASSI via Cygwin wrote: Federico Kircheis via Cygwin writes: I also did a chmod/chown on the file to ensure that the permission where correct. The file with the permission unchanged worked without issues when moved in ~/.ssh. Whatever directory that file resides in must be readable only by the owner or SSH will not use it. Regard, Achim. Mhm, that could be it. I did not try to modify the permission of the directory. Nope. Directory has permission 0700, file has permission 0600, just to be sure I've execute chmod on both. I can access they key but I still experienced the issue $ ls -la $SSH_KEY -rw---+ 1 Administrators None 3357 Dec 20 2019 /cygdrive/c/cygport-ps/ssh/id_rsa_cyg $ ls -la /cygdrive/c/cygport-ps/ssh/ total 13 drws--S---+ 1 Administrators None0 Jan 14 2023 . drwxrwx---+ 1 Administrators None0 Dec 18 10:55 .. -rw---+ 1 Administrators None 3357 Dec 20 2019 id_rsa_cyg -rw---+ 1 Administrators None 745 Jul 25 2018 id_rsa_cyg.pub -rw---+ 1 Administrators None 236 Mar 18 2020 known_hosts If I manually execute lftp $ lftp sftp://cygwin:@cygwin.com lftp cygwin@cygwin.com:~> cd . cd `.' [Connecting...] and hangs. I'm not sure how to debug the issue further, and the relation between all tools. $ sftp sftp://cygwin:@cygwin.com cygwin:@cygwin.com: Permission denied (publickey). Connection closed I guess lftp/sftp does not support the variable SSH_KEY, as I get the same "Permission denied (publickey)." error with "ssh -v sftp://cygwin:@cygwin.com";, and I see that there is no attempt to use my ssh key Also following command does not report an error: sftp -i $SSH_KEY sftp://cygwin:@cygwin.com Connection closed by 8.43.85.97 port 22 Connection closed -- 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: cygport upload seems to ignore SSH_KEY
On 18/12/2024 20.38, Eliot Moss wrote: On 12/18/2024 2:30 PM, Federico Kircheis via Cygwin wrote: On 05/11/2024 18.31, Federico Kircheis wrote: On 05/11/2024 18.29, ASSI via Cygwin wrote: Federico Kircheis via Cygwin writes: I also did a chmod/chown on the file to ensure that the permission where correct. The file with the permission unchanged worked without issues when moved in ~/.ssh. Whatever directory that file resides in must be readable only by the owner or SSH will not use it. Regard, Achim. Mhm, that could be it. I did not try to modify the permission of the directory. Nope. Directory has permission 0700, file has permission 0600, just to be sure I've execute chmod on both. I can access they key but I still experienced the issue $ ls -la $SSH_KEY -rw---+ 1 Administrators None 3357 Dec 20 2019 /cygdrive/c/ cygport-ps/ssh/id_rsa_cyg $ ls -la /cygdrive/c/cygport-ps/ssh/ total 13 drws--S---+ 1 Administrators None 0 Jan 14 2023 . drwxrwx---+ 1 Administrators None 0 Dec 18 10:55 .. -rw---+ 1 Administrators None 3357 Dec 20 2019 id_rsa_cyg -rw---+ 1 Administrators None 745 Jul 25 2018 id_rsa_cyg.pub -rw---+ 1 Administrators None 236 Mar 18 2020 known_hosts If I manually execute lftp $ lftp sftp://cygwin:@cygwin.com lftp cygwin@cygwin.com:~> cd . cd `.' [Connecting...] and hangs. I'm not sure how to debug the issue further, and the relation between all tools. $ sftp sftp://cygwin:@cygwin.com cygwin:@cygwin.com: Permission denied (publickey). Connection closed I guess lftp/sftp does not support the variable SSH_KEY, as I get the same "Permission denied (publickey)." error with "ssh -v sftp:// cygwin:@cygwin.com", and I see that there is no attempt to use my ssh key Also following command does not report an error: sftp -i $SSH_KEY sftp://cygwin:@cygwin.com Connection closed by 8.43.85.97 port 22 Connection closed Curious. I'm not an expert, but I tend to put info in my ssh config file. Does that help here? And, probably grasping at straws, are you sure SSH_KEY is exported :-) ? Some people who are more expert might have better suggestions ... Eliot Moss Yes, I'm sure it is exported, and currently even copying the file in .ssh does not work, which did work last time (I get the exact same behavior), thus ATM I'm unable to push an update. Maybe an issue server-side? -- 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
env and PATH
Hello to everyone, I've noticed that env seems to handle the environment variable PATH in a particular way - > cd /d; > env -i PATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:PATH C;D:\Windows;C;D:\Windows\system32; From this and other examples it seems that env uses for PATH as separator, then preprends the current drive to all paths that begin with '\' (thus all of them), and ";" is treated as part of the path I would like to use the PATH as-is in the invoked program, just like it is done for other variables, for example cd /d env -i OPATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:OPATH C:\Windows;C:\Windows\system32; in this case OPATH is forwarded as-is to powershell.exe. I understand that PATH is special, that for cygwin processes some transformation might be necessary. But is there any way to achieve what I'm trying? I search if there is maybe a separation option for telling env to use PATH as-is, but could not find none. Best Federico -- 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: Conflict between tmux and cygwin
On 7 December 2024 02:48:50 UTC, Keith Thompson
wrote:
>It's not really a tmux issue. You can demonstrate it just by invoking
>a shell.
>
>For example, if you "cd /tmp" and then invoke a new shell with
>"bash -l", the code in /etc/profile will cd to your home directory.
>(This doesn't happen on Ubuntu, for example, which has a
>different /etc/profile.)
>
>But if you invoke bash without "-l", or with "CHERE_INVOKING=1 bash
>-l", the new shell will have /tmp as its current directory.
>
>"chere" is a script, installable via Cygwin setup, that enables
>opening a Cygwin terminal in a specific directory via the Windows
>Explorer context menu (right-click). I haven't tried it myself yet.
>
>Here's the relevant code from /etc/profile :
>
># Make sure we start in home unless invoked by CHERE
>if [ ! -z "${CHERE_INVOKING}" ]; then
> unset CHERE_INVOKING
>else
> cd "${HOME}" || echo "WARNING: Failed attempt to cd into ${HOME}!"
>fi
Hi,
Yes, I wrote myself that it is not a tmux issue but a config in /etc/profile,
as it is also written on the bug report.
The question was of it is possible to have tmux work correctly out of the box
without having end users changing /etc/profile, and if this conflict in
functionalities was known to packagers and mantainers
--
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: env and PATH
On 09/01/2025 08.31, Andrey Repin wrote: The apparent issue you are missing is that you are calling native app from Cygwin environment. Each have its own rules, and to have it working with minimal issues, you'd need to satisfy both sides. In specific case, PATH is a special environment variable for both sides, and you have to correctly translate it from one side to the other. What do you mean? I'm perfectly aware that PATH is special, and why it is, I also wrote it in the first mail. I questioned the statement that the conversion is expected _because_ `env` expects POSIX semantics and parsed my command according to that. Since POSIX says nothing about the interaction of env and PATH, and conversions are not described by the standard (as you confirmed), the behavior is expected because of what cygwin does, not because of POSIX. (and yes, I knew cygwin does the conversion from cygwin PATH to Windows PATH, so that was expected, I did not expect it to break a Windows PATH and to depend on the current drive) The main question of this thread was: "I noticed that PATH is converted, and cannot find a switch do disable this conversion. Is it possible to define an environment and use it as is, without having some implicit conversions?" I mean, there are other variables that have special meanings; all those that define a path. (Examples would be HOME, XDG_CACHE_HOME, XDG_DATA_HOME, ...) The answer seems to be no (which was what I feared). Thus special casing for some environment variables is necessary as there is no such switch. I saw PATH as particularly problematic because I was not aware of the option --path of cygpath. I provided a wrapper script I use myself, you could add any massaging to it that you feel necessary. Like `unset TERM` or PATH modifications. Attachment seems to be missing, but I think unsetting environment variables one by one, changing existing, and adding the missing, is too error-prone. Defining a "clean" environment once seems to have less chances to have some errors. -- 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: env and PATH
On 13/01/2025 09.59, Andrey Repin wrote: Greetings, Federico Kircheis! On 09/01/2025 08.31, Andrey Repin wrote: The apparent issue you are missing is that you are calling native app from Cygwin environment. Each have its own rules, and to have it working with minimal issues, you'd need to satisfy both sides. In specific case, PATH is a special environment variable for both sides, and you have to correctly translate it from one side to the other. What do you mean? I'm perfectly aware that PATH is special, and why it is, I also wrote it in the first mail. It is special TO BOTH SIDES. The "both" is the key word. I questioned the statement that the conversion is expected _because_ `env` expects POSIX semantics and parsed my command according to that. No, it is expected because of its meaning to both sides AND because env don't know, what kind of program it is running. But I know that the program is a windows program, thus a setting for manually disabling the conversion made sense (at least in my head). Runtime knows, env does not. Runtime does conversion, not env. Ah, ok I missed the part that the conversion is not done by env but somewhere else, thus a flag for env does might not make that much sense. Since POSIX says nothing about the interaction of env and PATH, Why it should? This is Cygwin specifics. and conversions are not described by the standard (as you confirmed), the behavior is expected because of what cygwin does, not because of POSIX. (and yes, I knew cygwin does the conversion from cygwin PATH to Windows PATH, so that was expected, I did not expect it to break a Windows PATH and to depend on the current drive) env don't expect Windows paths to begin with. And dependency on current drive is coincidental, since your paths, read as POSIX, were interpreted as relative. The main question of this thread was: "I noticed that PATH is converted, and cannot find a switch do disable this conversion. Is it possible to define an environment and use it as is, without having some implicit conversions?" I mean, there are other variables that have special meanings; all those that define a path. (Examples would be HOME, XDG_CACHE_HOME, XDG_DATA_HOME, ...) Special to both sides? While HOME and TMP do have a meaning to both sides (though, HOME is questionable), XDG_* ones are purely *NIX specific. XDG_* are not purely unix specific; they are just environment variables. For example, I actually expect a multiplatform programs that respect XDG_* on a Linux machine to respect it also on Windows. Why should a program that supports XDG_* environment variables go out of it's way and explicitly ignore them? The answer seems to be no (which was what I feared). Thus special casing for some environment variables is necessary as there is no such switch. I saw PATH as particularly problematic because I was not aware of the option --path of cygpath. I provided a wrapper script I use myself, you could add any massaging to it that you feel necessary. Like `unset TERM` or PATH modifications. Attachment seems to be missing, Was not an attachment. (The list is not very tolerant to those.) Ah sorry, I thought you provided a wrapper script as attachment, and could not find it. but I think unsetting environment variables one by one, changing existing, and adding the missing, is too error-prone. Defining a "clean" environment once seems to have less chances to have some errors. That's up to you. I have more intricate wrappers than this one. Just didn't want to flood the list. -- 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: env and PATH
On 04/01/2025 21.13, Andrey Repin wrote: Greetings, Federico Kircheis! On 04/01/2025 02.41, Andrey Repin wrote: Greetings, Federico Kircheis! Hello to everyone, I've noticed that env seems to handle the environment variable PATH in a particular way - >> cd /d; >> env -i PATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:PATH C;D:\Windows;C;D:\Windows\system32; Fully expected behavior. `env` expects POSIX semantics and parsed your command according to that. The results are, as I said, expected, although not by you. What do you mean by POSIX semantic? On my Linux system, PATH is used unmodified by subprocesses, not transformed. This is (IMHO) the expected semantic. No. env is a Cygwin (POSIX) tool and it works with POSIX paths. When starting non-POSIX app, Cygwin will translate $PATH back to native format. I am not aware of any rule in POSIX that requires or recommends some transformations for environment variables, in that sense, any transformation is "unexpected" or an extension to the standard. That's Cygwin specific. It completely makes sense to convert cygwin paths to windows path when invoking windows programs, but it is not my case. Then why TF you supply Windows paths to it? Because it is a windows program. And since I do not have cygwin paths, it does not make sense to convert them. Hence why I searched for an option, even an explicit one, to tell cygwin not to modify the parameters, but use them as-is. From this and other examples it seems that env uses for PATH as separator, then preprends the current drive to all paths that begin with '\' (thus all of them), and ";" is treated as part of the path Exactly. I would like to use the PATH as-is in the invoked program, just like it is done for other variables, for example cd /d env -i OPATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:OPATH C:\Windows;C:\Windows\system32; in this case OPATH is forwarded as-is to powershell.exe. I understand that PATH is special, that for cygwin processes some transformation might be necessary. It is, but in a way you suppose. But is there any way to achieve what I'm trying? Yes. Pass the POSIX paths in $PATH, they will be converted to Windows ones when invoking a Windows process. Also, I strongly suggest using /proc/cygdrive/ tree in such case, especially when you make scripts for somebody else. I was not aware of /proc/cygdrive/, thank you for the hint, although I am not sure how it helps. I search if there is maybe a separation option for telling env to use PATH as-is, but could not find none. There's no need or reason to do it. In your case, what you wanted to achieve could be written as env -i "PATH=$(cygpath -UW):$(cygpath -US):$PATH" pwsh The reason is I already have a variable containing the path I should use as PATH, and it is the windows expected format. But you just said that your app is NOT a Windows app. Then why do you attempt to supply it Windows paths? No. I wrote that it is not my case because my PATH does not have cygwin paths; it has windows paths. Then in your example you invoke PowerShell which IS a Windows app. So, what was it? I'm trying to invoke a Windows program, as I wrote since my first mail. I need to convert it to a cygwin path, so that env translates it back again. It is doable, but sounds completely unnecessary. Nope. Also it comes at a particular cost at runtime. I want to start the subshell as fast as possible. () will start a subshell. As fast as possible. Sorry, I meant a windows subshell; for example cmd and powershell. Iterating and invoking an external program (cygpath) for every path takes some time. Depends on actual use case, it may be just a single invocation for entire list. I'm currently not on Windows, you mean it is possible to convert C:\Windows;C:\Windows\system32; to /cygdrive/c/windows:/cygdrive/c/windows/system32 (or equivalent with /proc) with one invocation of cygpath? If that is the option --path (just read from the documentation, I did not notice it before, and did not try it, I will do it in the next days) then I suppose the performance issue I mentioned would be a non-issue. Although I would still have preferred to be able to tell env to use the variable as-is, just like all the others. But let's stop there and settle the matter of what we are doing and what is the expected result. The use-case is starting a windows shell (powershell, cmd, ...) with a provided environment, from cygwin. For example an environment without TERM, without cygwin tools in PATH, and so on. The easiest way to do it is to use env, ignore all environment variables, and provide the desired one. The "issue" is that in case of PATH (and maybe other env variables? so far PATH is the only one I o
Re: env and PATH
On 04/01/2025 02.41, Andrey Repin wrote: Greetings, Federico Kircheis! Hello to everyone, I've noticed that env seems to handle the environment variable PATH in a particular way - >> cd /d; >> env -i PATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:PATH C;D:\Windows;C;D:\Windows\system32; Fully expected behavior. `env` expects POSIX semantics and parsed your command according to that. The results are, as I said, expected, although not by you. What do you mean by POSIX semantic? On my Linux system, PATH is used unmodified by subprocesses, not transformed. This is (IMHO) the expected semantic. I am not aware of any rule in POSIX that requires or recommends some transformations for environment variables, in that sense, any transformation is "unexpected" or an extension to the standard. It completely makes sense to convert cygwin paths to windows path when invoking windows programs, but it is not my case. Hence why I searched for an option, even an explicit one, to tell cygwin not to modify the parameters, but use them as-is. From this and other examples it seems that env uses for PATH as separator, then preprends the current drive to all paths that begin with '\' (thus all of them), and ";" is treated as part of the path Exactly. I would like to use the PATH as-is in the invoked program, just like it is done for other variables, for example cd /d env -i OPATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:OPATH C:\Windows;C:\Windows\system32; in this case OPATH is forwarded as-is to powershell.exe. I understand that PATH is special, that for cygwin processes some transformation might be necessary. It is, but in a way you suppose. But is there any way to achieve what I'm trying? Yes. Pass the POSIX paths in $PATH, they will be converted to Windows ones when invoking a Windows process. Also, I strongly suggest using /proc/cygdrive/ tree in such case, especially when you make scripts for somebody else. I was not aware of /proc/cygdrive/, thank you for the hint, although I am not sure how it helps. I search if there is maybe a separation option for telling env to use PATH as-is, but could not find none. There's no need or reason to do it. In your case, what you wanted to achieve could be written as env -i "PATH=$(cygpath -UW):$(cygpath -US):$PATH" pwsh The reason is I already have a variable containing the path I should use as PATH, and it is the windows expected format. I need to convert it to a cygwin path, so that env translates it back again. It is doable, but sounds completely unnecessary. Also it comes at a particular cost at runtime. I want to start the subshell as fast as possible. Iterating and invoking an external program (cygpath) for every path takes some time. (The "%SystemRoot%" is NOT NECESSARILY 'C:\Windows', though you CAN use "%SystemRoot%\System32" with confidence, once you acquired the former.) (Also, why the *** you are using v1.0? Get v7 already, save yourself the tragedy.) Because the executable I invoked is the one installed on all Windows versions since Windows 7 (or maybe even Vista?). Also the actual version is not 1.0, but something like 5.something (if I remember correctly) v7 is AFAIK a different product, but most importantly it needs to be installed separately, and would not change the issue I have. -- 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: env and PATH
On 20/12/2024 23.15, Brian Inglis via Cygwin wrote: Hi Federico, Looks like non-Cygwin program launch is messing up PATH not on the current drive: $ cd /proc/cygdrive/d $ cat -A /proc/cygdrive/d/tmp/t.cmd echo %PATH%^M$ $ env -i PATH='C:\Windows;C:\Windows\system32;' /bin/sh -c 'echo $PATH' C:\Windows;C:\Windows\system32; $ env -i PATH='C:\Windows;C:\Windows\system32;' `cygpath $COMSPEC` /s /c \ "d:\tmp\t.cmd" D:\>echo C;D:\Windows;C;D:\Windows\system32; C;D:\Windows;C;D:\Windows\system32; D:\>exit I did some other testing From cygwin, without using env explicitly > PATH='D:\windows' /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe > echo $env:PATH D;C:\windows (similar result for cmd) From powershell > $env:PATH="D:\windows" > C:/Windows/System32/WindowsPowerShell/v1.0/powershell.exe > echo $env:PATH D:\windows (similar result for cmd) I also tried PATH='D:\windows' /usr/bin/cygstart /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe hoping it would do the trick, but PATH is still "broken", and powershell starts in a separate window :( On 2024-12-20 09:51, Federico Kircheis via Cygwin wrote: Hello to everyone, I've noticed that env seems to handle the environment variable PATH in a particular way - > cd /d; > env -i PATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/ WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:PATH C;D:\Windows;C;D:\Windows\system32; From this and other examples it seems that env uses for PATH as separator, then preprends the current drive to all paths that begin with '\' (thus all of them), and ";" is treated as part of the path I would like to use the PATH as-is in the invoked program, just like it is done for other variables, for example cd /d env -i OPATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/ WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:OPATH C:\Windows;C:\Windows\system32; in this case OPATH is forwarded as-is to powershell.exe. I understand that PATH is special, that for cygwin processes some transformation might be necessary. But is there any way to achieve what I'm trying? I search if there is maybe a separation option for telling env to use PATH as- is, but could not find none. Best Federico -- 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: env and PATH
On 02/01/2025 10.34, Federico Kircheis wrote: On 20/12/2024 23.15, Brian Inglis via Cygwin wrote: Hi Federico, Looks like non-Cygwin program launch is messing up PATH not on the current drive: $ cd /proc/cygdrive/d $ cat -A /proc/cygdrive/d/tmp/t.cmd echo %PATH%^M$ $ env -i PATH='C:\Windows;C:\Windows\system32;' /bin/sh -c 'echo $PATH' C:\Windows;C:\Windows\system32; $ env -i PATH='C:\Windows;C:\Windows\system32;' `cygpath $COMSPEC` / s /c \ "d:\tmp\t.cmd" D:\>echo C;D:\Windows;C;D:\Windows\system32; C;D:\Windows;C;D:\Windows\system32; D:\>exit I did some other testing From cygwin, without using env explicitly > PATH='D:\windows' /c/Windows/System32/WindowsPowerShell/v1.0/ powershell.exe > echo $env:PATH D;C:\windows (similar result for cmd) From powershell > $env:PATH="D:\windows" > C:/Windows/System32/WindowsPowerShell/v1.0/powershell.exe > echo $env:PATH D:\windows (similar result for cmd) I also tried PATH='D:\windows' /usr/bin/cygstart /c/Windows/System32/ WindowsPowerShell/v1.0/powershell.exe hoping it would do the trick, but PATH is still "broken", and powershell starts in a separate window :( And obvisouyl I also tried > PATH="/cydrive/c/windows:/cygdrive/d/windows" /c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe > echo $env:PATH C:\Windows;D:\Windows So it still looks like cygwin translates the paths when creating a new process. From powershell > $env:PATH="/d/windows" > C:/Windows/System32/WindowsPowerShell/v1.0/powershell.exe > echo $env:PATH /d/windows which seems to imply that powershell (and cmd) gets the environment variable PATH as-is On 2024-12-20 09:51, Federico Kircheis via Cygwin wrote: Hello to everyone, I've noticed that env seems to handle the environment variable PATH in a particular way - > cd /d; > env -i PATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/ WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:PATH C;D:\Windows;C;D:\Windows\system32; From this and other examples it seems that env uses for PATH as separator, then preprends the current drive to all paths that begin with '\' (thus all of them), and ";" is treated as part of the path I would like to use the PATH as-is in the invoked program, just like it is done for other variables, for example cd /d env -i OPATH='C:\Windows;C:\Windows\system32;' /c/Windows/System32/ WindowsPowerShell/v1.0/powershell.exe # in the powershell instance echo $env:OPATH C:\Windows;C:\Windows\system32; in this case OPATH is forwarded as-is to powershell.exe. I understand that PATH is special, that for cygwin processes some transformation might be necessary. But is there any way to achieve what I'm trying? I search if there is maybe a separation option for telling env to use PATH as- is, but could not find none. Best Federico -- 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: Latest version of mc requires python3
On 17/02/2025 16.31, Marco Atzeri via Cygwin wrote: On 17/02/2025 12:55, Marco Atzeri wrote: On 17/02/2025 12:29, Federico Kircheis via Cygwin wrote: Hello to everyone I just noted that the last version of mc (4.8.33-1) depends on python3. only optional at best. I will look on the matter 4.8.33-2 uploaded. The 3 extra python files have been moved in the doc directory is someone want to use them. Regards Marco Thank you! I'll give it a look in the next days Federico -- 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
Latest version of mc requires python3
Hello to everyone I just noted that the last version of mc (4.8.33-1) depends on python3. Up to version 4.8.32-1 there was no such dependency (I guess it was optional. I made a first search, and did not find that the new version requires python3. On Debian (same version), for example, python3 is an optional dependency. Was that an oversight while mc was packaged for cygwin, or is python3 really required? Best Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200320-1
Version 20200320-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200320. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200417-1
Version 20200417-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200417. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200424-1
Version 20200424-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200424. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200501-1
Version 20200501-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200501. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200619-1
Version 20200619-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200619. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200424-1
Version X-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200424. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200807-1
Version 20200807-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200807. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200814-1
Version 20200814-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200814. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200821-1
Version 20200821-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200821. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20200925-1
Version 20200925-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20200925. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20201120-1
Version X-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20201120. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20201127-1
Version 20201127-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20201127. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20220408-1
Version 20220408-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20220408. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20220415-1
Version 20220415-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20220415. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20220429-1
Version 20220429-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20220429. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: dumpasn1-20210212-1
Version 20210212-1 of dumpasn1 has been uploaded. dumpasn1 is an ASN.1 object dump program which will dump data encoded using any of the ASN.1 encoding rules in a variety of user-specified formats. -- 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
[ANNOUNCEMENT] Updated: neomutt-20210205-1
Version 20210205-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20210205. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20211015-1
Version 20211015-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20211015. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20211022-1
Version 20211022-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20211022. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: neomutt-20211029-1
Version 20211029-1 of neomutt has been uploaded. The command line mail reader neomutt reached version 20211029. On GitHub it is possible to find the changelog for the new release: https://github.com/neomutt/neomutt/releases Federico -- 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
[ANNOUNCEMENT] Updated: cmus-2.9.1-1
Version 2.9.1-1 of cmus has been uploaded. The music player cmus reached version 2.9.1. On GitHub it is possible to find the changelog for the new release: https://github.com/cmus/cmus/releases Federico -- 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
