Re: TL;DR: About Distros, packages, Cygwin, volunteers

[Brian Inglis]

On 2021-01-04 21:37, Brian Inglis wrote:

On 2021-01-04 08:11, Marco Atzeri via Cygwin wrote:

On 04.01.2021 13:21, tommie.k...@alverservices.com wrote:

But im struggling to see how I can upgrade openssl >1.1.1f
Compliance checks state that we must have a more up to date version, I know
that it exists (1.1.1g, 1.1.1h, 1.1.1i)


https://cygwin.com/packages/summary/openssl.html

the last one available on cygwin is 1.1.1f


But I can only seem to upgrade to 1.1.1f in Cygwin  - is there a new upgrade
package for Cygwin/Openssl coming in the near future?


It will depends on the maintainer (Corinna) availability.
Maybe after the holiday season


What are your compliance timing constraints in terms of releases and time?
I see Cygwin openssl is now 3 versions and 9 months behind the latest.

If you have a compliance timing issue, your organization will have to take 
responsibility for meeting your compliance needs, either by having staff or 
contracting others to meet those needs, by building packages more up to date 
than those available from the distros you use.


All recent, and certainly all important, Cygwin packages use the common cygport 
package build and maintenance system, which takes a lot of the burden off the 
rote tasks required of maintainers to update packages to newer versions.
Any package user may also do so by installing the cygport package and all its 
toolchain dependencies, downloading the package sources, most of which contain a 
.cygport file, or cloning the package repo:


https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/openssl.git;a=summary

to get the .cygport file, change the package version within to the 
latest, and within that directory run:


 $ cygport .cygport download all check

to download all source and patch files and build the package.

In some cases, you may need to install the package source to get the patch 
sources if they have not been pushed to the package repo (as there is not really 
much in the way of common policies or practices about that as yet), or search 
and find the online locations of distros patches.


You may also have to tweak the .cygport files to skip patches already 
applied to the upstream package so redundant, tweak patches that are still 
required but no longer apply without error, drop patches as the package has been 
tweaked in some other way so they are no longer required, or make your own 
patches to get the package to build under Cygwin.


You will also have to install the development versions of libraries required by 
packages, often named lib/...-devel, and those available on Cygwin which support 
additional functionality provided by the package, which may have to be 
explicitly configured into the build specified in the .cygport files.


Some background and help is available in the pages under Contributing on the 
home page, in the archives of the cygwin-apps list, by searching online, and 
asking on this list, if nothing else works.


TL;DR: About Distros, packages, Cygwin, volunteers

Most distros do not have the current versions of most packages in their stable 
releases, as they have to do rebuilds of all dependent packages, and regression 
tests of all the packages they are dependent on, apply patches for issues and 
rerun regression tests for those, regardless of security issue severity and 
urgency, even though they have many full time staff available to carry out the 
processes.


For important packages, Cygwin maintainers often monitor the status of their 
packages in other distros to see how stable new versions are, how many 
regressions or issues have been found in testing, how many patches have been 
applied, and their test status, as they are all volunteers working in their 
spare time.


I know a number of Cygwin maintainers monitor the status and use many of the 
patches applied to Fedora, as they have access to that due to their full time 
day jobs at Redhat and/or personal use of those systems at home, and others may 
also monitor and use patches from Debian, Gentoo, OpenSuSE, and other distros 
with funded infrastructure processes, staff to perform extensive testing, and 
develop their own patches for issues found testing on their distros.


One of the biggest issues in volunteer maintained distros like Cygwin is when 
dependent packages have to be updated to allow an important package to be 
updated, and some of those dependent packages have issues requiring a lot of 
work to resolve to get them to build on Cygwin, sometimes requiring the 
expertise of the official maintainer, who may not have much time available due 
to real life issues.


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:

Re: OpenSSL

[Brian Inglis]

On 2021-01-04 08:11, Marco Atzeri via Cygwin wrote:

On 04.01.2021 13:21, tommie.k...@alverservices.com wrote:

But im struggling to see how I can upgrade openssl >1.1.1f
Compliance checks state that we must have a more up to date version, I know
that it exists (1.1.1g, 1.1.1h, 1.1.1i)


https://cygwin.com/packages/summary/openssl.html

the last one available on cygwin is 1.1.1f


But I can only seem to upgrade to 1.1.1f in Cygwin  - is there a new upgrade
package for Cygwin/Openssl coming in the near future?


It will depends on the maintainer (Corinna) availability.
Maybe after the holiday season


What are your compliance timing constraints in terms of releases and time?
I see Cygwin openssl is now 3 versions and 9 months behind the latest.

If you have a compliance timing issue, your organization will have to take 
responsibility for meeting your compliance needs, either by having staff or 
contracting others to meet those needs, by building packages more up to date 
than those available from the distros you use.


All recent, and certainly all important, Cygwin packages use the common cygport 
package build and maintenance system, which takes a lot of the burden off the 
rote tasks required of maintainers to update packages to newer versions.
Any package user may also do so by installing the cygport package and all its 
toolchain dependencies, downloading the package sources, most of which contain a 
.cygport file, or cloning the package repo:


https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/openssl.git;a=summary

to get the .cygport file, change the package version within to the 
latest, and within that directory run:


$ cygport .cygport download all check

to download all source and patch files and build the package.

In some cases, you may need to install the package source to get the patch 
sources if they have not been pushed to the package repo (as there is not really 
much in the way of common policies or practices about that as yet), or search 
and find the online locations of distros patches.


You may also have to tweak the .cygport files to skip patches already 
applied to the upstream package so redundant, tweak patches that are still 
required but no longer apply without error, drop patches as the package has been 
tweaked in some other way so they are no longer required, or make your own 
patches to get the package to build under Cygwin.


You will also have to install the development versions of libraries required by 
packages, often named lib/...-devel, and those available on Cygwin which support 
additional functionality provided by the package, which may have to be 
explicitly configured into the build specified in the .cygport files.


Some background and help is available in the pages under Contributing on the 
home page, in the archives of the cygwin-apps list, by searching online, and 
asking on this list, if nothing else works.


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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: [ITA] libspectre-0.2.9-1

[Marco Atzeri via Cygwin-apps]

