Re: Please support download setup-x86_64.exe on IPv6-only network

[Backwoods BC via Cygwin]

On Mon, Nov 20, 2023 at 9:36 PM Brian Inglis via Cygwin
 wrote:
>
> On 2023-11-20 17:45, Lee via Cygwin wrote:
> > On Mon, Nov 20, 2023 at 7:13 PM Backwoods BC via Cygwin wrote:
> >>
> >> On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin wrote:
> >>> The whole IP v4 internet is available as a compatibility subnet 
> >>> :::0:a.b.c.d
> >>> on IP v6, so there is no excuse for not supporting interconnection, as it 
> >>> will
> >>> be required until the last backbone routers drop IP v4 support.
> >>
> >> Just a small correction for the mail archives as this appears solved.
> >> The correct IPV6 address for the IPV4 address range is
> >> :::a.b.c.d  (no '0')
> >
> > If you're going for correcting the record, let's make it correct.
> > :::a.b.c.d is not a solution for IPv6 => IPv4 interconnection over
> > the Internet.
> >
> > from:  https://www.rfc-editor.org/rfc/rfc5156
> >
> > 2.2.  IPv4-Mapped Addresses
> >
> > :::0:0/96 are the IPv4-mapped addresses [RFC4291].  Addresses
> > within this block should not appear on the public Internet.
>
> These internal addresses are used by dual stack hosts to allow clients or
> servers to handle connections to IPv4 hosts the same as IPv6 hosts.
>
> Whereas :::0:0:0/96 == :::0:a.b.c.d allows IPv6 only hosts without
> assigned IPv4 addresses to connect to IPv4 only hosts via SIIT see:
>
> https://www.rfc-editor.org/rfc/rfc7915 Stateless IP/ICMP Translation.

Sorry I got this wrong. I admit to knowing only enough about IP v4 to
be dangerous (and design hardware for it), but I was relying on  this
site for IP v6 info:



In my defence, I also saw this in RFC 4291:

2.5.5.2.  IPv4-Mapped IPv6 Address
   A second type of IPv6 address that holds an embedded IPv4 address is
   defined.  This address type is used to represent the addresses of
   IPv4 nodes as IPv6 addresses.  The format of the "IPv4-mapped IPv6
   address" is as follows:
   |80 bits   | 16 |  32 bits|
   +--+--+
   |..||IPv4 address |
   +--++-+

I hope you can see why I was confused and thought your comment was a
type. I apologize for doubting you.

There are far too many RFCs for someone who has never used IP v6 for
real. I'll just acknowledge that I don't know what I'm talking about
and slink back into the darkness.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygport upgrade to use gnupg2/gpg2 if available

[ASSI via Cygwin-apps]

Brian Inglis via Cygwin-apps writes:
> After applying the attached patches, which add support for the newer
> gpg2 from gnupg2 if installed, the attached log second chunk shows the
> new keys verified by gpg2 added to lib/src_prep.cygpart
> ___gpg_verify().
>
> Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for
> check and definition and __gpg_sign() for use in gpg signing of Cygwin
> patches and files.


We should just switch to gpg2 an require that, there is no point in
trying to use GPG 1.x anymore.

https://repo.or.cz/cygport/rpm-style.git/commitdiff/84279e484726a68cc8f08e7c9126bef13d9510d7


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

Re: cygport upgrade to use gnupg2/gpg2 if available

[Brian Inglis via Cygwin-apps]

On 2023-11-20 21:51, Brian Inglis via Cygwin-apps wrote:
The attached log first chunk shows that new downloads especially GnuPG and GNU 
packages may be signed with keys not recognized by old gnupg/gpg.
After applying the attached patches, which add support for the newer gpg2 from 
gnupg2 if installed, the attached log second chunk shows the new keys verified 
by gpg2 added to lib/src_prep.cygpart ___gpg_verify().
Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for check and 
definition and __gpg_sign() for use in gpg signing of Cygwin patches and files.


