Re: HELP ME OUT ! Trying to Convert .tar INTO .tar.md5

[Brian Inglis]

On 2018-03-19 07:46, Marco Atzeri wrote:
> Unlikely that Kashif is following the mailing list


Thanks: resent to OP; fingers default to Reply to List ;^>

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

--
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: GitForWindows vs. Cygwin

[Vince Rice]

> On Mar 20, 2018, at 7:24 PM, Tony Kelman  wrote:
> 
>>> Can anyone enlighten me about the relationship of "Git for Windows" to
>>> Cygwin?
>> 
>> They are not related.
> 
> Yes, they are.

No they're not.

It doesn't use cygwin, therefore it's not related. Since this is a cygwin 
mailing list,
that means the first two replies were correct — this isn't the place to discuss 
it.
--
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: GitForWindows vs. Cygwin

[Tony Kelman]

>> Can anyone enlighten me about the relationship of "Git for Windows" to
>> Cygwin?
>
> They are not related.

Yes, they are.

>> But now I hear of this GitForWindows thing.  Which seems to have replaced
>> MSysGit, with a GUI thrown in.  But is it _still_ a stale fork of Cygwin, or 
>> a
>> fork at all?  Is it descended from MSysGit?  I have been googling all over,
>> but not finding good answers.

GitForWindows 2.x is based on MSYS2, which doesn't share any non-cygwin
code with the old MSYS1 as far as I'm aware, but it reimplements (on
top of a much more up-to-date fork of cygwin) the path-mangling trick
that was the main motivating factor for using MSYS1 in the first place.
When you have a non-cygwin windows executable (one compiled by mingw.org,
or mingw-w64, or MSVC compilers) and try to pass it a posix/cygwin-style
absolute path, the windows executable won't usually recognize it as a
file that exists. What the MSYS shell does is apply a heuristic that
automatically translates posix-style absolute paths to Windows paths
(similar to manually calling `cygpath -w /posix/style/path` on each
argument within cygwin) before passing the argument to the executable.
There are other differences between MSYS2 and Cygwin, mostly that it
uses a different package manager and repository, but these are less
significant with respect to GitForWindows' requirements.

The git.exe in Cygwin's git package is a cygwin executable compiled
by cygwin's gcc. Hence it understands posix-style paths just fine,
but it depends on cygwin1.dll to do so, and may not perform as well as
a non-cygwin Windows executable. (Maybe someone has benchmarked this.)

GitForWindows has historically been compiled using mingw gcc -
the legacy and now-mostly-obsolete mingw.org in the git 1.x timeframe
(this is the reason there was not a 64 bit version of git.exe through
that release channel at the time), and more recently the mingw-w64
compilers for git 2.x. Many of your questions are answered at
https://github.com/git-for-windows/git/wiki/FAQ#what-is-the-relationship-between-git-for-windows-and-msysgit
https://github.com/git-for-windows/build-extra#components-of-the-git-for-windows-sdk
https://www.msys2.org

Some components used by git (any shell scripts, for example) require
some form of posix compatibility layer to function. The recent MinGit
has a busybox-based variant that can mostly avoid MSYS2 dependencies,
though it seems to have at least some small MSYS2 pieces remaining:
https://github.com/git-for-windows/git/wiki/MinGit#experimental-busybox-based-mingit

You can see exactly how the MSYS2 runtime used by GitForWindows differs
from the version used by the MSYS2 project itself by looking at the
git repo at https://github.com/git-for-windows/msys2-runtime/commits/master
and how MSYS2 differs from upstream cygwin by looking at the repos at
https://github.com/Alexpux/Cygwin/commits/msys2-master
https://github.com/mirror/newlib-cygwin/commits/master
https://github.com/mirror/newlib-cygwin/releases

These "patch sets" tend to get rebased pretty frequently when new
cygwin releases come out upstream.

I dunno where else this history has been written down, but this is
my understanding of the development heritage. Any git and/or MSYS2
maintainers can correct me if anything I stated here is incorrect.

-Tony

--
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: GitForWindows vs. Cygwin

[Andrey Repin]

Greetings, KARL BOTTS!


> Can anyone enlighten me about the relationship of "Git for Windows" to
> Cygwin?

They are not related.

> I have no intention to use GFW myself: I use Cygwin git.  But now other people
> around here are discovering GitHub, MSysGit and or GitForWindows.  Pretty
> soon, we are going to wind up with multiple git flavors installed on the same
> host, which worries me.

Erm, but how?

> But now I hear of this GitForWindows thing.  Which seems to have replaced
> MSysGit, with a GUI thrown in.  But is it _still_ a stale fork of Cygwin, or a
> fork at all?  Is it descended from MSysGit?  I have been googling all over,
> but not finding good answers.

You'd have better chance for the answers at their support channels.


-- 
With best regards,
Andrey Repin
Wednesday, March 21, 2018 02:40:11

Sorry for my terrible english...


--
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: GitForWindows vs. Cygwin

[Steven Penny]