On 05.01.2021 00:29, Lemures Lemniscati via Cygwin-apps wrote:

On Mon, 4 Jan 2021 19:28:39 +0100, Marco Atzeri via Cygwin-apps

On 04.01.2021 17:37, Lemures Lemniscati via Cygwin-apps wrote:

On Tue, 05 Jan 2021 01:33:28 +0900, Lemures Lemniscati

ITA for libspectre, which has been maintained by Yaakov [1].



``Now, the latest upstream of libspectre is 0.2.9 [2].''



Now I've added them, rebuilt,
and placed new packages to the same URLs.

Thank you for review.

Regards,

Lem



GTG

Thanks
Marco

Re: Is it possible to define the root directory in a cross compiled program

[Brian Inglis]

On 2021-01-04 18:34, Roger Kaufman wrote:
When I cross compile the following program, opening /dev/null fails and instead 
the whole install path of /cygwin64/dev/null is visible.


Is there a way to make fopen respect / as the root directory in a cross compiled 
program for windows?


example output...

Roger@interocitor:~
$ x86_64-w64-mingw32-g++ -o writenull.exe write2null.cc

Roger@interocitor:~
$ writenull.exe
/dev/null did not succeed

Roger@interocitor:~
$ gcc -o writenull write2null.cc

Roger@interocitor:~
$ writenull
/cygwin64/dev/null did not succeed

C Code that was compiled...

#include 

int main(int argc, char **argv)
{
   FILE *errfile1 = fopen("/dev/null", "w");
   if (!errfile1) // must be a valid pointer
     errfile1 = stderr;

   FILE *errfile2 = fopen("/cygwin64/dev/null", "w");
   if (!errfile2) // must be a valid pointer
     errfile2 = stderr;

   fprintf(errfile1, "/dev/null did not succeed\n");
   fprintf(errfile2, "/cygwin64/dev/null did not succeed\n");

   return 0;
}


It's a Windows program - it can do whatever you program it to do!
On Windows the device is NUL, the root is the drive root C:\,
and anything else depends on the Windows subsystem.

To do otherwise you have to program it to emulate the Cygwin emulation,
or build it as a Cygwin program using the Cygwin toolchain.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
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

Is it possible to define the root directory in a cross compiled program

[Roger Kaufman]

When I cross compile the following program, opening /dev/null fails and 
instead the whole install path of /cygwin64/dev/null is visible.


Is there a way to make fopen respect / as the root directory in a cross 
compiled program for windows?


example output...

Roger@interocitor:~
$ x86_64-w64-mingw32-g++ -o writenull.exe write2null.cc

Roger@interocitor:~
$ writenull.exe
/dev/null did not succeed


Roger@interocitor:~
$ gcc -o writenull write2null.cc

Roger@interocitor:~
$ writenull
/cygwin64/dev/null did not succeed


C Code that was compiled...

#include 

int main(int argc, char **argv)
{
  FILE *errfile1 = fopen("/dev/null", "w");
  if (!errfile1) // must be a valid pointer
    errfile1 = stderr;

  FILE *errfile2 = fopen("/cygwin64/dev/null", "w");
  if (!errfile2) // must be a valid pointer
    errfile2 = stderr;

  fprintf(errfile1, "/dev/null did not succeed\n");
  fprintf(errfile2, "/cygwin64/dev/null did not succeed\n");

  return 0;
}
--
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: [ITA] libspectre-0.2.9-1

[Lemures Lemniscati via Cygwin-apps]

On Mon, 4 Jan 2021 19:28:39 +0100, Marco Atzeri via Cygwin-apps
> On 04.01.2021 17:37, Lemures Lemniscati via Cygwin-apps wrote:
> > On Tue, 05 Jan 2021 01:33:28 +0900, Lemures Lemniscati
> >> ITA for libspectre, which has been maintained by Yaakov [1].
> >>
> >> Now, the latest upstream of exif is 0.6.22 [2].
> >
> > This line should be...
> >
> > ``Now, the latest upstream of libspectre is 0.2.9 [2].''
> >
> some typing error ?
> 
> $ cygport libspectre.cygport all
> /pub/tmp/libspectre-0.2.9-1.src/libspectre.cygport: line 11: 
> freedesktop.sub.experimental: No such file or directory

I forgot to add these lines:

SRC_URI+="
  freedesktop.sub.experimental
"

Now I've added them, rebuilt, 
and placed new packages to the same URLs.



Thank you for review.

Regards,

Lem

Re: Setting env var CYGWIN for Cygwin service?

[Bill Stewart]

On Mon, Jan 4, 2021 at 3:08 PM Oleksandr Gavenko wrote:

> /usr/bin/exim-config has line with:
>
>   cygrunsrv -I exim -p /usr/bin/exim -e CYGWIN="${cygenv}" ...
>
> So it is the answer (as pointed by others).
>
> Still "procexp" doesn't show anything else besides PATH/WINDIR for "exim"
> process. It can be that cygrunsrv passed env vars in some Cygwin *magical 
> way*.
>
> Cannot confirm this, attempt to read /proc/X/environ gives "". There
> is no problem to read "environ" for other Cygwin processes.

I have observed the same thing. The environment variable setting
exists in the 
HKLM\System\CurrentControlSet\Services\\Parameters\Environment
registry subkey, but Process Explorer does not show the environment
variable in the list of environment variables for the process.

I have not looked at the code, but it seems that environment variables
specified in this way are not propagated to the environment block for
the process but instead are read some other way.

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

Noticed that mintty starts non-login bash with "Win+R mintty Enter".

[Oleksandr Gavenko via Cygwin]

I interact with Cygwin via mintty launched as "Win+R mintty Enter".

During first launch of "exim-config" script existed with an error:

  /usr/bin/exim-config: line 447: USER: unbound variable

After looking into docs I got that mintty should be launched with a parameter 
"-".

Probably it was always that way.



Checking POSIX standard on what might be defined in login shell:

https://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html (1997)
https://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd_chap08.html (2004)

I noticed that USER is mentioned but LOGNAME is not only mentioned by
description is given:

  The system shall initialize this variable at the time of login to be the
  user's login name.

Cygwin's /etc/profile has:

  # Set the user id
  USER="$(/usr/bin/id -un)"

