Cedric Blancher via Cygwin wrote:
Good morning!
Does Cycgwin have a command to bind a new process to a specific set of
CPUs, e.g. bind /usr/bin/eatfrogs to CPU cores 3 and 4?
$ taskset -c 3,4 /usr/bin/eatfrogs
...
$ cygcheck -f /usr/bin/taskset
util-linux-2.39.3-2
--
Regards,
Christian
Good morning!
Does Cycgwin have a command to bind a new process to a specific set of
CPUs, e.g. bind /usr/bin/eatfrogs to CPU cores 3 and 4?
Ced
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
--
Problem reports: https://cygwin.com/problems.html
FAQ
On Nov 30 04:53, Martin Wege via Cygwin wrote:
> Hello,
>
> if I do a mount -o bind //foo/bar/baz /mnt the UNC path //foo/bar/baz
> is evaluated immediately, i.e. the network share //foo/bar/baz is
> "mounted" immediately.
>
> Is it possible to mount //foo/bar/
Hello,
if I do a mount -o bind //foo/bar/baz /mnt the UNC path //foo/bar/baz
is evaluated immediately, i.e. the network share //foo/bar/baz is
"mounted" immediately.
Is it possible to mount //foo/bar/baz only the first time someone does
a cd /mnt, sort of automounter-style "lazy&q
On Aug 11 17:37, Cedric Blancher via Cygwin wrote:
> On Tue, 8 Aug 2023 at 20:53, Corinna Vinschen
> wrote:
> >
> > On Aug 8 16:52, Cedric Blancher via Cygwin wrote:
> > > Good afternoon!
> > >
> > > How do I set mount posix=1 option for an existin
On Tue, 8 Aug 2023 at 20:53, Corinna Vinschen wrote:
>
> On Aug 8 16:52, Cedric Blancher via Cygwin wrote:
> > Good afternoon!
> >
> > How do I set mount posix=1 option for an existing bind mount? mount -o
> > remount does not work.
>
> Did you read https:/
On Aug 8 16:52, Cedric Blancher via Cygwin wrote:
> Good afternoon!
>
> How do I set mount posix=1 option for an existing bind mount? mount -o
> remount does not work.
Did you read https://cygwin.com/cygwin-ug-net/mount.html?
Mount points created by mount(1) only exist in the
Good afternoon!
How do I set mount posix=1 option for an existing bind mount? mount -o
remount does not work.
Ced
--
Cedric Blancher
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
--
Problem reports: https://cygwin.com/problems.html
FAQ: https
Greetings, All!
>> >The workaround I found was to recompile the sources, but making sure
>> >that -DFD_SETSIZE=16384 is defined during the configure stage. Patch
>> >attached below.
>> >
>> >Can someone please update the port with this bumped up FD_SETSIZE patch?
>>
>> If FD_SETSIZE is used to c
The following packages have been uploaded to the Cygwin distribution:
* bind-9.11.9-1
* bind-utils-9.11.9-1
* bind-doc-9.11.9-1
* libbind9_161-9.11.9-1
* libdns1106-9.11.9-1
* libirs161-9.11.9-1
* libisc1100-9.11.9-1
* libisccc161-9.11.9-1
* libisccfg163-9.11.9-1
* liblwres161-9.11.9-1
* libbind9
On Jun 5 15:06, Petr Skočík wrote:
> Hi.
>
> I don't know if this is technically a bug, but I've noticed that unlike
> on Linux or MacOS, I a cannot bind a unix domain socket in a child
> process and then listen on it in the parent.
>
> The bind succeeds but `lis
Hi.
I don't know if this is technically a bug, but I've noticed that unlike
on Linux or MacOS, I a cannot bind a unix domain socket in a child
process and then listen on it in the parent.
The bind succeeds but `listen()` in the parent then fails with EINVAL.
(The reason I'd like
report an
> > > crash on startup where, when the Notebook server tries to bind() to
> > > the port it will listen on (TCP ) the bind() fails and errno is
> > > set to EPERM, which is not an expected errno from bind().
> > >
> > > Looking at the Cyg
On Apr 23 14:28, E. Madison Bray wrote:
> On Tue, Apr 23, 2019 at 2:17 PM E. Madison Bray wrote:
> >
> > Hello,
> >
> > I have had some users of the Jupyter Notebook [1] on Cygwin report an
> > crash on startup where, when the Notebook server tries to bind() to
&g
On Apr 23 14:17, E. Madison Bray wrote:
> Hello,
>
> I have had some users of the Jupyter Notebook [1] on Cygwin report an
> crash on startup where, when the Notebook server tries to bind() to
> the port it will listen on (TCP ) the bind() fails and errno is
> set to EPER
On Tue, Apr 23, 2019 at 2:17 PM E. Madison Bray wrote:
>
> Hello,
>
> I have had some users of the Jupyter Notebook [1] on Cygwin report an
> crash on startup where, when the Notebook server tries to bind() to
> the port it will listen on (TCP ) the bind() fails and errno
Hello,
I have had some users of the Jupyter Notebook [1] on Cygwin report an
crash on startup where, when the Notebook server tries to bind() to
the port it will listen on (TCP ) the bind() fails and errno is
set to EPERM, which is not an expected errno from bind().
Looking at the Cygwin
The following packages have been uploaded to the Cygwin distribution:
* bind-9.11.6-1
* bind-utils-9.11.6-1
* bind-doc-9.11.6-1
* libbind9_161-9.11.6-1
* libdns1105-9.11.6-1
* libirs161-9.11.6-1
* libisc1100-9.11.6-1
* libisccc161-9.11.6-1
* libisccfg163-9.11.6-1
* liblwres161-9.11.6-1
* libbind9
The following packages have been uploaded to the Cygwin distribution:
* bind-9.11.5-2.P4
* bind-utils-9.11.5-2.P4
* bind-doc-9.11.5-2.P4
* libbind9_161-9.11.5-2.P4
* libdns1104-9.11.5-2.P4
* libirs161-9.11.5-2.P4
* libisc1100-9.11.5-2.P4
* libisccc161-9.11.5-2.P4
* libisccfg163-9.11.5-2.P4
Hello Csaba,
Cygwin package search tells us:
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=stringprep.h&arch=x86_64
> You probably need to install libidn-devel (which should drag in libidn)
Yeah you're right, its work for me ,
Many Thanks,
Meanwhile How i learning all dependencies package
Hi Onur,
On Thu, Oct 11, 2018 at 9:46 AM Onur GURSOY wrote:
>
> Hello Everyone,
>
> Nowadays, Im trying to many cyfwin package.
> I lookfor a dns server, i notice bind9 and i found a pacakage in cygwin.
> Everythin is ok but cygwin support binary package and source.
> Binary package is working very
Hello Everyone,
Nowadays, Im trying to many cyfwin package.
I lookfor a dns server, i notice bind9 and i found a pacakage in cygwin.
Everythin is ok but cygwin support binary package and source.
Binary package is working very well but when i try to compile from source
"cygport bind.cygport all"
do
The following packages have been uploaded to the Cygwin distribution:
* bind-9.11.2-1
* bind-utils-9.11.2-1
* bind-doc-9.11.2-1
* libbind9_160-9.11.2-1
* libdns169-9.11.2-1
* libirs160-9.11.2-1
* libisc166-9.11.2-1
* libisccc160-9.11.2-1
* libisccfg160-9.11.2-1
* liblwres160-9.11.2-1
* libbind9
The following packages have been uploaded to the Cygwin distribution:
* bind-9.11.0-3.P5
* bind-utils-9.11.0-3.P5
* bind-doc-9.11.0-3.P5
* libbind9_160-9.11.0-3.P5
* libdns166-9.11.0-3.P5
* libirs160-9.11.0-3.P5
* libisc160-9.11.0-3.P5
* libisccc160-9.11.0-3.P5
* libisccfg160-9.11.0-3.P5
Greetings, L A Walsh!
> Andrey Repin wrote:
>> I would argue against all junctions being treated blindly.
>> The difference with bind mounts in Linux is that in Linux
>> you don't have the
>> information available within the filesystem itself, and have
>>
gram(s) that are broken and don't detect
such loops, but at least the core utils do check -- and besides,
no one HAS to create junctions -- they can use symlinks as they do
today and no risk of such problems.
But treating linkd-junctions the same as mountvol-junctions allows
those bind-style m
On Mar 9 07:48, L A Walsh wrote:
> Andrey Repin wrote:
> > I would argue against all junctions being treated blindly.
> > The difference with bind mounts in Linux is that in Linux you don't have
> > the
> > information available within the filesystem itself, and ha
Andrey Repin wrote:
I would argue against all junctions being treated blindly.
The difference with bind mounts in Linux is that in Linux
you don't have the
information available within the filesystem itself, and have
no other option,
than to treat them as regular directories.
Only d
t is now, it's
> inconsistent with junctions created with mountvol being
> different from junctions created with linkd.
> Symlink(D)s would stay as they are now and provide the
> symlink functionality.
I would argue against all junctions being treated blindly.
The difference
Didn't see a response to this, so reposting, as this
would provide a needed vol and subdir mount facility as
exists on linux...
Especially, since there was a misunderstanding of what
was needed or wanted w/regards to the JUNCTION file-system
mounts in Windows. Didn't need mount table updated, j
I have a strange situation here: DiG 9.11.0-P3 does not work, but
nslookup does.
Target server XXX.220.6.135 is a Windows domain controller with the
following versions:
$ dig @160.220.6.135 version.bind txt chaos
> ;; Warning: query response not set
> ;; Warning: Message parser reports malforme
Corinna Vinschen wrote:
They
half-way work under Cygwin (junctions to volumes look like
mounted file systems look under linux, but junctions to
pathnames get converted by cygwin to symlinks -- losing
information when such junctions are restored.
Corinna -- could you _please_ re-look at suppor
The following packages have been uploaded to the Cygwin distribution:
* bind-9.11.0-2.P3
* bind-utils-9.11.0-2.P3
* bind-doc-9.11.0-2.P3
* libbind9_160-9.11.0-2.P3
* libdns166-9.11.0-2.P3
* libirs160-9.11.0-2.P3
* libisc160-9.11.0-2.P3
* libisccc160-9.11.0-2.P3
* libisccfg160-9.11.0-2.P3
The following packages have been uploaded to the Cygwin distribution:
* bind-9.11.0-1.P2
* bind-utils-9.11.0-1.P2
* bind-doc-9.11.0-1.P2
* libbind9_160-9.11.0-1.P2
* libdns166-9.11.0-1.P2
* libirs160-9.11.0-1.P2
* libisc160-9.11.0-1.P2
* libisccc160-9.11.0-1.P2
* libisccfg160-9.11.0-1.P2
The following packages have been uploaded to the Cygwin distribution:
* bind-9.10.4-4.P4
* bind-utils-9.10.4-4.P4
* bind-doc-9.10.4-4.P4
* libbind9_140-9.10.4-4.P4
* libdns165-9.10.4-4.P4
* libirs141-9.10.4-4.P4
* libisc160-9.10.4-4.P4
* libisccc140-9.10.4-4.P4
* libisccfg140-9.10.4-4.P4
The following packages have been uploaded to the Cygwin distribution:
* bind-9.10.4-3.P3
* bind-utils-9.10.4-3.P3
* bind-doc-9.10.4-3.P3
* libbind9_140-9.10.4-3.P3
* libdns165-9.10.4-3.P3
* libirs141-9.10.4-3.P3
* libisc160-9.10.4-3.P3
* libisccc140-9.10.4-3.P3
* libisccfg140-9.10.4-3.P3
The following packages have been uploaded to the Cygwin distribution:
* bind-9.10.4-2.P2
* bind-utils-9.10.4-2.P2
BIND is an implementation of the Domain Name System (DNS) protocols. The
DNS protocols are part of the core Internet standards. They specify the
process by which one computer can
The following packages have been uploaded to the Cygwin distribution:
* bind-9.10.3-3.P4
* bind-utils-9.10.3-3.P4
BIND is an implementation of the Domain Name System (DNS) protocols. The DNS
protocols are part of the core Internet standards. They specify the process
by which one computer can
The following packages have been uploaded to the Cygwin distribution:
* bind-9.10.3-2.P3
* bind-utils-9.10.3-2.P3
BIND is an implementation of the Domain Name System (DNS) protocols. The
DNS protocols are part of the core Internet standards. They specify the
process by which one computer can
The following package has been updated in the Cygwin distribution:
* bind-9.10.3-1
* bind-utils-9.10.3-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release:
ftp://ftp.isc.org/isc/bind9/9.10.3/RELEASE-NOTES.bind-9.10.3.html
(Note that
The following package has been updated in the Cygwin distribution:
* bind-9.10.2-4.P4
* bind-utils-9.10.2-4.P4
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release, which includes fixes
for CVE-2015-5722 and CVE-2015-5986:
http
The following package has been updated in the Cygwin distribution:
* bind-9.10.2-2.P2
* bind-utils-9.10.2-2.P2
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release, which includes a fix
for CVE-2015-4620:
http://ftp.isc.org/isc/bind9
On Fri, Jun 19, 2015 at 3:36 PM, Yaakov Selkowitz wrote:
> On Fri, 2015-06-19 at 14:24 -0600, Keith Christian wrote:
>> Updated to bind-utils-9.10.2-1 and neither dig nor host returns
>> output. There is a pause of about 0.7 seconds while dig runs.
>>
>> Strace shows
On Fri, 2015-06-19 at 14:24 -0600, Keith Christian wrote:
> Updated to bind-utils-9.10.2-1 and neither dig nor host returns
> output. There is a pause of about 0.7 seconds while dig runs.
>
> Strace shows quite a bit of dig activity but nothing returned.
>
> Anyone else havin
Tried to continue the previous thread but large attachments destroyed
the thread.
Updated to bind-utils-9.10.2-1 and neither dig nor host returns
output. There is a pause of about 0.7 seconds while dig runs.
Strace shows quite a bit of dig activity but nothing returned.
Anyone else having this
On Jun 9 06:53, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > I uploaded a new developer snapshot. Please give it a try:
> > https://cygwin.com/snapshots/
>
> Fix confirmed. Thanks!
Cool, thank you!
Corinna
--
Corinna Vinschen Please, send mails regarding
Corinna Vinschen cygwin.com> writes:
> I uploaded a new developer snapshot. Please give it a try:
> https://cygwin.com/snapshots/
Fix confirmed. Thanks!
Regards,
Achim.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On Jun 8 16:04, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > Easily reproducible, thank you. I think I found the culprit. mount(1)
> > always converts the mnt_fsname field to backslash notation. That breaks
> > converting the bind mount from the expe
Corinna Vinschen cygwin.com> writes:
> Easily reproducible, thank you. I think I found the culprit. mount(1)
> always converts the mnt_fsname field to backslash notation. That breaks
> converting the bind mount from the expected POSIX notation to a valid
> Win32 path.
>
>
On Jun 8 14:53, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > > //server/some/directory /mnt/server-share none binary 0 0
> > > #bind mounts
> > > /mnt/server-share/some/other/directory /mnt/task1 none binary,bind
> > >
> >
Corinna Vinschen cygwin.com> writes:
> > //server/some/directory /mnt/server-share none binary 0 0
> > #bind mounts
> > /mnt/server-share/some/other/directory /mnt/task1 none binary,bind
> >
> > That works well until I try to add another such bind mount
On Jun 8 10:39, Achim Gratz wrote:
> I've been using bind mounts to provide alternative paths into the same file
> system.
>
> //server/some/directory /mnt/server-share none binary 0 0
> #bind mounts
> /mnt/server-share/some/other/directory /mnt/task1 none, binary,bind
>
I've been using bind mounts to provide alternative paths into the same file
system.
//server/some/directory /mnt/server-share none binary 0 0
#bind mounts
/mnt/server-share/some/other/directory /mnt/task1 none, binary,bind
That works well until I try to add another such bind mount and act
The following package has been updated in the Cygwin distribution:
* bind-9.10.2-1
* bind-utils-9.10.2-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release:
https://kb.isc.org/article/AA-01153/81/BIND-9.10.0-Release-Notes.html
https
Greetings, Keith Christian!
>>> I'm sorry - I could be completely off-base here. What I meant was can you
>>> try running
>>> '/usr/bin/dig' (providing the full path to the application) rather than by
>>> just running 'dig'
>>> just in case there is some other 'dig' on your path (or shell aliases)
Yaakov, Brian, Andrey, Marco, and Mark -
I updated Cygwin this morning, and now: "dig works! I have no idea why!"
"cksum /usr/bin/dig /bin/dig" reports the same checksums as before,
and "cygcheck dig" produces the same output as before.
Baffling.
Thanks to all of you for the suggestions.
Thanks Mark, but I tried both of those early in my attempts without
success. Good suggestion, though.
On Wed, Apr 15, 2015 at 2:53 PM, Mark Hansen wrote:
> On 4/15/2015 12:02 PM, Keith Christian wrote:
>>
>> cygcheck attachment is too large according to sourceware.
>>
>> What specific parts of c
On 4/15/2015 12:02 PM, Keith Christian wrote:
cygcheck attachment is too large according to sourceware.
What specific parts of cygcheck are needed to help troubleshoot this?
Keith
On Wed, Apr 15, 2015 at 12:55 PM, Keith Christian
wrote:
Both /usr/bin/dig and /bin/dig run the same program:
cygcheck attachment is too large according to sourceware.
What specific parts of cygcheck are needed to help troubleshoot this?
Keith
On Wed, Apr 15, 2015 at 12:55 PM, Keith Christian
wrote:
> Both /usr/bin/dig and /bin/dig run the same program:
>
>>cksum /usr/bin/dig /bin/dig
> 680300229 22021
Are you sure that you're getting the correct dig executable? Is it possible
that something else in
your path or alias list is getting hit? Perhaps you can try /usr/bin/dig just
to be sure?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Do
On 4/14/2015 10:33 PM, Keith Christian wrote:
Thanks Marco, requested information below:
Tue Apr 14 14:31:02 pty2 >cygcheck dig
Found: C:\cygwin\bin\dig.exe
Found: C:\cygwin\bin\dig.exe
C:\cygwin\bin\dig.exe
C:\cygwin\bin\cyggcc_s-1.dll
C:\cygwin\bin\cygwin1.dll
as all Dll's are there
Thanks Marco, requested information below:
Tue Apr 14 14:31:02 pty2 >cygcheck dig
Found: C:\cygwin\bin\dig.exe
Found: C:\cygwin\bin\dig.exe
C:\cygwin\bin\dig.exe
C:\cygwin\bin\cyggcc_s-1.dll
C:\cygwin\bin\cygwin1.dll
C:\windows\system32\KERNEL32.dll
C:\windows\system32\API-MS-W
On 4/14/2015 8:39 PM, Keith Christian wrote:
Brian, Andre,
Thanks for the suggestions / info.
Examples below. "No output" means that dig provided no reply or
diagnostic info to the Cygwin screen as can be seen below, even when
asking for the internal help text.
Dig was working fine until the
y.
>>>
>>> ls -l /bin/dig shows:
>>>
>>> -rwxr-xr-x 1 keith Domain Users 2202141 Mar 18 20:05 /bin/dig
>
>> Anyone have suggestions? I've uninstalled and reinstalled bind-utils,
>> no improvement.
>
> Clarify "no output"? What
Greetings, Keith Christian!
>> nslookup returns normal output.
>>
>> An strace of dig shows nothing out of the ordinary.
>>
>> ls -l /bin/dig shows:
>>
>> -rwxr-xr-x 1 keith Domain Users 2202141 Mar 18 20:05 /bin/dig
> Anyone have suggestions? I
Keith Christian gmail.com> writes:
>
> Anyone have suggestions? I've uninstalled and reinstalled bind-utils,
> no improvement.
>
> On Fri, Apr 10, 2015 at 11:36 AM, Keith Christian
> gmail.com> wrote:
> > nslookup returns normal output.
> >
>
On Mon, 2015-04-13 at 09:25 -0600, Keith Christian wrote:
> Anyone have suggestions? I've uninstalled and reinstalled bind-utils,
> no improvement.
WFM, so:
> Problem reports: http://cygwin.com/problems.html
--
Yaakov
--
Problem reports: http://cygwin.com/pro
Anyone have suggestions? I've uninstalled and reinstalled bind-utils,
no improvement.
On Fri, Apr 10, 2015 at 11:36 AM, Keith Christian
wrote:
> nslookup returns normal output.
>
> An strace of dig shows nothing out of the ordinary.
>
> ls -l /bin/dig shows:
>
> -rwxr
The following package has been updated in the Cygwin distribution:
* bind-9.9.7-1
* bind-utils-9.9.7-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release for the 9.9 stable
branch. This release also fixes compatibility with XP x64
The following package has been updated in the Cygwin distribution:
*** bind-9.9.6-P1-2
*** bind-utils-9.9.6-P1-2
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release for the 9.9 stable
branch. This release also fixes compatibility with
On Nov 14 14:42, Brian Inglis wrote:
> henix gmail.com> writes:
> > Other commands in bind-utils (nslookup, host) have the same empty
> > result, while their 32bit version works just fine (on Windows 8.1
> > 64bit).
> Latest Cygwin release 1.7.33-1
henix gmail.com> writes:
> Other commands in bind-utils (nslookup, host) have the same empty
> result, while their 32bit version works just fine (on Windows 8.1
> 64bit).
Latest Cygwin release 1.7.33-1 aka 2 fixes this on Win7x64.
--
Problem reports: http://cygwin.com/probl
Corinna Vinschen cygwin.com> writes:
> On Nov 14 13:25, Brian Inglis wrote:
>> All bind-utils - host, nslookup, dig - output not to stdout or stderr - can
>> not be redirected, but redirection suppresses output, with current update
>> 9.9.6-2 but works with previous 9.
cannot be redirected.
> > $ dig +short google.com
> > 74.125.68.101
> > 74.125.68.138
> > 74.125.68.100
> > 74.125.68.102
> > 74.125.68.139
> > 74.125.68.113
> > $ dig +short google.com | tee dig.txt
> > $ cat dig.txt
> > (no text is shown)
gt; 74.125.68.113
> $ dig +short google.com | tee dig.txt
> $ cat dig.txt
> (no text is shown)
> $ dig +short google.com 2>&1 | tee dig.txt
> $ cat dig.txt
> (no text is shown)
All bind-utils - host, nslookup, dig - output not to stdout or stderr - can
not be redirected, but
>> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
>> Yaakov Selkowitz
>> Sent: Sunday, October 26, 2014 3:51 AM
>> To: cygwin@cygwin.com
>> Subject: Re: FW: bind-utils stdout pipe broken Cygwin x86_64 1.7.32+
>> On 2014-10-24 0
On 2014-10-24 09:41, Jon Retting wrote:
Sorry to report, but it would seem the new Cygwin versions break "bind-utils 9.9.5-3
-- 9.9.6-2" ability to stdout stdin.
Tested on:
CYGWIN_NT-6.1 1.7.32 - 1.7.33(0.278/5/3) 2014-10-22 10:37 x86_64 Cygwin
(w2k8r2)
CYGWIN_NT-6.3 1.7.32
Windows 8.1 64bit
setup.exe 2.850
bind-utils 9.9.6-2 9.9.5-3
Run this: dig www.google.com | cat
Expected: the output of dig
But was: empty
and the same empty result for:
* dig www.google.com > test.txt ; cat test.txt
* a=$(dig www.google.com) ; echo $a
Other commands in bind-utils (nsloo
Sorry to report, but it would seem the new Cygwin versions break "bind-utils
9.9.5-3 -- 9.9.6-2" ability to stdout stdin.
Tested on:
CYGWIN_NT-6.1 1.7.32 - 1.7.33(0.278/5/3) 2014-10-22 10:37 x86_64 Cygwin
(w2k8r2)
CYGWIN_NT-6.3 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygw
The following package has been updated in the Cygwin distribution:
*** bind-9.9.6-1
*** bind-utils-9.9.6-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release for the 9.9 stable
branch. This release also fixes compatibility with XP x64
mandb: warning: /usr/share/man/man1/xmond.1.gz: bad symlink or ROFF
`.so' request
$ cygcheck -f /usr/share/man/man1/bind9-config.1.gz
bind-utils-9.9.5-3
$ gzip -cd /usr/share/man/man1/bind9-config.1.gz
.so isc-config.sh.1
but there is no isc-config.sh.1 page in any cygwin package
$ cygche
The following package has been updated in the Cygwin distribution:
*** bind-9.9.5-3
*** bind-utils-9.9.5-3
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This release has been rebuilt for MIT Kerberos.
--
Yaakov
Cygwin/X
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thanks for the pointer! :)
On 05/13/2014 04:55 PM, Corinna Vinschen wrote:
> On May 13 16:19, Moritz Warning wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi,
>>
>> I try to bind a socke
On May 13 16:19, Moritz Warning wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> I try to bind a socket to a multicast address (239.192.202.5). But it fails
> with an error:
> "Cannot assign requested address"
>
> Is this not sup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I try to bind a socket to a multicast address (239.192.202.5). But it fails
with an error:
"Cannot assign requested address"
Is this not supported using Cygwin? I've added a simple test program in case
someone wants
to
The following package has been updated in the Cygwin distribution:
*** bind-9.9.5-1
*** bind-utils-9.9.5-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release.
--
Yaakov
Cygwin/X
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
The following package has been updated for both arches:
*** bind-9.9.4-P1-1
*** bind-utils-9.9.4-P1-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release.
--
Yaakov
Cygwin/X
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
oversight in
> packaging?
> >
> > Any advice on getting named up and running (I don't have the expertise yet
> to quickly write up a named.conf
> > file?)
>
> named.conf is going to be different for every installation. It's where you
> define the doma
tion. It's where you
define the domains that bind will serve. There are lots of details that can
be gotten wrong. If you get certain specific ones wrong your bind server
can be victimized into participating in DNS attacks.
Why do you need to run a DNS server? Is this for a local network on
I just installed BIND 9.9.3-P2 (Extended Support Version)
using 32-bit setup-x86.exe. I ran /usr/sbin/named-config and then
cygrunsrv -S named.
Bind's named server fails. It goes get started, but immediately dies.
The Events Log shows the foll
The following package has been updated for both arches:
*** bind-9.9.3-P2-1
*** bind-utils-9.9.3-P2-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release.
--
Yaakov
Cygwin/X
CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
On 2013-04-26 23:22, Rick McCombs AD5DU wrote:
This is not a show stopper, but I can get named to run.
Please try again with 9.9.3-P1.
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/doc
nfo: Check /etc/system.conf first, if it suits your needs.
Configuration finished. Have fun!
Rick@RickVista /usr/sbin
$ net start named
The CYGWIN BIND named service is starting.
The CYGWIN BIND named service could not be started.
The service did not report an error.
More help is available by typ
Hello,
I am experiencing a problem with BIND9.9.2-P1 on Cygwin throwing
"general: error: socket: file descriptor exceeds limit (128/64)".
This problem was reported previously "Re: 1.7.1: Bind 9.6.0-P1 on
Vista: could not listen on UDP socket: not enough free resources (patch
On Feb 4 11:03, Tanaka Akira wrote:
> Hi.
>
> I found bind(sock, addr, addrlen) function doesn't respect addrlen.
>
> If addr is AF_UNIX socket address and sun_path field is not
> NUL-terminated until the length specified as addrlen,
> bind() refer bytes after addrlen.
Hi.
I found bind(sock, addr, addrlen) function doesn't respect addrlen.
If addr is AF_UNIX socket address and sun_path field is not
NUL-terminated until the length specified as addrlen,
bind() refer bytes after addrlen.
This can be observed by created socket file name is longer
than exp
The following packages have been updated in the Cygwin distribution,
having been rebuilt for openldap-2.4:
*** apache2-2.2.23-2
*** apache2-devel-2.2.23-2
*** apache2-manual-2.2.23-2
*** bind-9.9.2-P1-2
*** bind-utils-9.9.2-P1-2
*** curl-7.28.1-2
*** libcurl4-7.28.1-2
*** libcurl-devel-7.28.1-2
Greetings, Yaakov (Cygwin/X)!
> The following package has been updated for the Cygwin distribution:
> *** bind-9.9.2-P1-1
> *** bind-utils-9.9.2-P1-1
> ISC BIND is a suite of Domain Name Service (DNS) utilities.
> This is an update to the latest upstream release. dig, host,
The following package has been updated for the Cygwin distribution:
*** bind-9.9.2-P1-1
*** bind-utils-9.9.2-P1-1
ISC BIND is a suite of Domain Name Service (DNS) utilities.
This is an update to the latest upstream release. dig, host, nslookup,
and nsupdate are now in a separate bind-utils
> On Thu, 2012-11-29 at 10:52 -0500, Andrew Schulman wrote:
> > It seems that host expects to find /usr/lib/engines/libgost.so. There's no
> > directory /usr/lib/engines in my installation, but there is
> > /usr/lib/openssl-1.0.1/engines/libgost.so.
>
> This is the culprit:
>
> > 1515k 2012/04/
1 - 100 of 157 matches
Mail list logo