daily CVS update output
Updating src tree: P src/external/cddl/osnet/dev/cyclic/cyclic.c P src/sys/arch/amd64/amd64/cpufunc.S P src/sys/arch/arm/acpi/acpipchb.c P src/sys/arch/x86/include/cpu_counter.h P src/sys/arch/x86/x86/cpu.c P src/sys/arch/x86/x86/tsc.c P src/sys/arch/x86/x86/x86_softintr.c P src/sys/arch/xen/xen/hypervisor.c P src/sys/dev/random.c P src/sys/dev/acpi/acpi_pci.c P src/sys/dev/acpi/acpi_pci.h P src/sys/dev/ic/hpet.c P src/sys/dev/ic/hpetvar.h P src/sys/dev/pci/cs4281.c P src/sys/dev/pci/if_msk.c P src/sys/dev/pci/if_skreg.h P src/sys/dev/usb/if_cdce.c P src/sys/kern/kern_clock.c P src/sys/kern/kern_entropy.c P src/sys/kern/kern_sleepq.c P src/sys/kern/sys_ptrace_common.c P src/sys/sys/entropy.h P src/sys/sys/sleepq.h Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc: collecting... replacing... done Updating release-8 src tree (netbsd-8): P bin/rcp/rcp.c U doc/CHANGES-8.3 Updating release-8 xsrc tree (netbsd-8): Updating release-8 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory) pax: WARNING! These file names were not selected: src/gnu done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src/x11: collecting...pax: Unable to access src/x11 (No such file or directory) pax: WARNING! These file names were not selected: src/x11 done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc/xfree: collecting...pax: Unable to access xsrc/xfree (No such file or directory) pax: WARNING! These file names were not selected: xsrc/xfree done xsrc: collecting... replacing... done Updating release-9 src tree (netbsd-9): P bin/rcp/rcp.c U doc/CHANGES-9.1 P sys/arch/arm/cortex/gic_v2m.c P sys/arch/arm/cortex/gic_v2m.h P sys/arch/arm/sunxi/sun4i_a10_ccu.c P sys/dev/sdmmc/if_bwfm_sdio.c P usr.bin/finger/finger.1 P usr.bin/finger/util.c P usr.sbin/lastlogin/lastlogin.8 P usr.sbin/lastlogin/lastlogin.c Updating release-9 xsrc tree (netbsd-9): Updating release-9 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting...
Re: How long to build from source?
On Fri, May 08, 2020 at 08:54:32AM -0400, Greg Troxel wrote: > Why do you need to know? It will almost certainly be less than a day. > Is that going to cause you do try netbsd, or not try netbsd? As others have said, it highly depends on your hard disk and amount of ram installed. Our build cluster takes ~7 hours to build all 67 ports (including debug info), see https://releng.netbsd.org/cgi-bin/builds.cgi A single port is faster: build.sh started:Fri May 8 04:51:23 UTC 2020 NetBSD version: 9.99.60 MACHINE: amd64 MACHINE_ARCH:x86_64 [..] Successful make release Successful make iso-image Successful make install-image build.sh ended: Fri May 8 08:01:00 UTC 2020 Your machine likely will be slightly slower. A new machine and a build without debug info will be lot faster. But for trying, there is no need to compile the source yourself, you can use the latest "daily" build from the build cluster: https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/ Martin
Re: pkgsrc current dbus build failure
Thank you for pointing that out. I am updating now. I downloaded the NetBSD-9.99.60-amd64-install.img (date stamped May 07, 2020) this morning and installed on my Lenovo X200. I did select the option to download pkgsrc. I changed the path from stable to current and that is what was pulled in. On 5/8/20 11:10 AM, Roland Illig wrote: On 08.05.2020 16:44, Ron Georgia wrote: Installed current NetBSD 9.99.60 (GENERIC) #0 and pkgsrc current on 05/08/2020 at about 0900 EST. I tried to build dbus but got an error when it tried to build perl5. sh: 1: Syntax error: Word "/d"p" unexpected (expecting ")") That was a bug in mk/subst.mk r1.91. It was fixed in r1.92, which is from 2020-05-02. This contradicts that you are using pkgsrc-current from 2020-05-08, which is 6 days later. -- “90% of my problems are due to ignorance, the other 10% is because I just don’t know any better.”
Re: pkgsrc current dbus build failure
On 08.05.2020 16:44, Ron Georgia wrote: Installed current NetBSD 9.99.60 (GENERIC) #0 and pkgsrc current on 05/08/2020 at about 0900 EST. I tried to build dbus but got an error when it tried to build perl5. sh: 1: Syntax error: Word "/d"p" unexpected (expecting ")") That was a bug in mk/subst.mk r1.91. It was fixed in r1.92, which is from 2020-05-02. This contradicts that you are using pkgsrc-current from 2020-05-08, which is 6 days later.
pkgsrc current dbus build failure
Installed current NetBSD 9.99.60 (GENERIC) #0 and pkgsrc current on
05/08/2020 at about 0900 EST. I tried to build dbus but got an error
when it tried to build perl5.
sh: 1: Syntax error: Word "/d"p" unexpected (expecting ")")
*** Error code 2
Stop.
make[1]: stopped in /usr/pkgsrc/lang/perl5
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/lang/perl5
I "fixed" the problem in the Makefile. See diff:
# diff Makefile Makefile.orig
277c277
< SUBST_SED.dirmode= -e "s/755/${PKGDIRMODE}/g;/umask/d"
---
> SUBST_SED.dirmode= -e "s/755/${PKGDIRMODE}/g;/umask(/d"
After that it failed again with the following message:
Making utilities
Everything is up to date. Type '/usr/bin/make test' to run test suite.
LD_LIBRARY_PATH=/usr/pkgsrc/lang/perl5/work/perl-5.30.2 ./perl -Ilib -I.
installperl --destdir=/usr/pkgsrc/lang/perl5/work/.destdir
Unmatched right curly bracket at ./install_lib.pl line 42, at end of line
syntax error at ./install_lib.pl line 42, near "}"
Compilation failed in require at installperl line 10.
BEGIN failed--compilation aborted at installperl line 11.
*** Error code 255
I removed the stray } and it finished building. See diff
# diff work/perl-5.30.2/install_lib.pl work/perl-5.30.2/install_lib.pl.orig
41a42
> }
--
“90% of my problems are due to ignorance, the other 10% is because I just don’t
know any better.”
Re: modload & xen and -current 9.99.60
On Fri, May 08, 2020 at 02:55:10PM +0200, Frank Kardel wrote: > I checked to same kernel in an instance with memory=2048 and it just works. > > Using todays kernel also works woth memory=2048. > > Using memory=65536 for the xen instance gives a surprising familiar > > TEST-A# modload bpfjit > [ 97.4727034] kobj_load, 444: [%M/bpfjit/bpfjit.kmod]: linker error: out of > memory > modload: bpfjit: Cannot allocate memory > TEST-A# > > So it seems to be linked to available memory. > > The more you have the less you get for modload. It could be a variable overflow somewhere but I can't see how it relates to 64Gb. Does it work with 16Gb ? Also could you try with a PVH or HVM guest ? These ones would use modules from /stand/amd64/ and not /stand/amd64-xen/ and should be close to native. I don't have a box with that much RAM to test ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: modload & xen and -current 9.99.60
I checked to same kernel in an instance with memory=2048 and it just works. Using todays kernel also works woth memory=2048. Using memory=65536 for the xen instance gives a surprising familiar TEST-A# modload bpfjit [ 97.4727034] kobj_load, 444: [%M/bpfjit/bpfjit.kmod]: linker error: out of memory modload: bpfjit: Cannot allocate memory TEST-A# So it seems to be linked to available memory. The more you have the less you get for modload. Frank On 05/07/20 22:52, Manuel Bouyer wrote: On Thu, May 07, 2020 at 09:50:18PM +0200, Frank Kardel wrote: see here: Alpine: 21:45 ~ [8] sysctl kern.module.path kern.module.path = /stand/amd64-xen/9.99.60/modules looks good Alpine: 21:46 ~ [9] ll /stand/amd64-xen/9.99.60/modules/bpfjit/bpfjit.kmod -r--r--r-- 1 root wheel 34328 May 5 16:58 /stand/amd64-xen/9.99.60/modules/bpfjit/bpfjit.kmod Alpine: 21:46 ~ [10] size /stand/amd64-xen/9.99.60/modules/bpfjit/bpfjit.kmod textdata bss dec hex filename 10399 0 0 10399289f /stand/amd64-xen/9.99.60/modules/bpfjit/bpfjit.kmod Alpine: 21:46 ~ [11] ll /stand/amd64-xen/9.99.60/modules/pciverbose/pciverbose.kmod -r--r--r-- 1 root wheel 140600 May 5 16:55 /stand/amd64-xen/9.99.60/modules/pciverbose/pciverbose.kmod Alpine: 21:47 ~ [12] size /stand/amd64-xen/9.99.60/modules/pciverbose/pciverbose.kmod textdata bss dec hex filename 132575 16 0 132591 205ef /stand/amd64-xen/9.99.60/modules/pciverbose/pciverbose.kmod no problem for me, with sources from today: xen1:/#modload bpfjit xen1:/#modstat | grep !$ö modstat | grep bpfjit bpfjit misc filesys -09174 sljit xen1:/#modload pciverbose xen1:/#modstat | grep !$ modstat | grep pciverbose pciverbose misc filesys -0 218 pci
Re: How long to build from source?
nottobay writes: > I have a 5 year old a8 laptop. How can I figure out how long compiling the > current source will take? Actually compile it and report back. Why do you need to know? It will almost certainly be less than a day. Is that going to cause you do try netbsd, or not try netbsd?
Re: How long to build from source?
On Fri, 8 May 2020, Benny Siegert wrote: The short answer: It depends. Slightly longer: Does the laptop have an SSD, an NVMe disk or a spinning hard drive? Which build options do you choose -- for instance, do you want to build X as well, do you want to build the graphics acceleration stuff (which requires building LLVM IIRC), etc. pp. Add to the questions: * How much RAM do you have? * Where is your /tmp located? tmpfs (in RAM)? SSD? spinning disk? I think it's going to be a couple hours. You could run the build overnight if you want. If you're also building in-tree X11, you can add a couple more hours to the estimate! :) ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: How long to build from source?
The short answer: It depends. Slightly longer: Does the laptop have an SSD, an NVMe disk or a spinning hard drive? Which build options do you choose -- for instance, do you want to build X as well, do you want to build the graphics acceleration stuff (which requires building LLVM IIRC), etc. pp. I think it's going to be a couple hours. You could run the build overnight if you want. On Fri, May 8, 2020 at 1:44 PM nottobay wrote: > > I have a 5 year old a8 laptop. How can I figure out how long compiling the > current source will take? -- Benny
How long to build from source?
I have a 5 year old a8 laptop. How can I figure out how long compiling the current source will take?
Re: github.com/NetBSD/src 5 days old?
On Thu, Apr 30, 2020 at 17:44 Constantine A. Murenin wrote: > On Sun, 26 Apr 2020 at 12:20, wrote: > >> On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: >> > I switched away from cvsup a while back, but I now see that github >> > NetBSD/src mirror is now 5 days old. Known issue? >> >> Yes, I believe joerg and spz are changing the conversion from >> cvs->??->git to hg->git, to match what will be done once we stop using >> CVS. >> > > What's wrong with "??"? I think it's pretty well-known that Fossil has > been the intermediary repository in NetBSD's conversion from CVS to Git > since 2011, and it would seem that https://src.fossil.netbsd.org/ is > still up-to-date, FWIIW, whereas GitHub's src is 7 days behind. > > I thought the plan to move to HG hasn't been finalised yet, am I missing > something? Plus, why HG and not Fossil, if the end-result consumption is > via Git anyways? > Last I heard fossil had scaling issues due to the large number of artifacts that needed to be tracked. I may be able to trawl notes and find some particulars, or Joerg may be able to comment from memory on the technical aspects. I was really hopeful for fossil as a solution as it seems really sane for many reasons: 1) good user interface(s) 2) good, novel ticket handling 3) sane architecture 4) portable C implementation 5) BSD license I think in the end though Joerg reckoned the scalability issue was too much. -bch > > C. >