but there is nothing for LOGNAME... Shouldn't /etc/profile set LOGNAME too?

-- 
http://defun.work/

--
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: Setting env var CYGWIN for Cygwin service?

[Oleksandr Gavenko via Cygwin]

On 2020-12-30, Oleksandr Gavenko via Cygwin wrote:

> What way can I pass env var "CYGWIN" to the Cygwin service?

Today I reinstalled Cygwin & Exim.

"exim-config" script asked me:

  Enter the value of CYGWIN for the daemon: []

/usr/bin/exim-config has line with:

  cygrunsrv -I exim -p /usr/bin/exim -e CYGWIN="${cygenv}" ...

So it is the answer (as pointed by others).

Still "procexp" doesn't show anything else besides PATH/WINDIR for "exim"
process. It can be that cygrunsrv passed env vars in some Cygwin *magical way*.

Cannot confirm this, attempt to read /proc/X/environ gives "". There
is no problem to read "environ" for other Cygwin processes.

-- 
http://defun.work/

--
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: [cygwin] DD bug fails to wipe last 48 sectors of a disk

[Jason Pyeron]

> From: Hashim Aziz
> Sent: Monday, January 4, 2021 3:16 PM
>
> > From: Jason Pyeron 
> > Sent: 30 December 2020 1:35 AM
> > To: mailto:cygwin@cygwin.com 
> > Subject: RE: [cygwin] DD bug fails to wipe last 48 sectors of a disk
> >
> > > -Original Message-
> > > From: Brian Inglis
> > > Sent: Tuesday, December 29, 2020 12:55 PM
> > >
> > > On 2020-12-28 19:41, Jason Pyeron wrote:
> > > > On Monday, December 28, 2020 7:46 PM, Hashim Aziz wrote:
> > > >> On 23 June 2020 8:33 PM, Brian Inglis wrote:
> > > >>> I don't have the facilities to test, and there appear to be *NO* 
> > > >>> Windows
> > > >>> documentation details on error condition handling, but my suspicion is
> > > >>> that Unix reads and writes fail only *AFTER* reading or writing at the
> > > >>> end of the device, but Windows reads and writes extents may be checked
> > > >>> and failed *BEFORE* reading or writing any data near the end of the
> > > >>> device.
> > > >>> If the actual Windows error code returned is generic, Cygwin would 
> > > >>> need
> > > >>> to pre-check the device size as Windows does, and reduce read and 
> > > >>> write
> > > >>> sizes to the allowed maximum at the end of the device.
> > >
> > > >> That's very helpful, thank you. Do you know if any more work has been 
> > > >> done
> > > >> to attempt to fix this bug, and whether it's likely to be fixed anytime
> > > >> soon? It's crazy that such a commonly used command leaves so much data
> > > >> unwiped unbeknown to so many users, it's a very serious security hole 
> > > >> and
> > > >> the sooner it can be fixed the better.
> > >
> > > > Have you tried iflag=fullblock ? This causes special handling.
> > >
> > > >> I didn't previously see this email, but the point is that this is a 
> > > >> bug -
> > > >> dd should not require first making calculations based on the size of 
> > > >> each
> > > >> drive or using the smallest possible block size (and hence taking a
> > > >> ridiculous amount of time) in order to do what
> > >
> > > > Do you have any metrics that it is faster, by any meaningful amount? If 
> > > > so I
> > > > would be very interested in mitigating it, but I suspect not the actual
> > > > case.
>
> That dd is faster with a block size of something large like 4M vs the default 
> of 512 or 1024 has 
> long been attested to by anyone who has used these tools on large drives - 
> here's just 
> one https://superuser.com/a/234241/323079 from SuperUser.

But I just copied 1TB in 2 hours on Cygwin dd using a GCD calculated block 
size. No one is arguing that 512 is slow, the issue seems to be you do not like 
using a whole multiple of the actual drive size, and are insisting on using a 
non-divisible block size.

> >
> > > Could you please state explicitly, how many 
> > > bytes/sectors/blocks/pages/clusters
> > > of what size you expect to get written, and how many
> > > bytes/sectors/blocks/pages/clusters of what size are actually written?
> >
> > As mentioned in the original email and in 
> > https://superuser.com/a/1509903/323079, I have confirmed that everything 
> > but the last 48 sectors of the drive are wiped on both a 1TB HDD and a 
> > 128GB SSD, by inspecting the disks themselves with a hex editor (opening 
> > the raw disks in HxD). As someone else said earlier, on both occasions this 
> > points to the very last block failing to write properly.
> > BUT, I want a clear test plan first, with clearly articulated issues 
> > BECAUSE I do not believe there are any issues actually existing.
> >
> > The best I can glean from the thread is
> >
> > 1. Cygwin is agedly breaking dd, but is also broken in the windows native 
> > dd [1]
> > 2. Using "correct" (as I have previously defined it e.g. [4]) values is both
> > 2.1. too slow on the write [2]
> > 2.2. inappropriately complicated of a process for the user
> > 3. It has been well investigated
> > 3.1. with a root cause was identified as a windows OS issue [3,5,6]
> > 3.2. with a mitigation [4,5]
> >
> > I am happy to spend time and money on 2.1.
> > I will not spend my time on dealing with 2.2 - except providing an example 
> > and documentation update for upstream.
>
> Isn't the entire purpose of Cygwin to have tools that behave as their 
> upstream equivalents do? 

Yes(ish), but the upstream has this issue to. As their documentation indicates 
- some OSes are not forgiving.

> Upstream dd has no problems running the same command without these issues,

You indicated that it (windows native dd) has the same issue, whereas on Linux 
(a different OS) behaves differently.

> and I'm sure upstream would agree on the serious security hole that leaving 
> behind the last 48 sectors of every disk is.

No this appears to be a user error - I do not have the issue, when I execute it 
correctly.

