SSH access to desktop
I need to be able to SSH into a Windows machine with Cygwin installed and be able to run Windows programs and see the Windows they create. That is, when I run "notepad" I need to see the Window it creates. And, I need multiple users to be able to do this. In the past, I did this by having each user put an item in their Startup folder that did: C:\cygwin64\usr\sbin\sshd.exe -p 8100 where the port, 8100 in this case, is different for each user. The snag now seems to be: $ /usr/sbin/sshd.exe -p 8100 /var/empty must be owned by root and not group or world-writable. $ ls -l /var total 4 drwxr-xr-x+ 1 layer Domain Users 0 Mar 16 10:13 cache/ drwxr-x--x+ 1 Administrator Administrators 0 Mar 16 10:08 empty/ drwxr-xr-x+ 1 layer Domain Users 0 Mar 16 10:06 lib/ drwxrwxrwt+ 1 Administrators Administrators 0 Mar 16 15:08 log/ drwxrwxrwt+ 1 Administrators Administrators 0 Mar 16 10:51 run/ drwxrwxrwt+ 1 layer Domain Users 0 Apr 2 00:42 tmp/ $ The "in the past" is on an older version of Cygwin that hasn't been updated in a while. The new machine, where this is not working, is pretty up to date. Ideas? Thanks. Kevin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.13
Hi Cygwin friends and users, I just released a new Cygwin TEST version 2.5.0-0.13. This test release only contains one noticable patches on top of -0.12: - Fix a problem in the new console reporting code which seems to be the culprit for the vim hang reported in https://cygwin.com/ml/cygwin/2016-04/msg00126.html The rest of this mail is what you know from the -0.11/0.12 release messages. If things are not going very wrong, this is basically what you'll get as 2.5.0-1 release (really, we mean it this time). Please, please test and report regressions. Refresh with the following changes: - Declare BSD finite/isinf/isnan functions in . - The isinf/isinff/isinfl functions are now signed, returning -1 for negative infinity for compatibility with glibc. - Update sysconf(3) for recent feature additions. - Fix getconf(1) supported specifications on 64-bit. - Applied feature test macros in and . - Added . - fexcept_t is now an integral type for source compatibility with glibc and other systems. - Fixes for compiling with G++ 6. User-visible changes compared to 2.4.1: What's new: --- - Full set of POSIX.1e ACL API functions now implemented. New APIs: acl_add_perm, acl_calc_mask, acl_clear_perms, acl_copy_entry, acl_copy_ext, acl_copy_int, acl_create_entry, acl_delete_def_file, acl_delete_entry, acl_delete_perm, acl_dup, acl_free, acl_from_text, acl_get_entry, acl_get_fd, acl_get_file, acl_get_permset, acl_get_qualifier, acl_get_tag_type, acl_init, acl_set_fd, acl_set_file, acl_set_permset, acl_set_qualifier, acl_set_tag_type, acl_size, acl_to_text, acl_valid. - Most libacl extensions now implemented, too: New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error, acl_extended_fd, acl_extended_file, acl_extended_file_nofollow, acl_from_mode, acl_get_perm, acl_to_any_text. - First implementation of pthread_barrier/pthread_barrierattr functions. New APIs: pthread_barrierattr_init, pthread_barrierattr_setpshared, pthread_barrierattr_getpshared, pthread_barrierattr_destroy, pthread_barrier_init, pthread_barrier_destroy, pthread_barrier_wait. - Enabled console reports requested by escape sequences: Requesting primary and secondary device attributes, requesting cursor position report; see https://cygwin.com/ml/cygwin-patches/2012-q3/msg00019.html - New APIs: clog10, clog10f, nexttoward, nexttowardf, nexttowardl. - Add missing long double functions. New APIs: acoshl, acosl, asinhl, asinl, atan2l, atanhl, atanl, cacoshl, cacosl, cargl, casinhl, casinl, catanhl, catanl, ccoshl, ccosl, ceill, cexpl, clog10l, clogl, conjl, copysignl, coshl, cosl, cpowl, cprojl, csinhl, csinl, csqrtl, ctanhl, ctanl, dreml, erfcl, erfl, exp10l, exp2l, expl, expm1l, fabsl, fdiml, floorl, fmal, fmaxl, fminl, fmodl, frexpl, ilogbl, isinfl, isnanl, ldexpl, lgammal, lgammal_r, llroundl, log10l, log1pl, log2l, logbl, logl, lroundl, modfl, nearbyintl, nextafterl, pow10l, powl, remainderl, remquol, roundl, scalbl, scalblnl, scalbnl, sincosl, sinhl, sinl, tanhl, tanl, tgammal, truncl. - New header: cpio.h. What changed: - - Including now *only* includes the POSIX ACL API. To include the old Solaris API, include . - In calls to chmod treat ACLs with extra ACEs *only* for Admins and SYSTEM like a trivial ACL. - Bump POSIX option macros to POSIX.1-2008. - Profiling data, specifically pc sampling, now covers all threads of a program and not just the main thread. Environment variable GMON_OUT_PREFIX enables multiple gmon.out files to preserve profiling data after fork or from multiple program runs. - Feature test macros, which control which symbols are exposed in the standard headers, have been completely overhauled for compatibility with glibc. - The isinf, isinff, and isinfl functions are signed, returning -1 for negative infinity for compatibility with glibc. Bug Fixes - - Fix potential hang when using LoadLibraryEx(LOAD_LIBRARY_SEARCH_SYSTEM32). Reported and tested via IRC. - Fix a bug in ACL handling which might result in a spurious extra entry for the primary group. Self-observed. - printf(3): Handle multibyte decimal point in field size computation. Addresses: https://cygwin.com/ml/cygwin/2016-02/msg00014.html - cygwin_conv_path: Always preserve trailing backslashes in conversion to POSIX paths. Addresses: https://cygwin.com/ml/cygwin/2016-01/msg00480.html - Make buffered console characters visible to select(). Addresses: https://cygwin.com/ml/cygwin/2014-12/msg00118.html - Always report relocation problems, not only in debug DLL. Addresses: https://cygwin.com/ml/cygwin/2016-02/msg00147.html - Don't spill network credentials of privileged user changing the user context via setuid method 1 (https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1) into user session. Addresses: https://cygwin.com/ml/cygwin/2016-02/msg00101.html - Fix bug in setvbuf resulting in overwriting data in line buffered IO when writing aft
Re: cygwin 2.5.0-0.12 questions, vim and nextafterl()
On Apr 6 13:07, Tim Prince wrote: > 1) vim usually hangs if run under bash, but works fine under mintty > (same in previous snapshot) There's a patch in git master which seems to fix this problem. I'll release a 0.13 RSN. > 2) gcc testsuite cases which attempt to link nextafterl() have continued > failing as before. Did you update the cygwin-devel package as well? This: #include int main () { nextafterl (1.0L, 2.0L); } works with cygwin-devel-2.5.0-0.12. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
cygwin 2.5.0-0.12 questions, vim and nextafterl()
1) vim usually hangs if run under bash, but works fine under mintty (same in previous snapshot) 2) gcc testsuite cases which attempt to link nextafterl() have continued failing as before. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Home directory has blank space, X resources not recognized
> So I have moved my Cygwin ~ (home) directory to that folder. I > configured nsswitch.conf as follows: > > db_home: /cygdrive/c/Users/reisert/Box%_Sync/Home > > Most things are working. However, my Xterms are coming up in the > default 80x24 format with black text on a white background. The Xwin > server does not seem to recognize my ~/.xserverrc file which contains > simply: I did not state this correctly. I should have written: The Xwin server does not seem to recognize my ~/.Xresources file. I can do this from an xterm: xrdb ~/.Xresources Then my X resources will get loaded properly. -- Jim Reisert AD1C, , http://www.ad1c.us -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Home directory has blank space, X resources not recognized
Hi, My employer is making us use Box Sync for backup. We have to move all directories we want backed up into the Box Sync folder. So I have moved my Cygwin ~ (home) directory to that folder. I configured nsswitch.conf as follows: db_home: /cygdrive/c/Users/reisert/Box%_Sync/Home Most things are working. However, my Xterms are coming up in the default 80x24 format with black text on a white background. The Xwin server does not seem to recognize my ~/.xserverrc file which contains simply: exec /usr/bin/XWin -notrayicon "$@" It does appear that my ~/.bashrc is executing normally. What can I do to fix this? -- Jim Reisert AD1C, , http://www.ad1c.us -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Noto fonts missing from cygwin
On 4/6/2016 7:36 AM, David Boerschlein wrote: It seems the "noto" fonts are missing from the Cygwin LaTeX distribution. I am using the "mirrors.kernel.org" CTAN (https://www.ctan.org/tex-archive/fonts/noto?lang=en) says they are supposed to be in TeX Live. I will be updating TeX Live within a week or so, at which point the noto fonts will be in the texlive-collection-fontsextra package. The update will include the tlmgr utility, which you will be able to use to install just noto (if you don't want the whole fontsextra collection) in a texmf tree in your home directory. Ken Brown Cygwin's TeX Live maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1
Hi, On Wed, Apr 6, 2016 at 1:42 PM, Marco Atzeri wrote: > On 06/04/2016 11:32, Ismail Donmez wrote: >> >> Hi, >> >> On Wed, Apr 6, 2016 at 12:22 PM, Marco Atzeri >> wrote: >>> >>> A counter example: >>> >>> http://chbrauner.blogspot.de/2014/02/mutt-compiled-against-ncurses-and.html >>> >>> try and let me know >> >> >> I am not using a mutt colorscheme but a mintty one which mutt fails to >> render. I will, however, try the change but a quote from the page >> >> "The solution is to replace a lot of the very specific color >> specifications of the colorscheme by the value default. " >> >> This proves the point that mutt is unable to use 256-color specifications. >> >> Thanks, >> Ismail > > > ncurse can handle 256 color. > I doubt that mutt is different from other programs. > > > which TERM variable are you using ? > > $ TERM="xterm" > $ tput colors > 8 > > $ TERM="xterm-256color" > $ tput colors > 256 My TERM is also xterm-256color but however that won't matter because looking at mutt-1.6.0/color.c I see: #ifdef USE_SLANG_CURSES static char *get_color_name (char *dest, size_t destlen, int val) { static const char * const missing[3] = {"brown", "lightgray", "default"}; int i; [...] #endif and similar functions. So looks like "some" color functionality depends on slang. Regards, ismail -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Package choosing algorithm ... more clarification
For those interested, see attached file (chooser_overview.txt). Regards, Henrichooser_overview.txt: 2016-04-05 // Another attempt to create an overview ... = precondition - assume a "database" which reflects the info from setup.ini ... (packagedb::packages) - it list each package and every version of that pkg ... - this database even tells us what version has been installed if that is the case (reflecting installed.db) - furthermore we (setup.exe) are able to ascertain whether the tarball, associated with a version, is available or not -- the source code of setup.exe uses the term "accessible" for availability = D w/o I (Download without Installing) - setup.exe should show us ALL the pkgs and every version of that pkg ... - assume all tarballs are available (stable mirror) = I f LD (Install from Local Directory) - setup.exe should show us the installed pkgs and the versions of that pkg that are not installed, but are available in the repo ... - the tarball of an installed version may or may not be available in the repo ... - furthermore it should show us each non-installed pkg if at least one version of that pkg is available in the repo ChooserPage::OnInit has the following call flow in both cases (D w/o I and I f LD) ChooserPage::OnInit packagemeta::ScanDownLoadedFiles packagedb::setExistence packagemeta::trustp(true, ... = D w/o I // (pkg.installed == version) => pkg is installed - ScanDownloadedFiles # method name is a misnomer here ! (pkg is installed || a version is acccessible) => erase version from packagemeta.versions - here all versions will be kept (stable mirror) in packagemeta.versions - setExistence ! (pkg is installed || a version is acccessible) => erase pkg from packages - the test whether the pkg is installed or not, is useless here ... - ... as all pkgs (i.e. all versions of each pkg) are available (accessible): UNmodified database End result: setup.up will show us all the pkgs and every version of each pkg ... = I f LD // (pkg.installed == version) => pkg is installed - ScanDownloadedFiles ! (pkg is installed || a version is accessible) => erase version from packagemeta.versions - not-installed pkgs: available versions will be kept in packagemeta.versions - installed pkgs: the installed version will be kept - installed pkgs: non-available versions will be removed from packagemeta.versions - setExistence ! (pkg is installed || a version is accessible) => erase pkg from packages - a not-installed pkg, of which at least one version is available: this pkg will be kept in the database (versions will show the available versions) - installed pkgs: these pkgs will be kept in the database (versions will show the installed version and available versions that are not installed) End result: setup.exe will show us all the available versions of each pkg, if it has not been installed yet, and all the pkgs (both the installed version and available versions that are not installed) which have been installed ... - Ignoring the issue of source tarballs ... Each "package entry" (p, c and/or t) in setup.ini is represeneted by an object of type packagemeta ... - class variable packages (of type packagedb): std::map or: a mapping from a packagename to a pointer to an object of type packagemeta A simplified view of the data members of class packagemeta is as follows: - prev of type packageversion - curr ditto - exp ditto - installed ditto - versions of type std::set - prev, curr, exp and installed reflect the "static" part of a "package entry": these data members reflect the info from both setup.ini and installed.db ... "Nullifying" these data members, as currently happens in ScanDownLoadedFiles is ... stupid? versions tells what versions of the pkg are available (accessible); versions is managed by ScanDownLoadedFiles ... Attempting to grasp the general flow of computation: packagemeta::ScanDownLoadedFiles => for each pkg // from packagedb::packages for each version // from metapackage::versions [ .scan() ] // packageversion::scan() -- simplified! // (pkg.installed == version) => pkg is installed if ! (pkg is installed || version is accessible) // packagemeta::installed, packageversion::accessible() erase version from versions Note: a version is NOT erased if the version is installed OR if the version is available packagemeta::accessible => // called by setExistence for each version // from metapackage::versions if version is accessible // packageversion::accessible() return true // pkg is available in (local) repo return false packageversion::accessible => _packageversion::accessible => ... packagedb::setExistence for each pkg // from packagedb::packages // (pkg.installed == version) => pkg is installed if ! (pkg is installed || a version is accessible) // packagemeta::installed, packagemeta::accessible() er
Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1
On 06/04/2016 11:32, Ismail Donmez wrote: Hi, On Wed, Apr 6, 2016 at 12:22 PM, Marco Atzeri wrote: A counter example: http://chbrauner.blogspot.de/2014/02/mutt-compiled-against-ncurses-and.html try and let me know I am not using a mutt colorscheme but a mintty one which mutt fails to render. I will, however, try the change but a quote from the page "The solution is to replace a lot of the very specific color specifications of the colorscheme by the value default. " This proves the point that mutt is unable to use 256-color specifications. Thanks, Ismail ncurse can handle 256 color. I doubt that mutt is different from other programs. which TERM variable are you using ? $ TERM="xterm" $ tput colors 8 $ TERM="xterm-256color" $ tput colors 256 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Package choosing algorithm ...
Title: Re: Package choosing agorithm ... Hi Corinna, (Of course I am formally addressing the project leader, but Achim, Jon, Yaakov, others? are welcome to correct me if I am wrong below). D w/o I = Download without Install I f LD = Install from Local Directory As a reminder: I reported that a new test release of Cygwin is NOT offered for install (having installed the previous test release) in my case. https://cygwin.com/ml/cygwin/2016-03/msg00425.html Relevant in my case is: - I am not using a local mirror ... - but a "partially populated Local Directory" - I do not invoke setup.exe with the -m option - my local directory does not have the current release of Cygwin As you replied "it works for me" and "not using the -m option should not make a difference", I decided to study the source code of setup.exe. As I had never seen the source code of setup before, I started my study where you had "left off" modifying (about a year ago). Subsequently, I reported back to the list, announcing that I found the bug, but was not sure I had. https://cygwin.com/ml/cygwin/2016-03/msg00480.html I was wrong. My patch did work, but for the wrong reasons. So does your modification of packagemeta::trustp ... Here is another attempt of mine (attempt? I seriously doubt whether there is someone which fully understands the source code in all its details ...) You will find 2 patch files attached. These patch files modify (correct): 1. packagemeta::ScanDownLoadedFiles and 2. packagemeta::trustp (yes, I do realize, that this correction to setup, is NOT important enough to most of you - using a local mirror and all that; consequently, do whatever you like with my post - I am merely providing info to the list). My argument for the correction is as follows: - packagedb::packages, a class variable, is the "package database" that is used by setup. - basically, it is a list of pairs (mapping between the packagename and its entry in setup.ini) (one where installed.db has been "integrated"). - formally: - typedef std::map packagecollection; - static packagecollection packages; - packagemeta is the type that describes a "package entry" from setup.ini - an object of type packagemeta does not only describe the previous, current and experimental (if applicable) lines from a package entry in setup.ini, it also describes the installed version of a package, as if installed.db is part of setup.ini. -- - bottom-line: the prev, curr, exp and installed data member of packagemeta are "static": these data members represent the info from setup.ini (and installed.db) and they should never be "nullified". - yet, that is exactly what happens in metapackage::ScanDownLoadedFiles. -- - packagemeta ALSO has a "not so static" data member, called versions; like packages, the contents of versions is "variable" - versions, a set of type packageversion, contains the versions of the package that are available (the source code speaks about "accessible") - available (in my simplistic view) means whether or not the tarball is present in the (local) repo - unfortunately, though versions specifies which versions are available, it does not tell us whether the previous, current or experimental version of a package is available or not -- - bottom-line: version numbers can be compared if that info is present in setup.ini; however, although the info may be present, it does not tell us that the associated tarball is available (neither does versions). - consequently, metapackage:trustp does not only have to verify that setup.ini has the required info, it also has to verify that the tarball is available, before it can give the "go-ahead". Lastly: No, I have not tested (been able) my modification for each possible configuration out there (for instance, I do not install source tarballs). Regards, Henri =diff --git a/package_meta.cc b/package_meta.cc index 34ff78c..ff787a8 100644 --- a/package_meta.cc +++ b/../src2/package_meta.cc @@ -683,15 +683,18 @@ packagemeta::ScanDownloadedFiles (bool mirror_mode) /* For local installs, if there is no src and no bin, the version * is unavailable */ - if (!i->accessible () && !pkgsrcver.accessible () - && *i != pkg.installed) + if (*i != pkg.installed + && !i->accessible () && !pkgsrcver.accessible () ) { +// Henri: innihilate the info that has been collected from setup.ini? DO NOT! + #if 0 if (pkg.prev == *i) pkg.prev = packageversion (); if (pkg.curr == *i) pkg.curr = packageversion (); if (pkg.exp == *i) pkg.exp = packageversion (); + #endif pkg.versions.erase (i++); /* For now, leave the source version alone */ } diff --git a/package_meta.h b/package_meta.h index b24d4fc..3d2b775 100644 --- a/package_meta.h +++ b/../src2/package_meta.h @@ -105,12 +105,14 @@ p
Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1
Hi, On Wed, Apr 6, 2016 at 12:22 PM, Marco Atzeri wrote: > A counter example: > http://chbrauner.blogspot.de/2014/02/mutt-compiled-against-ncurses-and.html > > try and let me know I am not using a mutt colorscheme but a mintty one which mutt fails to render. I will, however, try the change but a quote from the page "The solution is to replace a lot of the very specific color specifications of the colorscheme by the value default. " This proves the point that mutt is unable to use 256-color specifications. Thanks, Ismail -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1
On 06/04/2016 11:13, Ismail Donmez wrote: On Wed, Apr 6, 2016 at 11:59 AM, Marco Atzeri wrote: On 05/04/2016 18:35, Ismail Donmez wrote: Hi, On Tue, Apr 5, 2016 at 6:03 PM, Marco Atzeri wrote: New versions 1.6.0-1 of mutt is available in the Cygwin distribution: CHANGES Last upstream release. First 1.6.x Thanks for the update! Could you maybe build it with slang? That way mutt can support 256 colors. Regards, ismail -- I don't find anything in the mutt documentation that says that 256 color requires slang. Have you some reference ? Yes, https://superuser.com/questions/695867/not-able-to-use-solarized-in-mutt I have the same problem and compiling mutt against slang fixes the issue. Thanks. A counter example: http://chbrauner.blogspot.de/2014/02/mutt-compiled-against-ncurses-and.html try and let me know Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1
On Wed, Apr 6, 2016 at 11:59 AM, Marco Atzeri wrote: > > > On 05/04/2016 18:35, Ismail Donmez wrote: >> >> Hi, >> >> On Tue, Apr 5, 2016 at 6:03 PM, Marco Atzeri >> wrote: >>> >>> New versions 1.6.0-1 of >>> >>>mutt >>> >>> is available in the Cygwin distribution: >>> >>> CHANGES >>> Last upstream release. First 1.6.x >> >> >> Thanks for the update! Could you maybe build it with slang? That way >> mutt can support 256 colors. >> >> Regards, >> ismail >> >> -- > > > I don't find anything in the mutt documentation that says > that 256 color requires slang. > Have you some reference ? Yes, https://superuser.com/questions/695867/not-able-to-use-solarized-in-mutt I have the same problem and compiling mutt against slang fixes the issue. Thanks. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1
On 05/04/2016 18:35, Ismail Donmez wrote: Hi, On Tue, Apr 5, 2016 at 6:03 PM, Marco Atzeri wrote: New versions 1.6.0-1 of mutt is available in the Cygwin distribution: CHANGES Last upstream release. First 1.6.x Thanks for the update! Could you maybe build it with slang? That way mutt can support 256 colors. Regards, ismail -- I don't find anything in the mutt documentation that says that 256 color requires slang. Have you some reference ? Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How can I try a newly build package locally?
thoni56 junovagen.se> writes: > We use CMake so there is a packager available, and it's easy to create a > .bz2 package. Cygwin packages have moved to .tar.xz for quite a while. Also, please build and package with cygport. > Once I've created the package, how can I try it locally? In Linux this can > easily be done with dpkg, but is there a way to use the Cygwin package > installer so that it picks up a local package? You can point setup.exe at a local directory, but it'd be preferrable if you created a local package repository with genini (you can then use it as an additional repo during install). Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple