Re: rsync to anoncvs.NetBSD.org::cvsroot missing dirs?

[gary]

   I just did fresh checkouts from anoncvs and my own rsync clone. I see
no difference in the gcc.old directory, and while there is no gdb.old
directory, I see no difference in the gdb directory.

  Gary Duzan



=> I've been rsyncing against anoncvs (and/or mirrors) for ~years, without
=> issues. I've just noticed build issues, and tracked it down to the
=> following dirs missing from my rsync of the anoncvs repo:
=>
=> src/external/gpl3/gcc.old
=> src/external/gpl3/gdb.old
=>
=> Running a diff between a cvs checkout of the local rsync repo and a
=> cvs checkout direct from anoncvs seems to show quite a lot of stuff
=> missing from the rsync'ed repo (1854 dirs/files).
=> Permissions issue, perhaps?
=>
=> FYI: I'm currently rsyncing against anoncvs.NetBSD.org::cvsroot
=> I assume this is still a somewhat supported method of keeping up
=> to date sources?
=>
=> Cheers,
=> --
=> Paul Ripke
=> "Great minds discuss ideas, average minds discuss events, small minds
=>  discuss people."
=> -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
=>

Re: rsync to anoncvs.NetBSD.org::cvsroot missing dirs?

[matthew sporleder]

On Tue, Dec 1, 2015 at 11:03 PM, Paul Ripke  wrote:
> I've been rsyncing against anoncvs (and/or mirrors) for ~years, without
> issues. I've just noticed build issues, and tracked it down to the
> following dirs missing from my rsync of the anoncvs repo:
>
> src/external/gpl3/gcc.old
> src/external/gpl3/gdb.old
>
> Running a diff between a cvs checkout of the local rsync repo and a
> cvs checkout direct from anoncvs seems to show quite a lot of stuff
> missing from the rsync'ed repo (1854 dirs/files).
> Permissions issue, perhaps?
>
> FYI: I'm currently rsyncing against anoncvs.NetBSD.org::cvsroot
> I assume this is still a somewhat supported method of keeping up
> to date sources?
>
> Cheers,
> --
> Paul Ripke
> "Great minds discuss ideas, average minds discuss events, small minds
>  discuss people."
> -- Disputed: Often attributed to Eleanor Roosevelt. 1948.


I'm not sure if it's happened yet but a lot of our systems (anoncvs
included) are migrating.

I'm confident things will clear up over the next little bit.

Re: Strange error resolving non-existent hostname

[Andreas Gustafsson]

Thomas Klausner wrote:
> Recently, a mercurial test has started failing for me (7.99.21/amd64):
> 
> @@ -80,7 +80,7 @@
>$ echo 'http://does.not.exist/bundle.hg' > server/.hg/clonebundles.manifest
>$ hg clone http://localhost:$HGPORT 404-url
>applying clone bundle from http://does.not.exist/bundle.hg
> -  error fetching bundle: * not known (glob)
> +  error fetching bundle: No address associated with hostname
>abort: error applying bundle
>(if this error persists, consider contacting the server operator or 
> disable clone bundles via "--config experimental.clonebundles=false")
>[255]
> 
> ERROR: test-clonebundles.t output changed
> 
> 
> In other words, the test tries resolving does.not.exist and expects
> any error message ending with 'not known' but gets the one for
> EAI_NODATA, in contrast to all other operating systems (according to
> the mercurial author).
> 
> Can someone else please try this, to make sure it's not my DNS setup?
> 
> cd /usr/pkgsrc/devel/py-mercurial && make test

I see the same error on 6.1.4.

Here's a simpler test:

   $ telnet nosuch
   nosuch: No address associated with hostname

I get the above (incorrect) output on both 6.1.4 and -current.

> Any ideas what could be the reason for this?

Looks like a bug in NetBSD's getaddrinfo() to me.
-- 
Andreas Gustafsson, g...@gson.org

no vga* at pci?

[Rhialto]

If I configure a (amd64, 7.0) kernel with

no vga*   at pci?

then it fails to boot (properly). This is despite the fact that no "vga
at pci" ever seems to get configured (so it is unneeded). Instead, I have

acpivga0 at acpi0 (OVGA): ACPI Display Adapter

What happens is rather strange. After the kernel is loaded, the
copyright message does not appear. After a few moments the screen is
however switched to graphics mode and the text that happens to be
on-screen is converted to it. The colour is however not the usual green
but something fairly dark and hardly visible. The caps-lock led reacts.

One could think that the kernel is continuing with the boot process but
without further feedback, but waiting a while never results in being
able to log in with ssh.

Any idea why vga is more important than it seems to be?

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature

Re: no vga* at pci?

[Michael van Elst]

rhia...@falu.nl (Rhialto) writes:

>If I configure a (amd64, 7.0) kernel with

>no vga*   at pci?

>then it fails to boot (properly).

It probably fails to establish a console.
-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: no vga* at pci?

[Felix Deichmann]

2015-12-02 23:37 GMT+01:00 Rhialto :
> Any idea why vga is more important than it seems to be?

Sounds as bothersome as the need to use a "LEGACY" kernel when you
have vga@isa...

Felix

daily CVS update output

[NetBSD source update]

Updating src tree:
P src/distrib/sets/lists/modules/mi
P src/lib/libc/net/getaddrinfo.c
P src/sbin/gpt/Makefile
P src/sbin/gpt/add.c
P src/sbin/gpt/backup.c
P src/sbin/gpt/biosboot.c
P src/sbin/gpt/create.c
P src/sbin/gpt/destroy.c
P src/sbin/gpt/gpt.8
P src/sbin/gpt/gpt.c
P src/sbin/gpt/gpt.h
P src/sbin/gpt/gpt_uuid.c
P src/sbin/gpt/header.c
P src/sbin/gpt/label.c
P src/sbin/gpt/main.c
P src/sbin/gpt/map.c
P src/sbin/gpt/map.h
P src/sbin/gpt/migrate.c
P src/sbin/gpt/recover.c
P src/sbin/gpt/remove.c
P src/sbin/gpt/resize.c
P src/sbin/gpt/resizedisk.c
P src/sbin/gpt/restore.c
P src/sbin/gpt/set.c
P src/sbin/gpt/show.c
P src/sbin/gpt/type.c
P src/sbin/gpt/unset.c
cvs update: `src/sys/compat/common/compat_sysv_mod.c' is no longer in the 
repository
P src/sys/compat/common/sysv_ipc_50.c
P src/sys/compat/linux/common/linux_mod.c
P src/sys/compat/netbsd32/netbsd32_mod.c
P src/sys/kern/files.kern
P src/sys/kern/init_sysent.c
P src/sys/kern/syscalls.c
P src/sys/kern/syscalls.master
P src/sys/kern/syscalls_autoload.c
P src/sys/kern/systrace_args.c
P src/sys/kern/sysv_ipc.c
P src/sys/modules/Makefile
cvs update: `src/sys/modules/compat_sysv/Makefile' is no longer in the 
repository
P src/sys/modules/sysv_ipc/Makefile
P src/sys/net/if_gif.c
P src/sys/rump/include/rump/rump_syscalls.h
P src/sys/rump/librump/rumpkern/rump_syscalls.c
P src/sys/sys/syscall.h
P src/sys/sys/syscallargs.h
P src/tests/net/arp/t_arp.sh

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Thu Dec  3 03:29:24 2015
SUP Scan for current completed at Thu Dec  3 03:43:29 2015
SUP Scan for mirror starting at Thu Dec  3 03:43:29 2015
SUP Scan for mirror completed at Thu Dec  3 05:12:31 2015




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  56427384 Dec  3 05:30 ls-lRA.gz

Re: Strange error resolving non-existent hostname

[Joerg Sonnenberger]

On Wed, Dec 02, 2015 at 10:22:48AM +0200, Andreas Gustafsson wrote:
> Here's a simpler test:
> 
>$ telnet nosuch
>nosuch: No address associated with hostname
> 
> I get the above (incorrect) output on both 6.1.4 and -current.
> 
> > Any ideas what could be the reason for this?
> 
> Looks like a bug in NetBSD's getaddrinfo() to me.

Linux provides exactly the same output.

Joerg

Re: Strange error resolving non-existent hostname

[Andreas Gustafsson]

Joerg Sonnenberger wrote:
> >$ telnet nosuch
> >nosuch: No address associated with hostname
> > 
> > I get the above (incorrect) output on both 6.1.4 and -current.
> > 
> > > Any ideas what could be the reason for this?
> > 
> > Looks like a bug in NetBSD's getaddrinfo() to me.
> 
> Linux provides exactly the same output.

My Linux system doesn't:

  $ uname -a; telnet nosuch
  Linux gurli 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:35:26 UTC 2012 i686 
GNU/Linux
  telnet: could not resolve nosuch/telnet: Name or service not known

Nor does Mac OS X:

  $ uname -a; telnet nosuch
  Darwin guinea.araneus.fi 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep  1 
21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64
  nosuch: nodename nor servname provided, or not known

The point being that the correct message is whatever corresponds to
a getaddrinfo() return value of EAI_NONAME, not EAI_NODATA.

See also PR 44915.
-- 
Andreas Gustafsson, g...@gson.org