>
> The only logical conclusion to me here - and it seems bizarre to me that 
> there is any pushback against it at all - is to make Cygwin dd behave like 
> upstream dd does (however 

[PATCH] cygport use shallow clone for branches and tags

[Achim Gratz]

--8<---cut here---start->8---
Subject: [PATCH] cygclass/git.cygclass: use shallow clones for branches and 
tags also

---
 cygclass/git.cygclass | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index 1e3de23..f63cc5f 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -70,10 +70,17 @@ git_fetch() {
 
check_prog_req git
 
-   if ! defined GIT_TAG && ! defined GIT_BRANCH && ! defined GIT_REV
+   if ! defined GIT_REV
then
-   # fetching master/HEAD, so we don't need any history
+   # fetching master/HEAD, branch or tag, so we don't need any 
history
_depth="--depth 1"
+   if defined GIT_TAG
+   then
+   _depth+=" --branch ${GIT_TAG}"
+   elif defined GIT_BRANCH
+   then
+   _depth+=" --branch ${GIT_BRANCH}"
+   fi
fi
 
# T likely doesn't exist at this point, so create it first
-- 
2.29.2

--8<---cut here---end--->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [RFE] calm needs to know about ZStandard compressed archives

[Achim Gratz]

Jon Turney writes:
>> I think the right thing to do is to stop having actual packages for
>> OBSOLETES and just emit the obsoltes: hint instead.
>
> Yeah, this change to cygport should be made and we can turn off
> support for setup versions which don't understand the obsoletes: hint.

The obsolete hints are already generated for some time, so at least the
newer packages should have them.  The older packages would need to
retroactively get them (or keep their equally old obsoleteion packages
around still).

So I think this is what's left to do in cygport (untested, on top of my
to-upstream branch):

--8<---cut here---start->8---
>From 0491ea2934d83c656ba5dacf7f02c31f02b46a38 Mon Sep 17 00:00:00 2001
Subject: [PATCH] lib/pkg_pkg.cygpart: stop generating packages for obsoletions

---
 lib/pkg_pkg.cygpart | 46 -
 1 file changed, 46 deletions(-)

diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 2b2f8bc..80003e9 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -828,32 +828,6 @@ _EOF
warning "${pkg_hint[${n}]%.hint}.hint is missing";
fi
 
-   for obspkg in ${!pkg_obsoletes_var}
-   do
-   if [ ${obspkg} = ${PN} ]
-   then
-   obssubdir= ;
-   else
-   obssubdir=${obspkg};
-   fi
-
-   mkdir -p ${distdir}/${PN}/${obssubdir};
-   ${CYGPORT_TAR_CMD-tar -J} -cf 
${distdir}/${PN}/${obssubdir}/${obspkg}-${PVR}${CYGPORT_TAR_EXT-.tar.xz} 
--files-from /dev/null
-
-   __step "${pkg_name[${n}]} OBSOLETES: ${obspkg}"
-
-   cat > 
${distdir}/${PN}/${obssubdir}/${obspkg}-${PVR}.hint <<-_EOF
-category: _obsolete
-requires: ${pkg_name[${n}]}
-sdesc: "Obsoleted by ${pkg_name[${n}]}"
-ldesc: "The ${obspkg} package is obsolete.  Selecting this package for
-installation will cause the ${pkg_name[${n}]} package, which replaces this
-one, to be installed instead."
-${obssubdir:+external-source: ${PN}}
-${pkg_tag}
-_EOF
-   done
-
n+=1;
done
 
@@ -887,26 +861,6 @@ _EOF
fi
fi
 
-   for obspkg in ${!dbg_obsoletes_var}
-   do
-   mkdir -p ${distdir}/${PN}/${obspkg};
-   ${CYGPORT_TAR_CMD-tar -J} -cf 
${distdir}/${PN}/${obspkg}/${obspkg}-${PVR}${CYGPORT_TAR_EXT-.tar.xz} 
--files-from /dev/null
-
-   __step "${PN}-debuginfo OBSOLETES: ${obspkg}"
-
-   cat > ${distdir}/${PN}/${obspkg}/${obspkg}-${PVR}.hint 
<<-_EOF
-category: _obsolete
-requires: ${PN}-debuginfo
-sdesc: "Obsoleted by ${PN}-debuginfo"
-ldesc: "The ${obspkg} package is obsolete.  Selecting this package for
-installation will cause the ${PN}-debuginfo package, which replaces this
-one, to be installed instead."
-external-source: ${PN}
-${pkg_tag}
-_EOF
-   done
-   fi
-
# source package hint
if [ ! -f ${distdir}/${PN}/${PN}-${PVR}-src.hint ]
then
-- 
2.29.2
--8<---cut here---end--->8---



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITA] libspectre-0.2.9-1

[Marco Atzeri via Cygwin-apps]

On 04.01.2021 17:37, Lemures Lemniscati via Cygwin-apps wrote:

On Tue, 05 Jan 2021 01:33:28 +0900, Lemures Lemniscati

ITA for libspectre, which has been maintained by Yaakov [1].

Now, the latest upstream of exif is 0.6.22 [2].


This line should be...

``Now, the latest upstream of libspectre is 0.2.9 [2].''


Regards,

Lem



some typing error ?

$ cygport libspectre.cygport all
/pub/tmp/libspectre-0.2.9-1.src/libspectre.cygport: line 11: 
freedesktop.sub.experimental: No such file or directory

Re: Postinstall script errors for man* packages

[Achim Gratz]

Allen Hewes via Cygwin writes:
> I think the recent man* package update has an issue in the postinstall script:

Yes, the script got broken when it was generated for packaging.  It's
hopefully fixed now.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
--
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: Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible

[Achim Gratz]

Matt D. via Cygwin writes:
> The normal behavior for both Windows and Linux is to create the
> symbolic link whether the target exists or not.

That's not the case on Windows or rather it has restrictions that can
trip you up.  On Windows you must specify if the symbolic link points to
a directory or a file in order to create a symbolic link to a
non-existing file.  If that information is not available, it is
obviously safer to not create the symbolic link.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
--
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: [ITA] libspectre-0.2.9-1

[Lemures Lemniscati via Cygwin-apps]

On Tue, 05 Jan 2021 01:33:28 +0900, Lemures Lemniscati
> ITA for libspectre, which has been maintained by Yaakov [1].
> 
> Now, the latest upstream of exif is 0.6.22 [2].

This line should be...

``Now, the latest upstream of libspectre is 0.2.9 [2].''


Regards,

Lem

