SSH access to desktop

[Kevin Layer]

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

[Corinna Vinschen]

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 

Re: cygwin 2.5.0-0.12 questions, vim and nextafterl()

[Corinna Vinschen]

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()

[Tim Prince]

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

[Jim Reisert AD1C]

> 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

[Jim Reisert AD1C]

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

[PATCH] cygport: propagate exit status

[Jon Turney]

The commands compile, check, inst, package and all currently return the exit
status of the last command in the pipeline, tee, which they pass their
output through.

I guess we don't want to just turn on pipefail, since pkg_pkg very carefully
turns it on and off in a particular place, so use $PIPESTATUS to propagate
the much more interesting exit status of the command who's output is tee'd.

Signed-off-by: Jon Turney 
---
 bin/cygport.in | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/bin/cygport.in b/bin/cygport.in
index b032b8b..4abca88 100644
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -561,19 +561,19 @@ do
__log_init ${compilelog};
__check_depends && \
src_compile 2>&1 | tee -a ${compilelog};
-   _status=$?;
+   _status=${PIPESTATUS[0]};
;;
check|test)
__stage Testing;
__log_init ${checklog};
src_test 2>&1 | tee -a ${checklog};
-   _status=$?;
+   _status=${PIPESTATUS[0]};
;;
inst*)
__stage Installing;
__log_init ${installlog};
(__prepinstalldirs && src_install && __src_postinst) 
2>&1 | tee -a ${installlog};
-   _status=$?;
+   _status=${PIPESTATUS[0]};
;;
postinst*)
__src_postinst;
@@ -603,7 +603,7 @@ do
__stage Packaging;
__log_init ${pkglog};
(__pkg_binpkg && __pkg_pkgcheck && __pkg_srcpkg && 
__pkg_dist) 2>&1 | tee -a ${pkglog};
-   _status=$?;
+   _status=${PIPESTATUS[0]};
;;
diff|mkdiff|mkpatch)
__pkg_diff;
@@ -613,7 +613,7 @@ do
__stage Uploading;
__log_init ${uploadlog};
(__pkg_upload) 2>&1 | tee -a ${uploadlog};
-   _status=$?;
+   _status=${PIPESTATUS[0]};
;;
announce)
__stage "Preparing announcement";
@@ -629,10 +629,13 @@ do
__log_init ${compilelog} && \
__check_depends && \
__stage Compiling && src_compile 2>&1 | tee -a 
${compilelog} && \
+   test ${PIPESTATUS[0]} -eq 0 && \
__log_init ${installlog} && \
__stage Installing && (__prepinstalldirs && src_install 
&& __src_postinst) 2>&1 | tee -a ${installlog} && \
+   test ${PIPESTATUS[0]} -eq 0 && \
__log_init ${pkglog} && \
-   __stage Packaging && (__pkg_binpkg && __pkg_pkgcheck && 
__pkg_srcpkg && __pkg_dist) 2>&1 | tee -a ${pkglog}
+   __stage Packaging && (__pkg_binpkg && __pkg_pkgcheck && 
__pkg_srcpkg && __pkg_dist) 2>&1 | tee -a ${pkglog} && \
+   test ${PIPESTATUS[0]} -eq 0
_status=$?;
;;
help)
-- 
2.7.4

Re: Noto fonts missing from cygwin

[Ken Brown]

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: Fwd: Re: [PATCH] Be truthful about reporting whether readahead is available

[Johannes Schindelin]

Hi Thomas,

On Tue, 5 Apr 2016, Thomas Wolff wrote:

> > > Betreff: Re: [PATCH] Be truthful about reporting whether readahead is
> > > available
> > >
> > > Thomas?
> > >
> > > Any input?
> > >
> Yes, let's fix the patch so. Sorry for the flaw.

No big deal, thanks for the ACK!

Ciao,
Johannes

Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1

[Ismail Donmez]

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

[Houder]

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, 

Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1

[Marco Atzeri]

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 ...

[Houder]

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
+++ 

Re: [ANNOUNCEMENT] Updated: mutt-1.6.0-1

[Ismail Donmez]

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

[Marco Atzeri]

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

[Ismail Donmez]

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

[Marco Atzeri]

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?

[Achim Gratz]

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