On Tue, 20 Mar 2018 17:52:24, "KARL BOTTS" wrote:

Can anyone enlighten me about the relationship of "Git for Windows" to
Cygwin?


As this is not the "Git for Windows" forum, your question would be better served
if you actually linked to what you are talking about.


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

GitForWindows vs. Cygwin

[KARL BOTTS]

Can anyone enlighten me about the relationship of "Git for Windows" to
Cygwin?

I have no intention to use GFW myself: I use Cygwin git.  But now other people
around here are discovering GitHub, MSysGit and or GitForWindows.  Pretty
soon, we are going to wind up with multiple git flavors installed on the same
host, which worries me.

I know that MSysGit is basically a stale fork of Cygwin.  I tried it a long
time ago (during a period when the git in Cygwin was not getting updated
often), and it caused me trouble.  As I recall, the bash in it was only v3,
and I was used to v4, and some of my scripts didn't run right, and MSysGit
messed up my HOME dir.  Anyhow, I got rid of MSysGit.  And now that the git in
Cygwin is keeping current, I am quite content.

But now I hear of this GitForWindows thing.  Which seems to have replaced
MSysGit, with a GUI thrown in.  But is it _still_ a stale fork of Cygwin, or a
fork at all?  Is it descended from MSysGit?  I have been googling all over,
but not finding good answers.

I just want to watch out for the damn thing, and try to keep it away...

---
Karl Botts, kdbo...@usa.net


--
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] libgpg-error 1.28-1

[Yaakov Selkowitz]

On 2018-03-20 14:18, Ken Brown wrote:
> On 3/19/2018 9:14 PM, Yaakov Selkowitz wrote:
>> * mingw64-i686-libgpg-error-1.28-1
>> * mingw64-x86_64-libgpg-error-1.28-1
> 
> After this update, I get linking errors when trying to build setup:

Thanks; patch posted to cygwin-apps.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

[PATCH setup] Link with -lws2_32 again

[Yaakov Selkowitz]

libgpg-error 1.28 includes new APIs which use socket functions, which
on Win32 are provided by WinSock2.

https://cygwin.com/ml/cygwin/2018-03/msg00306.html

Signed-off-by: Yaakov Selkowitz 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7a5b2cd..0c27529 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -99,7 +99,7 @@ inilint_SOURCES = \
 
 @SETUP@_LDADD = \
libgetopt++/libgetopt++.la -lgcrypt -lgpg-error -llzma -lbz2 -lz -lsolv 
-lregex \
-   -lshlwapi -lcomctl32 -lole32 -lpsapi -luuid -lntdll -lwininet -lmingw32
+   -lshlwapi -lcomctl32 -lole32 -lpsapi -luuid -lntdll -lwininet -lws2_32 
-lmingw32
 @SETUP@_LDFLAGS = -mwindows -Wc,-static -static-libtool-libs
 @SETUP@_SOURCES = \
AntiVirus.cc \
-- 
2.16.2

Re: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Achim Gratz]

Ken Brown writes:
> I'll look into both of these issues, unless Jon beats me to it.

Thanks.

> By the way, this only affects local installs.  For network installs,
> the hash gets checked at an earlier stage.

That's correct.  I forgot to mention that, but all my installs are from
a local mirror (necessary due to the way network access is restricted at
my workplace).


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Ken Brown]

On 3/20/2018 2:23 PM, Achim Gratz wrote:


I've found out the hard way that a dodgy package file no longer gets
ignored by setup and is installed without any error unless you care to
look in setup.log.full.  That was hard to figure out because in my case
some stupid error on mirroring just made each file miss a few bytes off
the end, so it was always the last file in the archive that went missing
on unpacking.  I think that's evil and needs to be fixed promptly, but I
have no time to do it myself right now.  I honestly don't remember if
the old setup did the uninstall part before not installing the no-good
package (it probably ddin't), but I suggest it shouldn't uninstall
anything that we don't have a good replacement for.  Also, the messages
that go to the console about SHA512 failures need to be reinstated (a
good check can keep quiet).

WIth libsolve it seems that we will have to calculate a new solution
once we have to drop a package from the solution due to SHA512 mismatch,
then check any new packages in that revised solution again.  So it seems
we need to keep state around whether the package archive was already
checked (lest we check everything again each time).


It looks like there are two things going on here.  First, there must 
have been a glitch when the topic/libsolv branch was merged into master. 
 An inadvertent result of that glitch is that the response to the query 
'yesno (owner, IDS_SKIP_PACKAGE, e->what())' in do_install_thread() now 
gets discarded.  Second, as you said, we do have to avoid processing an 
'erase' transaction that's paired with an 'install' transaction that 
gets dropped.


I'll look into both of these issues, unless Jon beats me to it.

By the way, this only affects local installs.  For network installs, the 
hash gets checked at an earlier stage.


Ken

Re: [ANNOUNCEMENT] libgpg-error 1.28-1

[Ken Brown]

On 3/19/2018 9:14 PM, Yaakov Selkowitz wrote:

* mingw64-i686-libgpg-error-1.28-1
* mingw64-x86_64-libgpg-error-1.28-1


After this update, I get linking errors when trying to build setup:

  CXXLDsetup.exe
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x257): 
undefined reference to `__imp_closesocket'
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x2cf): 
undefined reference to `__imp_send'
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x399): 
undefined reference to `__imp_closesocket'
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x540): 
undefined reference to `__imp_htons'
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x54e): 
undefined reference to `__imp_inet_addr'
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x576): 
undefined reference to `__imp_socket'
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x595): 
undefined reference to `__imp_connect'
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libgpg-error.a(libgpg_error_la-logging.o):(.text+0x6a0): 
undefined reference to `__imp_closesocket'


Reverting to 1.27-1 fixes the problem.

Ken

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

[Bug] Re3gression in setup handling of SHA512 checksum failures

[Achim Gratz]

I've found out the hard way that a dodgy package file no longer gets
ignored by setup and is installed without any error unless you care to
look in setup.log.full.  That was hard to figure out because in my case
some stupid error on mirroring just made each file miss a few bytes off
the end, so it was always the last file in the archive that went missing
on unpacking.  I think that's evil and needs to be fixed promptly, but I
have no time to do it myself right now.  I honestly don't remember if
the old setup did the uninstall part before not installing the no-good
package (it probably ddin't), but I suggest it shouldn't uninstall
anything that we don't have a good replacement for.  Also, the messages
that go to the console about SHA512 failures need to be reinstated (a
good check can keep quiet).

WIth libsolve it seems that we will have to calculate a new solution
once we have to drop a package from the solution due to SHA512 mismatch,
then check any new packages in that revised solution again.  So it seems
we need to keep state around whether the package archive was already
checked (lest we check everything again each time).


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: X Server 1.19.6-2 , xset does not add ghostscript fonts for xfig

[Achim Gratz]

Ken Brown writes:
>> The 35 core postscript fonts are now in
>> /usr/share/fonts/urw-base35. But I'm not sure what you have to do to
>> make xfig find them.
>
> I just looked at Fedora's xfig packaging
> (https://src.fedoraproject.org/cgit/rpms/xfig.git), and the two most
> recent commits fix issues with the urw fonts.  So maybe Cygwin's xfig
> needs something similar.

I might do that although these patches look extra hairy.  But, reading
the commit messages I start to wonder if it's not the URW font package
that needs fixing (there might still be a need to patch some things in
xfig)?  I'd not want to fl+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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: X Server 1.19.6-2 , xset does not add ghostscript fonts for xfig

[Ken Brown]

On 3/19/2018 10:44 PM, Ken Brown wrote:

On 3/19/2018 9:02 PM, Andrew P Paplinski via cygwin wrote:

Dear Cygwin X,

I am running X Server 1.19.6-2 built 2018-03-12

I have the following error:

$ xset fp+ /usr/share/ghostscript/fonts/
xset:  bad font path element (#2), possible causes are:
 Directory does not exist or has wrong permissions
 Directory missing fonts.dir
 Incorrect font server address or syntax

The font directory does exist:

app@MU00108269 /usr/share/ghostscript
$ ls -l
total 12
drwxr-xr-x+ 1 app Domain Users 0 Mar 9 10:02 9.22
drwxr-xr-x+ 1 app Domain Users 0 Mar 9 10:02 fonts

Also

$ xset q
  Font Path:
   catalogue:/etc/X11/fontpath.d,built-ins

Without  ghostscript fonts  xfig  does not get the proper fonts.


The 35 core postscript fonts are now in /usr/share/fonts/urw-base35. But 
I'm not sure what you have to do to make xfig find them.


I just looked at Fedora's xfig packaging 
(https://src.fedoraproject.org/cgit/rpms/xfig.git), and the two most 
recent commits fix issues with the urw fonts.  So maybe Cygwin's xfig 
needs something similar.


Ken


--
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] Updated: weechat-2.1-1

[Sébastien Helleu]

Version 2.1-1 of "weechat" has been uploaded.

ChangeLog:

https://weechat.org/files/changelog/ChangeLog-2.1.html

DESCRIPTION
WeeChat is a fast, light and extensible chat client. It runs on many platforms
like Linux, Unix, BSD, GNU Hurd, Mac OS X and Windows (bash/ubuntu and
cygwin).

HOMEPAGE
https://weechat.org/

Sébastien Helleu.

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

Updated: weechat-2.1-1

[Sébastien Helleu]

Version 2.1-1 of "weechat" has been uploaded.

ChangeLog:

https://weechat.org/files/changelog/ChangeLog-2.1.html

DESCRIPTION
WeeChat is a fast, light and extensible chat client. It runs on many platforms
like Linux, Unix, BSD, GNU Hurd, Mac OS X and Windows (bash/ubuntu and
cygwin).

HOMEPAGE
https://weechat.org/

Sébastien Helleu.