[ITA] libspectre-0.2.9-1

[Lemures Lemniscati via Cygwin-apps]

ITA for libspectre, which has been maintained by Yaakov [1].

Now, the latest upstream of exif is 0.6.22 [2].

A new candidate cygport file is placed at [3].
And, it's been tested on Cygwin AppVeyor CI (ID 1606: [4]).

Generated package files are placed at [5] and [6].


Packaging is rearranged from 0.2.8-1:
  General docs are moved from libspectre1 to libspectre-devel [7].


[1]: https://cygwin.com/git/?p=git/cygwin-packages/libspectre.git
[2]: https://gitlab.freedesktop.org/libspectre/libspectre
[3]: https://github.com/cygwin-freedesktop-lem/libspectre-cygport/tree/n_0.2.9-1
[4]: https://cygwin.com/cgi-bin2/jobs.cgi?id=1606
  or https://ci.appveyor.com/project/cygwin/scallywag/builds/37101239
[5]: https://cygwin-freedesktop-lem.github.io/libspectre-cygport/
[6]: 
https://github.com/cygwin-freedesktop-lem/libspectre-cygport/tree/n_0.2.9-1_gh-pages

[7]: Contents of packages:

>>> libspectre1-0.2.9-1.tar.xz
usr/bin/cygspectre-1.dll

>>> libspectre-devel-0.2.9-1.tar.xz
usr/include/
usr/include/libspectre/
usr/include/libspectre/spectre-document.h
usr/include/libspectre/spectre-exporter.h
usr/include/libspectre/spectre-macros.h
usr/include/libspectre/spectre-page.h
usr/include/libspectre/spectre-render-context.h
usr/include/libspectre/spectre-status.h
usr/include/libspectre/spectre-version.h
usr/include/libspectre/spectre.h
usr/lib/
usr/lib/libspectre.dll.a
usr/lib/pkgconfig/
usr/lib/pkgconfig/libspectre.pc
usr/share/doc/
usr/share/doc/libspectre/
usr/share/doc/libspectre/AUTHORS
usr/share/doc/libspectre/COPYING
usr/share/doc/libspectre/NEWS
usr/share/doc/libspectre/README
usr/share/doc/libspectre/TODO



Regards, 

Lem

Re: Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible

[Eliot Moss]

On 1/4/2021 10:27 AM, Matt D. via Cygwin wrote:
> I think there is a misunderstanding with how to set up your
> environment to reproduce my test cases. I did state in the subject
> "native symbolic links" but I can see that this can be misinterpreted
> and I should have clarified.
>
> I am using symbolic links native to Windows. My CYGWIN environment
> variable has been set to "winsymlinks:nativestrict" and my account has
> permission to make symbolic links. This is an issue specifically with
> Cygwin; I have no problems making links at the windows command line.
> Cygwin also does not have a problem making symbolic links-- if the
> target already exists. The issue is that I cannot create native
> symbolic links with Cygwin for targets that DON'T exist.
>
> The normal behavior for both Windows and Linux is to create the
> symbolic link whether the target exists or not. I don't know why
> Cygwin fails to do this only for native Windows symbolic links. It
> does not have a problem creating links to any target with the default
> Cygwin (non-Windows) symbolic links.

Ok, I see the behavior now that you are talking about.  You can get it with ln
without any need for cp.  With winsymlinks:nativestrict, if I do:

ln -s foo bar

and foo does not exist, it refuses to create the link.  As you found, it also
refuses to cp it.  However, I _was_ able to mv it.

Regards - Eliot
--
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: Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible

[Jeffrey Altman via Cygwin]

On 1/4/2021 10:27 AM, Matt D. via Cygwin (cygwin@cygwin.com) wrote:
> I am using symbolic links native to Windows. My CYGWIN environment
> variable has been set to "winsymlinks:nativestrict" and my account has
> permission to make symbolic links. This is an issue specifically with
> Cygwin; I have no problems making links at the windows command line.
> Cygwin also does not have a problem making symbolic links-- if the
> target already exists. The issue is that I cannot create native
> symbolic links with Cygwin for targets that DON'T exist.
> 
> The normal behavior for both Windows and Linux is to create the
> symbolic link whether the target exists or not. I don't know why
> Cygwin fails to do this only for native Windows symbolic links. It
> does not have a problem creating links to any target with the default
> Cygwin (non-Windows) symbolic links.

Windows native symlinks encode the object type of the target and the
encoded type must match that of the target or the link will not work
when the target exists.

A UNIX symlink does not encode any details of the target.

Cygwin doesn't know what type of native symlink to create if the
target does not exist.

I hope this knowledge helps.

Jeffrey Altman







smime.p7s
Description: S/MIME Cryptographic Signature
--
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: man-db-2.9.3-3

[Achim Gratz]

The man-db package version 2.9.3 is re-released to correct an error in
generating the postinstall scripts and replaces the erroneous version,
which was removed.

Man-db is an implementation of the standard Unix documentation system 
accessed using the man command. It uses a Berkeley DB database in place of 
the traditional flat-text whatis databases.


Cygwin Notes


The man-db package includes a conditional perpetual postinstall script
that keeps the database updated each time setup is run if (and only if)
the database exists.  This update now runs in the background by default,
so setup is no longer waiting for the update to complete.  This can be
changed if needed, see below.  The diagnostic output from the update is
stored at /var/log/mandb-index.log, so you can check if there were
problems on the last update.

In order to create the database directly via setup, please install the
man-db-create-index package.  The removal of this package will not
remove an existing database, this still needs to be done manually if
required.

If your installation procedure requires that setup waits for the index
update to complete, install the man-db-index-synchronously package
instead.  The creation of a new database can take several minutes to
over an hour depending on how many manual pages are installed and how
fast your filesystem is.  Removal of this package will leave an existing
database in place, but switches the system back to do background
updates.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
--
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

Updated: man-db-2.9.3-3

[Achim Gratz]

The man-db package version 2.9.3 is re-released to correct an error in
generating the postinstall scripts and replaces the erroneous version,
which was removed.

Man-db is an implementation of the standard Unix documentation system 
accessed using the man command. It uses a Berkeley DB database in place of 
the traditional flat-text whatis databases.


Cygwin Notes