Not sure what previous lib/src_prep.cygpart patch was generated from, but patch 
from correct sources is attached.


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry--- /usr/share/cygport/lib/src_prep.cygpart.orig2023-08-07 
09:46:31.0 -0600
+++ /usr/share/cygport/lib/src_prep.cygpart 2023-11-20 23:15:36.349253300 
-0700
@@ -181,12 +181,14 @@ __gpg_verify() {
local _filetype=${2};
local _sigext=${3:-sig};
 
-   if ! check_prog gpg
+   if check_prog gpg2; then GPG=gpg2; else GPG=gpg; fi
+
+   if ! check_prog $GPG
then
# display notice only once
if ! defined _gpg_not_found_
then
-   inform "gnupg must be installed in order to check 
signatures.";
+   inform "gnupg2 or gnupg must be installed in order to 
check signatures.";
_gpg_not_found_=1
fi
 
@@ -196,7 +198,7 @@ __gpg_verify() {
if [ -f ${_file}.${_sigext} ]
then
inform "${_filetype} signature follows:";
-   gpg --verify ${_file}.${_sigext} ${_file} || true;
+   $GPG --verify ${_file}.${_sigext} ${_file} || true;
fi
 }
 

Re: Please support download setup-x86_64.exe on IPv6-only network

[Brian Inglis via Cygwin]

On 2023-11-20 17:45, Lee via Cygwin wrote:

On Mon, Nov 20, 2023 at 7:13 PM Backwoods BC via Cygwin wrote:


On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin wrote:

The whole IP v4 internet is available as a compatibility subnet :::0:a.b.c.d
on IP v6, so there is no excuse for not supporting interconnection, as it will
be required until the last backbone routers drop IP v4 support.


Just a small correction for the mail archives as this appears solved.
The correct IPV6 address for the IPV4 address range is
:::a.b.c.d  (no '0')


If you're going for correcting the record, let's make it correct.
:::a.b.c.d is not a solution for IPv6 => IPv4 interconnection over
the Internet.

from:  https://www.rfc-editor.org/rfc/rfc5156

2.2.  IPv4-Mapped Addresses

:::0:0/96 are the IPv4-mapped addresses [RFC4291].  Addresses
within this block should not appear on the public Internet.


These internal addresses are used by dual stack hosts to allow clients or 
servers to handle connections to IPv4 hosts the same as IPv6 hosts.


Whereas :::0:0:0/96 == :::0:a.b.c.d allows IPv6 only hosts without 
assigned IPv4 addresses to connect to IPv4 only hosts via SIIT see:


https://www.rfc-editor.org/rfc/rfc7915 Stateless IP/ICMP Translation.

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

cygport upgrade to use gnupg2/gpg2 if available

[Brian Inglis via Cygwin-apps]

Hi folks,

The attached log first chunk shows that new downloads especially GnuPG and GNU 
packages may be signed with keys not recognized by old gnupg/gpg.


After applying the attached patches, which add support for the newer gpg2 from 
gnupg2 if installed, the attached log second chunk shows the new keys verified 
by gpg2 added to lib/src_prep.cygpart ___gpg_verify().


Similar code has been added to lib/pkg_pkg.cygpart __pkg_srcpkg() for check and 
definition and __gpg_sign() for use in gpg signing of Cygwin patches and files.


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry>>> Preparing gpgme-1.23.1-1.x86_64
*** Info: SOURCE 1 signature follows:
gpg: Signature made 2023 Oct 27 Fri 06:41:07 MDT using ? key ID 26403ADA
gpg: Can't check signature: unknown pubkey algorithm
gpg: Signature made 2023 Nov 14 Tue 17:50:43 MST using ? key ID 19C6C8BD
gpg: Can't check signature: unknown pubkey algorithm

>>> Preparing gpgme-1.23.1-1.x86_64
*** Info: SOURCE 1 signature follows:
gpg: Signature made 2023 Oct 27 Fri 06:41:07 MDT
gpg:using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
gpg: Good signature from "Werner Koch (dist signing 2020)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
gpg: Signature made 2023 Nov 14 Tue 17:50:43 MST
gpg:using EDDSA key AC8E115BF73E2D8D47FA9908E98E9B2D19C6C8BD
gpg: Good signature from "Niibe Yutaka (GnuPG Release Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
--- /usr/share/cygport/lib/pkg_pkg.cygpart.orig 2023-03-08 06:07:57.0 
-0700
+++ /usr/share/cygport/lib/pkg_pkg.cygpart  2023-11-19 21:13:16.879391200 
-0700
@@ -505,7 +505,7 @@ __gpg_sign() {
echo "${2} signature needs to be updated";
rm -f ${1}.sig;
# we 'check_prog gpg' in __pkg_srcpkg()
-   gpg --detach-sign ${1};
+   $GPG --detach-sign ${1};
 }
 
 __squeeze_whitespace() {
@@ -563,7 +563,9 @@ __pkg_srcpkg() {
 
if __arg_bool SIG
then
-   if check_prog gpg
+   if check_prog gpg2; then GPG=gpg2; else GPG=gpg; fi
+
+   if check_prog $GPG
then
__gpg_sign ${spkgdir}/${cygportfile} "CYGPORT SCRIPT";
 
@@ -583,14 +585,15 @@ __pkg_srcpkg() {
__gpg_sign ${spkgdir}/${src_patchfile} "SOURCE 
PATCH";
fi
else
-   inform "gnupg must be installed in order to make 
signatures.";
+   inform "gnupg2 or gnupg must be installed in order to 
make signatures.";
fi
fi
 
cd ${spkgdir%/*};
 
mkdir -p ${distdir}/${PN};
-   __tar ${distdir}/${PN}/${PF}-src.tar.${TAR_COMPRESSION_EXT} 
${spkgdir##*/}/ || error "Source package creation failed"
+   __tar ${distdir}/${PN}/${PF}-src.tar.${TAR_COMPRESSION_EXT} 
${spkgdir##*/}/ \
+   || error "Source package creation failed"
echo;
 
# source package hint
--- /usr/share/cygport/lib/src_prep.cygpart.orig2023-11-19 
18:51:13.284177300 -0700
+++ /usr/share/cygport/lib/src_prep.cygpart 2023-11-19 21:00:35.754036900 
-0700
@@ -181,12 +181,14 @@ __gpg_verify() {
local _filetype=${2};
local _sigext=${3:-sig};
 
-   if ! check_prog gpg && ! check_prog gpg2
+   if check_prog gpg2; then GPG=gpg2; else GPG=gpg; fi
+
+   if ! check_prog $GPG
then
# display notice only once
if ! defined _gpg_not_found_
then
-   inform "gnupg or gnupg2 must be installed in order to 
check signatures.";
+   inform "gnupg2 or gnupg must be installed in order to 
check signatures.";
_gpg_not_found_=1
fi
 
@@ -195,7 +197,6 @@ __gpg_verify() {
 
if [ -f ${_file}.${_sigext} ]
then
-   [ check_prog gpg2 ] && GPG=gpg2 || GPG=gpg
inform "${_filetype} signature follows:";
$GPG --verify ${_file}.${_sigext} ${_file} || true;
fi

Re: Please support download setup-x86_64.exe on IPv6-only network

[Lee via Cygwin]

On Mon, Nov 20, 2023 at 7:13 PM Backwoods BC via Cygwin wrote:
>
> On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin wrote:
> > The whole IP v4 internet is available as a compatibility subnet 
> > :::0:a.b.c.d
> > on IP v6, so there is no excuse for not supporting interconnection, as it 
> > will
> > be required until the last backbone routers drop IP v4 support.
>
> Just a small correction for the mail archives as this appears solved.
> The correct IPV6 address for the IPV4 address range is
> :::a.b.c.d  (no '0')

If you're going for correcting the record, let's make it correct.
:::a.b.c.d is not a solution for IPv6 => IPv4 interconnection over
the Internet.

from:  https://www.rfc-editor.org/rfc/rfc5156

2.2.  IPv4-Mapped Addresses

   :::0:0/96 are the IPv4-mapped addresses [RFC4291].  Addresses
   within this block should not appear on the public Internet.


Regards,
Lee

-- 
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: Please support download setup-x86_64.exe on IPv6-only network

[Backwoods BC via Cygwin]

On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin
 wrote:
> The whole IP v4 internet is available as a compatibility subnet 
> :::0:a.b.c.d
> on IP v6, so there is no excuse for not supporting interconnection, as it will
> be required until the last backbone routers drop IP v4 support.

Just a small correction for the mail archives as this appears solved.
The correct IPV6 address for the IPV4 address range is
:::a.b.c.d  (no '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: Please support download setup-x86_64.exe on IPv6-only network

[Lee via Cygwin]

On Mon, Nov 20, 2023 at 8:55 AM Jon Turney wrote:
>
> On 16/11/2023 01:40, Bin W via Cygwin wrote:
> > https://www.cygwin.com/setup-x86_64.exe
> > IPv6-only network can't download the installer.
>
> I've spoken to the people who speak to the people who actually
> administer the DNS for us, and an IPv6 DNS record has been added for
> cygwin.com.

Thank you!!

As admin:
  ipconfig /release
so the only IPv4 address I've got is a 169.254.x.x address and I can
- open https://cygwin.com/
- download and run https://cygwin.com/setup-x86_64.exe
- get the current package info and update an already installed package

Regards,
Lee

-- 
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 3.4.9 - how to install ssh-keygen

[Lee via Cygwin]

On Mon, Nov 20, 2023 at 11:54 AM Matthias wrote:
>
> Dear all,
>
> I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10.
> After installing defaults plus openssh 9.5p 1-1, I open the Cygwin64-Terminal 
> as Administrator and
> run ssh-host-config.
>  * Answered "yes" to create the /etc/ssh_config and /etc/sshd_config
>  * Answered "no" to use StrictMode
>  * and "yes" to install sshd as a service
>  * I just press  for the question for "Value of CYGWIN for the daemon".
> cygrunsrv -S cygsshd will not start the sshd. The logfile say "no hostkeys 
> available".
>
> Unfortunately  I can't find ssh-keygen in the installable packages.
> Howto install ssh-keygen or how to create hostkeys?

The easy way to see if it's already installed
  $ which ssh-keygen
  /usr/bin/ssh-keygen

If no, Cygwin is a bit of a pain when looking for a program that's
included in another package.

There's probably a better way, but I use the cygwin package search - eg:
  https://cygwin.com/cgi-bin2/package-grep.cgi?grep=ssh-keygen
and then take a guess as the most likely candidate in the results list
and click on that link to see if it's included in that package - eg
  
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fopenssh%2Fopenssh-9.5p1-1=ssh-keygen


Regards
Lee

-- 
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: [PATCH] Cygwin: Add /dev/disk/by-label and /dev/disk/by-uuid symlinks

[Corinna Vinschen]

On Nov 20 15:54, Christian Franke wrote:
> From: Christian Franke 
> Date: Mon, 20 Nov 2023 15:40:42 +0100
> Subject: [PATCH] Cygwin: /dev/disk/by-uuid: Fix NTFS serial number print
>  format
> 
> Signed-off-by: Christian Franke 
> ---
>  winsup/cygwin/fhandler/dev_disk.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/winsup/cygwin/fhandler/dev_disk.cc 
> b/winsup/cygwin/fhandler/dev_disk.cc
> index 016b4c7bc..c5d72816f 100644
> --- a/winsup/cygwin/fhandler/dev_disk.cc
> +++ b/winsup/cygwin/fhandler/dev_disk.cc
> @@ -308,7 +308,7 @@ partition_to_label_or_uuid(bool uuid, const 
> UNICODE_STRING *drive_uname,
>&& nvdb->VolumeSerialNumber.QuadPart)
>  {
>/* Print without any separator as on Linux. */
> -  __small_sprintf (name, "%16X", nvdb->VolumeSerialNumber.QuadPart);
> +  __small_sprintf (name, "%016X", nvdb->VolumeSerialNumber.QuadPart);
>NtClose(volhdl);
>return true;
>  }
> -- 
> 2.42.1
> 

Pushed.

Thanks,
Corinna

Re: Cygwin 3.4.9 - how to install ssh-keygen

[Hans-Bernhard Bröker via Cygwin]

Am 20.11.2023 um 17:54 schrieb Matthias--- via Cygwin:

Unfortunately  I can't find ssh-keygen in the installable packages.



That's quite strange, given ssh-keygen is clearly right there in that 
openssh package:


$ cygcheck -f /usr/bin/ssh-keygen.exe
openssh-9.5p1-1


--
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: [ITP] gflags 2.2.2

[Jon Turney via Cygwin-apps]

On 16/11/2023 23:20, Daisuke Fujimura via Cygwin-apps wrote:

Hello,

[ITP] A new package proposal: gflags

- gflags
- libgflags2.2
- libgflags-devel



SUMMARY: Commandline flags module for C++
HOMEPAGE: https://github.com/gflags/gflags
SRC_URI: https://github.com/gflags/gflags/archive/refs/tags/v2.2.2.tar.gz
LICENSE: BSD-3-Clause



Corresponding Linux/Unix packages are searched:
- https://repology.org/project/gflags/versions

Cygportfile:
- 
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/gflags

Packages, logs:
- https://github.com/cygwin/scallywag/actions/runs/6893072156



Looks good.

I've added this to your packages.

The one question I have is about what 'gflags_completions.sh' is for? Is 
this a helper for scripts other packages using gflags might install in 
/etc/bash_completion.d/, or an example? or generally useful?

Cygwin 3.4.9 - how to install ssh-keygen

[Matthias--- via Cygwin]

Dear all,

I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10.
After installing defaults plus openssh 9.5p 1-1, I open the Cygwin64-Terminal 
as Administrator and
run ssh-host-config.
 * Answered "yes" to create the /etc/ssh_config and /etc/sshd_config
 * Answered "no" to use StrictMode
 * and "yes" to install sshd as a service
 * I just press  for the question for "Value of CYGWIN for the daemon".
cygrunsrv -S cygsshd will not start the sshd. The logfile say "no hostkeys 
available".

Unfortunately  I can't find ssh-keygen in the installable packages.
Howto install ssh-keygen or how to create hostkeys?

Thanks in advance
Matthias




-- 
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: [PATCH cygport] git.cygclass: Suppress the depth option

[ASSI via Cygwin-apps]

Jon Turney via Cygwin-apps writes:
> This could just be named something a little shorter, like
> "GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the
> URI's host?
>
> But I wonder if wouldn't just be better to try with --depth and then
> fallback to without it, if that fails (especially if we can tell it
> failed for that reason).

I was about to say the same thing…


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [PATCH] Cygwin: Add /dev/disk/by-label and /dev/disk/by-uuid symlinks

[Christian Franke]

Corinna Vinschen wrote:

On Nov 20 10:40, Corinna Vinschen wrote:

Hi Christian,

This puzzles me:

On Nov 17 21:25, Christian Franke wrote:

@@ -610,7 +607,7 @@ get_by_id_table (by_id_entry * , 
fhandler_dev_disk::dev_disk_location loc)
if (!table)
  return (errno_set ? -1 : 0);
  
-  /* Sort by name and remove duplicates. */

+  /* Sort by name and mark duplicates. */
qsort (table, table_size, sizeof (*table), by_id_compare_name);
for (unsigned i = 0; i < table_size; i++)

by_id_compare_name only compars the actual names...


  {
@@ -619,12 +616,13 @@ get_by_id_table (by_id_entry * , 
fhandler_dev_disk::dev_disk_location loc)
j++;
if (j == i + 1)
continue;
-  /* Duplicate(s) found, remove all entries with this name. */
-  debug_printf ("removing duplicates %d-%d: '%s'", i, j - 1, 
table[i].name);
-  if (j < table_size)
-   memmove (table + i, table + j, (table_size - j) * sizeof (*table));
-  table_size -= j - i;
-  i--;
+  /* Duplicate(s) found, append "#N" to all entries.  This never

...but the names are identical.  So the *order* within the identically
named entries depends on qsort's reshuffling of table
entries.  Which in turn depends on outside factors like number of table
entries and the ultimate position of the identical entries within the
ordered table.

Having said that, I don't see how adding ordinals to the names can be
unambiguous.  AFAICS, the numbers may change by just adding another
disk (USB Stick) to the system...

Oops, that's not exactly what I was trying to say, sorry.

The problem is not adding ordinals to the name, AFAICS, the problem is
that the sorting function by_id_compare_name is not up to the task to
make sure the order is unambiguous within the entries of identical name.


That's correct, thanks for catching. qsort is not a stable sort. 
Changing drives outside the duplicate range may also change the order 
within the range. Could be fixed by a lexicographic compare of {name, 
drive, part}.


I'll provide a new patch soon. For now, I attached the unrelated but 
important part of the dropped patch.


Christian

From 64c8a0eb3ead91de36ee65516483e40cf7f49446 Mon Sep 17 00:00:00 2001
From: Christian Franke 
Date: Mon, 20 Nov 2023 15:40:42 +0100
Subject: [PATCH] Cygwin: /dev/disk/by-uuid: Fix NTFS serial number print
 format

Signed-off-by: Christian Franke 
---
 winsup/cygwin/fhandler/dev_disk.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/fhandler/dev_disk.cc 
b/winsup/cygwin/fhandler/dev_disk.cc
index 016b4c7bc..c5d72816f 100644
--- a/winsup/cygwin/fhandler/dev_disk.cc
+++ b/winsup/cygwin/fhandler/dev_disk.cc
@@ -308,7 +308,7 @@ partition_to_label_or_uuid(bool uuid, const UNICODE_STRING 
*drive_uname,
   && nvdb->VolumeSerialNumber.QuadPart)
 {
   /* Print without any separator as on Linux. */
-  __small_sprintf (name, "%16X", nvdb->VolumeSerialNumber.QuadPart);
+  __small_sprintf (name, "%016X", nvdb->VolumeSerialNumber.QuadPart);
   NtClose(volhdl);
   return true;
 }
-- 
2.42.1

Re: [PATCH cygport] git.cygclass: Suppress the depth option

[Jon Turney via Cygwin-apps]

On 19/11/2023 02:11, Daisuke Fujimura via Cygwin-apps wrote:

Some git providers do not support smart transport, so specifying the
depth option will result in an error.


Right. This is a bug and needs fixing.

Thanks for the patch.


```
Cloning into ''...
fatal: dumb http transport does not support shallow capabilities
```

Therefore, I suggest adding a variable to suppress the depth option.
(Variable names should be changed to something appropriate according
to the naming convention.)

diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..0aa97a09 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -75,7 +75,12 @@ git_fetch() {
# shallow fetch a ref (master, branch or tag) with --depth=1
# (not allowed for a hash, unless remote is configured to permit
# it with allow*SHA1InWant).
- _depth="--depth 1"
+ _depth=""
+ # git provider does not support smart transport
+ if ! defined GIT_PROVIDER_NOT_SUPPORT_SMART_TRANSPORT


If you're going to add a variable which changes the behaviour of cygport 
like this, it should be documented (by adding an appropriate robodoc 
comment)


This could just be named something a little shorter, like 
"GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the URI's 
host?


But I wonder if wouldn't just be better to try with --depth and then 
fallback to without it, if that fails (especially if we can tell it 
failed for that reason).


(Looking at [1], that seems a better approach than trying to probe the 
URI for smart transport support, which seems problematic)


[1] 
https://stackoverflow.com/questions/9270488/is-it-possible-to-detect-whether-a-http-git-remote-is-smart-or-dumb


What do you think?


+ then
+ _depth="--depth 1"
+ fi
if defined GIT_TAG
then
_depth+=" --branch ${GIT_TAG}"

Re: Please support download setup-x86_64.exe on IPv6-only network

[Jon Turney via Cygwin]

On 16/11/2023 01:40, Bin W via Cygwin wrote:

https://www.cygwin.com/setup-x86_64.exe
IPv6-only network can't download the installer.


I've spoken to the people who speak to the people who actually 
administer the DNS for us, and an IPv6 DNS record has been added for 
cygwin.com.


If there are any other problems with using IPv6, please let us know.


--
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: [PATCH] Cygwin: Add /dev/disk/by-label and /dev/disk/by-uuid symlinks

[Corinna Vinschen]

On Nov 20 10:40, Corinna Vinschen wrote:
> Hi Christian,
> 
> This puzzles me:
> 
> On Nov 17 21:25, Christian Franke wrote:
> > @@ -610,7 +607,7 @@ get_by_id_table (by_id_entry * , 
> > fhandler_dev_disk::dev_disk_location loc)
> >if (!table)
> >  return (errno_set ? -1 : 0);
> >  
> > -  /* Sort by name and remove duplicates. */
> > +  /* Sort by name and mark duplicates. */
> >qsort (table, table_size, sizeof (*table), by_id_compare_name);
> >for (unsigned i = 0; i < table_size; i++)
> 
> by_id_compare_name only compars the actual names...
> 
> >  {
> > @@ -619,12 +616,13 @@ get_by_id_table (by_id_entry * , 
> > fhandler_dev_disk::dev_disk_location loc)
> > j++;
> >if (j == i + 1)
> > continue;
> > -  /* Duplicate(s) found, remove all entries with this name. */
> > -  debug_printf ("removing duplicates %d-%d: '%s'", i, j - 1, 
> > table[i].name);
> > -  if (j < table_size)
> > -   memmove (table + i, table + j, (table_size - j) * sizeof (*table));
> > -  table_size -= j - i;
> > -  i--;
> > +  /* Duplicate(s) found, append "#N" to all entries.  This never
> 
> ...but the names are identical.  So the *order* within the identically
> named entries depends on qsort's reshuffling of table
> entries.  Which in turn depends on outside factors like number of table
> entries and the ultimate position of the identical entries within the
> ordered table.
> 
> Having said that, I don't see how adding ordinals to the names can be
> unambiguous.  AFAICS, the numbers may change by just adding another
> disk (USB Stick) to the system...

Oops, that's not exactly what I was trying to say, sorry.

The problem is not adding ordinals to the name, AFAICS, the problem is
that the sorting function by_id_compare_name is not up to the task to
make sure the order is unambiguous within the entries of identical name.


Corinna

Re: [PATCH] Cygwin: Add /dev/disk/by-label and /dev/disk/by-uuid symlinks

[Corinna Vinschen]

Hi Christian,

This puzzles me:

On Nov 17 21:25, Christian Franke wrote:
> @@ -610,7 +607,7 @@ get_by_id_table (by_id_entry * , 
> fhandler_dev_disk::dev_disk_location loc)
>if (!table)
>  return (errno_set ? -1 : 0);
>  
> -  /* Sort by name and remove duplicates. */
> +  /* Sort by name and mark duplicates. */
>qsort (table, table_size, sizeof (*table), by_id_compare_name);
>for (unsigned i = 0; i < table_size; i++)

by_id_compare_name only compars the actual names...

>  {
> @@ -619,12 +616,13 @@ get_by_id_table (by_id_entry * , 
> fhandler_dev_disk::dev_disk_location loc)
>   j++;
>if (j == i + 1)
>   continue;
> -  /* Duplicate(s) found, remove all entries with this name. */
> -  debug_printf ("removing duplicates %d-%d: '%s'", i, j - 1, 
> table[i].name);
> -  if (j < table_size)
> - memmove (table + i, table + j, (table_size - j) * sizeof (*table));
> -  table_size -= j - i;
> -  i--;
> +  /* Duplicate(s) found, append "#N" to all entries.  This never

...but the names are identical.  So the *order* within the identically
named entries depends on qsort's reshuffling of table
entries.  Which in turn depends on outside factors like number of table
entries and the ultimate position of the identical entries within the
ordered table.

Having said that, I don't see how adding ordinals to the names can be
unambiguous.  AFAICS, the numbers may change by just adding another
disk (USB Stick) to the system...


Thanks,
Corinna