The man-db package includes a conditional perpetual postinstall script
that keeps the database updated each time setup is run if (and only if)
the database exists.  This update now runs in the background by default,
so setup is no longer waiting for the update to complete.  This can be
changed if needed, see below.  The diagnostic output from the update is
stored at /var/log/mandb-index.log, so you can check if there were
problems on the last update.

In order to create the database directly via setup, please install the
man-db-create-index package.  The removal of this package will not
remove an existing database, this still needs to be done manually if
required.

If your installation procedure requires that setup waits for the index
update to complete, install the man-db-index-synchronously package
instead.  The creation of a new database can take several minutes to
over an hour depending on how many manual pages are installed and how
fast your filesystem is.  Removal of this package will leave an existing
database in place, but switches the system back to do background
updates.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Re: Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible

[Matt D. via Cygwin]

I think there is a misunderstanding with how to set up your
environment to reproduce my test cases. I did state in the subject
"native symbolic links" but I can see that this can be misinterpreted
and I should have clarified.

I am using symbolic links native to Windows. My CYGWIN environment
variable has been set to "winsymlinks:nativestrict" and my account has
permission to make symbolic links. This is an issue specifically with
Cygwin; I have no problems making links at the windows command line.
Cygwin also does not have a problem making symbolic links-- if the
target already exists. The issue is that I cannot create native
symbolic links with Cygwin for targets that DON'T exist.

The normal behavior for both Windows and Linux is to create the
symbolic link whether the target exists or not. I don't know why
Cygwin fails to do this only for native Windows symbolic links. It
does not have a problem creating links to any target with the default
Cygwin (non-Windows) symbolic links.

On Mon, Jan 4, 2021 at 7:30 AM Eliot Moss  wrote:
>
> On 1/4/2021 5:36 AM, Matt D. via Cygwin wrote:
>  > Did you try any of my test cases? This can't and doesn't work for the
>  > reasons I outlined in my previous message:
>  >
>  > $ cp -av folder_a/a folder_b/
>  > 'folder_a/a' -> 'folder_b/a'
>  > cp: cannot create symbolic link 'folder_b/a': No such file or directory
>  >
>  > $ cp -dv folder_a/a folder_b/
>  > 'folder_a/a' -> 'folder_b/a'
>  > cp: cannot create symbolic link 'folder_b/a': No such file or directory
>  >
>  > $ cp -Pv folder_a/a folder_b/
>  > 'folder_a/a' -> 'folder_b/a'
>  > cp: cannot create symbolic link 'folder_b/a': No such file or directory
>
> So did you mkdir folder_b first?  I don't think cp will create it for you.  I
> tried the commands above with folder_b not existing and got the behavior you
> indicated, but when I created folder_b first, all three cp commands worked.
> This overall behavior does not surprise me.
>
> On the other hand, if I have folder_b non-existing and do (e.g.)
>
> cp -rav folder_a folder_b
>
> then it _does_ create folder_b, and also copies the links.
>
> HTH - Eliot Moss
> --
> 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
--
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

Postinstall script errors for man* packages

[Allen Hewes via Cygwin]

Hi,

I think the recent man* package update has an issue in the postinstall script:

Postinstall script errors
Package: z/Perpetual
zp_man-db-update-index.dash exit code 2

$ /etc/postinstall/zp_man-db-update-index.dash
/etc/postinstall/zp_man-db-update-index.dash: line 4: syntax error near 
unexpected token `newline'
/etc/postinstall/zp_man-db-update-index.dash: line 4: `exec 3> '

/allen



Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or 
documents linked to this email, are intended for the addressee and may contain 
information that is privileged, confidential, proprietary, or otherwise 
protected by law. Any dissemination, distribution, or copying is prohibited. 
This notice serves as a confidentiality marking for the purpose of any 
confidentiality or nondisclosure agreement. If you have received this 
communication in error, please contact the original sender.
--
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: [ANNOUNCEMENT] Updated: less-563-1

[Andrey Repin]

Greetings, Marco Atzeri via Cygwin-announce via Cygwin!

> New version 563-1 of

>less

> is available in the Cygwin distribution

> CHANGES
> Last upstream release

> http://www.greenwoodsoftware.com/less/

> Also compiled with pcre regex

Yes! Thank you!


-- 
With best regards,
Andrey Repin
Monday, January 4, 2021 18:08:37

Sorry for my terrible english...

--
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: OpenSSL

[Marco Atzeri via Cygwin]

On 04.01.2021 13:21, tommie.k...@alverservices.com wrote:
  


Hey, sorry if this is the wrong place.


Hi Tommie,
this is the right place.



But im struggling to see how I can upgrade openssl >1.1.1f

Compliance checks state that we must have a more up to date version, I know
that it exists (1.1.1g, 1.1.1h, 1.1.1i)


https://cygwin.com/packages/summary/openssl.html

the last one available on cygwin is 1.1.1f



But I can only seem to upgrade to 1.1.1f in Cygwin  - is there a new upgrade
package for Cygwin/Openssl coming in the near future?


It will depends on the maintainer (Corinna) availability.
Maybe after the holyday season

Thanks
Tommie King


Regards
Marco

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

Testing is skipped on i686-AppVeyor for shared-mime-info 2.1

[Lemures Lemniscati via Cygwin-apps]

Hi!

I'm preparing share-mime-info-2.1-1, updating to the latest upstream.

My local-buildings run and check successfull both on i686 and x86_64
with a source tree [1].

But on AppVeyor [2], testing seems to be skipped on i686 arch, although
src_test is called  [3]...  On the other hand, testing is successful on
x86_64 arch [4]. 


I don't know the reason of this behavior.
Is there any similar case or advice?

[1]: 
https://cygwin.com/git/?p=git/cygwin-packages/shared-mime-info.git;a=tree;hb=0588202435b81436c528ea97d00d638b0a95447f

[2]: https://cygwin.com/cgi-bin2/jobs.cgi?id=1598

[3]: i686 log 
https://ci.appveyor.com/project/cygwin/scallywag/builds/37091169/job/6c336oytcgpm308g
 log from testing part to the end of AppVeyor build.
>>> Testing shared-mime-info-2.1-1.i686
scallywag: publishing artifacts
Collecting artifacts...
Found artifact 'staging' matching 'staging' path
Uploading artifacts...
[1/1] artifacts.zip (6,518,017 bytes)...100%
Updating build cache...
Cache 'C:\cache' - Up to date
SET PATH=%ORIG_PATH%
appveyor PushArtifact builddir.tar.xz -DeploymentName builddir || true
Uploading artifact builddir.tar.xz (23,726,328 bytes)...100%
Build success



[4]: x86_64 log 
https://ci.appveyor.com/project/cygwin/scallywag/builds/37091169/job/kk2wuebn40ikfl1c
 log from testing part to the end of AppVeyor build.
>>> Testing shared-mime-info-2.1-1.x86_64
1/9 translationsOK 5.75s
2/9 test-mime   OK 4.70s
3/9 No duplicate mime-types OK 0.56s
4/9 Single spelling caseOK 0.49s
5/9 Sanity check sub-class-of   OK 0.41s
6/9 xmllint freedesktop.org.xml OK 0.25s
7/9 Case sensitivityOK 0.28s
8/9 update-mime-databaseOK 0.11s
9/9 ITS validation  OK 0.06s
Ok: 9   
Expected Fail:  0   
Fail:   0   
Unexpected Pass:0   
Skipped:0   
Timeout:0   
Full log written to 
/cygdrive/c/projects/shared-mime-info/shared-mime-info-2.1-1.x86_64/src/shared-mime-info-2.1/x86_64-pc-cygwin/meson-logs/testlog.txt
scallywag: publishing artifacts
Collecting artifacts...
Found artifact 'staging' matching 'staging' path
Uploading artifacts...
[1/1] artifacts.zip (6,522,243 bytes)...100%
Updating build cache...
Cache 'C:\cache' - Up to date
SET PATH=%ORIG_PATH%
appveyor PushArtifact builddir.tar.xz -DeploymentName builddir || true
Uploading artifact builddir.tar.xz (23,784,880 bytes)...100%
Build success


Regards,

Lem

Re: [RFE] calm needs to know about ZStandard compressed archives

[Jon Turney]

On 03/01/2021 15:57, Achim Gratz wrote:

Marco Atzeri via Cygwin-apps writes:

We will also need to modify cygport to stop automatically add
OBSOLETES as most of this packages never existed


I think the right thing to do is to stop having actual packages for
OBSOLETES and just emit the obsoltes: hint instead.


Yeah, this change to cygport should be made and we can turn off support 
for setup versions which don't understand the obsoletes: hint.



an overall cleaning of obsoletes package may be useful in the
near future. I need to work on it.

Re: Fixing moreutils Git repo

[Jon Turney]

On 04/01/2021 10:39, Adam Dinwoodie wrote:

Somewhere along the way I seem to have unsubscribed from this list,
and therefore managed to miss a bunch of development with the Git
repositories at https://cygwin.com/git-cygwin-packages/. As a result I
thought they were still naive repositories with no fancy logic or
automation, and my first experiments with the moreutils repo have
created a branch I'd like to force-push to or delete, but am blocked
by the hooks.

Would it be possible for someone with the relevant access to either
delete the "next" branch from the moreutils repo, or delete the repo
wholesale so I can recreate it (with more care) from scratch?


I removed the 'next' branch for you.

Please let me know if there's anything else you need help with.


Tangentially, is there any clear documentation on what functions these
repos have these days? There's some info at
https://cygwin.com/packaging/repos.html, but (for example) that makes
no mention of the build automation that clearly now exists, nor of any
branch protection. And while I can go through the mailing list
archives, that also requires reading through a bunch of messages that
are going to be no longer relevant.


I added some brief documentation at [1]

https://cygwin.com/packaging/build.html

Re: [ITA] libexif-0.6.22-1

[Lemures Lemniscati via Cygwin-apps]

On Sun, 03 Jan 2021 10:51:30 +0100, Achim Gratz
> Lemures Lemniscati via Cygwin-apps writes:
> > So an expected libexiv-doc will contain
> […]
> > How about this rearrangement?
> 
> That sounds OK to me.  You don't need to do another update just for that
> change of course.

Thank you.

I've just prepared it [1]. The change will be reflected in a next update
(latest upstream or security).

[1]: 
https://github.com/cygwin-lem/libexif-cygport/blob/w_rearrange/libexif.cygport

Regards,

Lem

[ANNOUNCEMENT] Updated: man-db-2.9.3-2

[Achim Gratz]

The man-db package version 2.9.3 is re-released to correct a packaging
error and improve the perpetual index update postinstall script.

Man-db is an implementation of the standard Unix documentation system 
accessed using the man command. It uses a Berkeley DB database in place of 
the traditional flat-text whatis databases.


Cygwin Notes


The man-db package includes a conditional perpetual postinstall script
that keeps the database updated each time setup is run if (and only if)
the database exists.  This update now runs in the background by default,
so setup is no longer waiting for the update to complete.  This can be
changed if needed, see below.  The diagnostic output from the update is
stored at /var/log/mandb-index.log, so you can check if there were
problems on the last update.

In order to create the database directly via setup, please install the
man-db-create-index package.  The removal of this package will not
remove an existing database, this still needs to be done manually if
required.

If your installation procedure requires that setup waits for the index
update to complete, install the man-db-index-synchronously package
instead.  The creation of a new database can take several minutes to
over an hour depending on how many manual pages are installed and how
fast your filesystem is.  Removal of this package will leave an existing
database in place, but switches the system back to do background
updates.


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.
--
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

Updated: man-db-2.9.3-2

[Achim Gratz]

The man-db package version 2.9.3 is re-released to correct a packaging
error and improve the perpetual index update postinstall script.

Man-db is an implementation of the standard Unix documentation system 
accessed using the man command. It uses a Berkeley DB database in place of 
the traditional flat-text whatis databases.


Cygwin Notes


The man-db package includes a conditional perpetual postinstall script
that keeps the database updated each time setup is run if (and only if)
the database exists.  This update now runs in the background by default,
so setup is no longer waiting for the update to complete.  This can be
changed if needed, see below.  The diagnostic output from the update is
stored at /var/log/mandb-index.log, so you can check if there were
problems on the last update.

In order to create the database directly via setup, please install the
man-db-create-index package.  The removal of this package will not
remove an existing database, this still needs to be done manually if
required.

If your installation procedure requires that setup waits for the index
update to complete, install the man-db-index-synchronously package
instead.  The creation of a new database can take several minutes to
over an hour depending on how many manual pages are installed and how
fast your filesystem is.  Removal of this package will leave an existing
database in place, but switches the system back to do background
updates.


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Re: Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible

[Eliot Moss]

On 1/4/2021 5:36 AM, Matt D. via Cygwin wrote:
> Did you try any of my test cases? This can't and doesn't work for the
> reasons I outlined in my previous message:
>
> $ cp -av folder_a/a folder_b/
> 'folder_a/a' -> 'folder_b/a'
> cp: cannot create symbolic link 'folder_b/a': No such file or directory
>
> $ cp -dv folder_a/a folder_b/
> 'folder_a/a' -> 'folder_b/a'
> cp: cannot create symbolic link 'folder_b/a': No such file or directory
>
> $ cp -Pv folder_a/a folder_b/
> 'folder_a/a' -> 'folder_b/a'
> cp: cannot create symbolic link 'folder_b/a': No such file or directory

So did you mkdir folder_b first?  I don't think cp will create it for you.  I
tried the commands above with folder_b not existing and got the behavior you
indicated, but when I created folder_b first, all three cp commands worked.
This overall behavior does not surprise me.

On the other hand, if I have folder_b non-existing and do (e.g.)

cp -rav folder_a folder_b

then it _does_ create folder_b, and also copies the links.

HTH - Eliot Moss
--
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

OpenSSL

[tommie.king]

 

Hey, sorry if this is the wrong place.  

 

But im struggling to see how I can upgrade openssl >1.1.1f

 

Compliance checks state that we must have a more up to date version, I know
that it exists (1.1.1g, 1.1.1h, 1.1.1i)

 

But I can only seem to upgrade to 1.1.1f in Cygwin  - is there a new upgrade
package for Cygwin/Openssl coming in the near future?

 

Thanks 

 

Tommie King

 

 

 

 

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

Fixing moreutils Git repo

[Adam Dinwoodie]

Somewhere along the way I seem to have unsubscribed from this list,
and therefore managed to miss a bunch of development with the Git
repositories at https://cygwin.com/git-cygwin-packages/. As a result I
thought they were still naive repositories with no fancy logic or
automation, and my first experiments with the moreutils repo have
created a branch I'd like to force-push to or delete, but am blocked
by the hooks.

Would it be possible for someone with the relevant access to either
delete the "next" branch from the moreutils repo, or delete the repo
wholesale so I can recreate it (with more care) from scratch?

Tangentially, is there any clear documentation on what functions these
repos have these days? There's some info at
https://cygwin.com/packaging/repos.html, but (for example) that makes
no mention of the build automation that clearly now exists, nor of any
branch protection. And while I can go through the mailing list
archives, that also requires reading through a bunch of messages that
are going to be no longer relevant.

Re: Native symbolic link behavior is broken and makes backups using Cygwin command line tools impossible

[Matt D. via Cygwin]

Did you try any of my test cases? This can't and doesn't work for the
reasons I outlined in my previous message:

$ cp -av folder_a/a folder_b/
'folder_a/a' -> 'folder_b/a'
cp: cannot create symbolic link 'folder_b/a': No such file or directory

$ cp -dv folder_a/a folder_b/
'folder_a/a' -> 'folder_b/a'
cp: cannot create symbolic link 'folder_b/a': No such file or directory

$ cp -Pv folder_a/a folder_b/
'folder_a/a' -> 'folder_b/a'
cp: cannot create symbolic link 'folder_b/a': No such file or directory

On Sun, Jan 3, 2021 at 12:00 AM Brian Inglis
 wrote:
>
> On 2021-01-02 21:16, Matt D. via Cygwin wrote:
> > I have a folder with a lot of native Windows symbolic links. I want to
> > copy this folder.
> >
> > I cannot rsync or cp this folder due to Cygwin being unable to create
> > symbolic links without also wanting to verify the link target. This
> > can be demonstrated:
> >
> > $ ln -s a b
> > ln: failed to create symbolic link 'b': No such file or directory
> >
> > If I create a test directory folder_a/ and folder_b/. Inside I will
> > "touch a" and "ln -s a b".
> >
> > I cannot rsync this folder:
> >
> > $ rsync -a folder_a/ folder_b/
> > rsync: symlink "folder_a/b" -> "a" failed: No such file or directory (2)
> > rsync error: some files/attrs were not transferred (see previous
> > errors) (code 23) at main.c(1306) [sender=3.2.0dev]
> >
> > Using "cp -a folder_a/* folder_b/" in this test case DOES work but
> > this is simply because files were returned in the correct order and
> > the link could be created.
> >
> > This can be demonstrated where this works fine:
> >
> > $ cp -a folder_a/a folder_a/b folder_b/
> >
> > But this does not:
> >
> > $ cp -a folder_a/b folder_a/b folder_b/
> > cp: cannot create symbolic link 'folder_b/b': No such file or directory
> > cp: warning: source file 'folder_a/b' specified more than once
> >
> > The order in which files are returned while listing them in a
> > directory and necessitating their pre-existence while performing a
> > deep copy is impossible. It's also very normal for symbolic links to
> > exist which may or may not point to a valid target depending on the
> > observing path.
> >
> > Windows does NOT require a link to be valid before creation. This can
> > be demonstrated with mklink:
> >
> > C:\mklink b a
> > symbolic link created for b <<===>> a
>
> Depending on exactly what you have and what you want to do try:
>
> $ cp -av
> $ cp -dv
> $ cp -Pv
> or
> > robocopy /sl
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
> --
> 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
--
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: Fortran Installation

[Marco Atzeri via Cygwin]

On 04.01.2021 01:19, Lou Umscheid wrote:
Thank you for the information. Do you have any suggestions on which 
compiler to use ie the most recent or the tried and true? I have 4.5 
installed on my old T1600 system.





by default run the most recent

gcc-fortran-10.2.0-1

If you have problem, you can report here
--
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