Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote: > For one, Mercurial has no staging area. That removes one level of > the three-level hierarchy from my toolset. It’s hard to identify > exactly when in my workflow this causes issues, but I’ve started to > notice it. For example, it’s not possible to commit a hunk from my > editor like I can with git and vim-gitgutter. > > I do the same with magit -- the staging area is a supreme benefit! I disagree. Anyway, what git does here is "git add --patch" and the hg eqivalent is "hg record" (which is not enabled by default; just add "record=" in an "[extensions]" block in your .hgrc to enable it), so the functionality is available for both tools. > Mercurial also collapses all changes within a pull request > (changeset) into a single commit. That's just not true (as the next two comments in the thread clarify). Thomas
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Tue, 28 Apr 2020 08:50:55 +, m...@netbsd.org wrote: Subject: Re: github.com/NetBSD/src 5 days old? > > As a reminder, hg/git offer far better interoperability (than CVS). > Much of my own NetBSD work is done on Git, and even if I don't stop > doing this, I would be happier if the backend was Mercurial. So I've still not found any discussion explaining the reasoning behind Mercurial vs. anything/everything else. For me as I work independently on NetBSD it doesn't really matter what the back-end is so long as I can use Git for my day-to-day work and to keep better track of my local changes. (That, btw, is still very much just a work in progress for me -- I've been unable to use the current repo on github as it breaks after updates far too often, i.e. whenever the conversion is unstable somehow.) However it would seem to me to be better and easier, for me, to be able to publish those of my changes that I would hope to feed back to the main NetBSD repository via Git, and in such a way that my original commit metadata does not get lost or squashed or rewritten in any way. As-is this has been a major stumbling block for me w.r.t. feeding back some of my changes and fixes in terms of sending patches, etc. while NetBSD still uses CVS. Not knowing Mercurial myself, nor how it interoperates with Git, I'm unsure of whether this is possible or not, especially given whatever workflows the NetBSD core team comes up with. However I recently encountered this essay by Jeremy Kun which has presented some of my less-well formed thoughts in a more concrete way, and in particular one of his replies to a comment that was posted about his essay: "The Communicative Value of Using Git Well" https://jeremykun.com/2020/01/14/the-communicative-value-of-using-git-well/#comment-110432 For one, Mercurial has no staging area. That removes one level of the three-level hierarchy from my toolset. It’s hard to identify exactly when in my workflow this causes issues, but I’ve started to notice it. For example, it’s not possible to commit a hunk from my editor like I can with git and vim-gitgutter. I do the same with magit -- the staging area is a supreme benefit! I guess that it wouldn't matter if one used Git for day-to-day work and the back-end was still Mercurial, but that very much begs the question of just what benefit Mercurial can possibly bring in the long run. Mercurial also collapses all changes within a pull request (changeset) into a single commit. That removes the meaningful difference between the top level (pull request) and the mid level (commit) that I find helpful to narrate. There is some ability when working locally to create a bunch of commits like I would in git, and then later squash them all using hg histedit. But my reviewers can’t see the individual commits, nor can they be seen or reverted individually in the long term project history. If this is the case it would also seem to be a major drawback to Mercurial. There are further comments that suggest this may not be quite so bad as Kun makes it sound, and indeed that part of his problem might actually be specific to the workflow that his employer forces, but there's also some ongoing doubt about this. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpZVBBmAGt5E.pgp Description: OpenPGP Digital Signature
daily CVS update output
Updating src tree: P src/crypto/dist/ipsec-tools/src/setkey/extern.h P src/crypto/dist/ipsec-tools/src/setkey/setkey.c P src/crypto/dist/ipsec-tools/src/setkey/token.l P src/lib/libc/sys/clone.2 P src/sbin/rndctl/rndctl.c P src/share/man/man7/hier.7 P src/sys/arch/mips/cavium/dev/octeon_rnm.c P src/sys/arch/mips/cavium/dev/octeon_rnmreg.h P src/sys/arch/x86/x86/cpu.c P src/sys/arch/x86/x86/identcpu_subr.c P src/sys/arch/xen/xen/xbd_xenbus.c P src/sys/fs/tmpfs/tmpfs_subr.c P src/sys/kern/kern_entropy.c P src/sys/kern/kern_fork.c P src/sys/kern/kern_mutex.c P src/sys/kern/kern_pmf.c P src/sys/kern/vfs_cache.c P src/sys/rump/include/rump/rump_namei.h P src/sys/sys/namei.h P src/sys/sys/namei.src P src/sys/sys/param.h P src/sys/sys/sched.h P src/sys/ufs/ffs/ffs_vfsops.c P src/sys/ufs/ufs/ufs_vnops.c P src/usr.sbin/sysinst/bsddisklabel.c P src/usr.sbin/sysinst/defs.h P src/usr.sbin/sysinst/disks.c P src/usr.sbin/sysinst/install.c P src/usr.sbin/sysinst/main.c P src/usr.sbin/sysinst/util.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38107174 May 13 03:11 ls-lRA.gz
Problem with groff building 9.0
On a system running: NetBSD toy.wan.vpn 8.99.26 NetBSD 8.99.26 (GEMINI) #0: Sun Nov 25 11:06:09 PST 2018 r...@toy.wan.vpn:/usr/src/BUILD_OBJ/sys/arch/i386/compile/GEMINI i386 /etc/mk.conf specifies: X11_TYPE=modular I built gcc8 and it resides in: : which cc /usr/pkg/gcc8/bin/cc I attempt to build NetBSD 9.0: Immediately before attempting to compile a "cvs update -Pd" of the source is at location: /home/downloads/NetBSD-9.0_src/src /home/downloads/NetBSD-9.0_src/xsrc : cat CVS/Tag Tnetbsd-9 : env HOST_CXX=/usr/pkg/gcc8/bin/g++ HOST_SH=/bin/sh SUDO_GID=20 DISPLAY=localhost:12.0 OLDPWD=/usr/pkgsrc USERNAME=root SUDO_COMMAND=/bin/bash SOURCE=/home/downloads/NetBSD-9.0_src/ USER=root HOST_CC=/usr/pkg/gcc8/bin/cc PWD=/home/downloads/NetBSD-9.0_src/src HOME=/root SUDO_USER=newhouse SUDO_UID=7769 MAIL=/var/mail/root SHELL=/bin/sh TERM=xterm SHLVL=1 LOGNAME=root PATH=/usr/pkg/gcc8:/usr/pkg/gcc8/bin:/usr/bin:/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/X11R7/bin:/usr/sbin:/sbin:. PS1=toy[root]: _=/usr/bin/env Building with this command: ./build.sh -O ./BUILD_OBJ -T ./BUILD_TOOL -R $SOURCE/src/xreleasedir -X $SOURCE/../xsrc makewrapper tools I get this with completel baffles me. checking for /usr/pkg/gcc8/bin/cc option to accept ANSI C... none needed checking whether we are using the GNU C++ compiler... yes checking whether /usr/pkg/gcc8/bin/g++ accepts -g... yes checking that C++ compiler can compile simple program... yes checking that C++ static constructors and destructors are called... no configure: error: a working C++ compiler is required *** Failed target: .configure_done *** Failed command: (cd build && AR=ar AWK=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/nbawk CC=/usr/pkg/gcc8/bin/cc CFLAGS=-O CONFIG_SHELL=/bin/sh CPPFLAGS=\ -I/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/include/compat\ -I/home/downloads/NetBSD-9.0_src/src/tools/compat\ \ -DHAVE_NBTOOL_CONFIG_H=1\ -D_FILE_OFFSET_BITS=64 CXX=/usr/pkg/gcc8/bin/g++ CXXFLAGS=-O INSTALL=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/i486--netbsdelf-install\ -c\ \ -r LDFLAGS= LEX=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/nblex FLEX=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/nblex M4=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/nbm4 MAKE=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/nbmake PATH="/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin:$PATH" RANLIB=ranlib YACC=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/nbyacc /bin/sh /home/downloads/NetBSD-9.0_src/src/tools/groff/../../external/gpl2/groff/dist/configure --without-x --prefix=/home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL) *** Error code 1 Stop. nbmake[3]: stopped in /home/downloads/NetBSD-9.0_src/src/tools/groff *** Failed target: dependall *** Failed command: cd "/home/downloads/NetBSD-9.0_src/src/tools/groff"; /home/downloads/NetBSD-9.0_src/src/./BUILD_TOOL/bin/nbmake realall *** Error code 1 The .../tools/groff directory contains only the files CVS and Makefile. cvs update -Pd doesn't add any files. Where did I go wrong? Hints and/or clues are appreciated, TIA, Paul N.
Re: pkgsrc current dbus build failure
Thank you all for your help. I did move /usr/pkgsrc to another location and pulled in (ftp) a fresh copy of current. That worked. Again, I can’t thank you guys enough. Well, maybe I could. On Sun, May 10, 2020 at 2:38 AM Roland Illig wrote: > On 09.05.2020 12:53, Roland Illig wrote: > > On 08.05.2020 18:36, Ron Georgia wrote: > >> 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. > > > > I didn't find NetBSD-9.99.60-amd64-install.img anywhere, therefore I > > used another ISO image. I installed NetBSD 8 in a VM and, like you, > > changed the pkgsrc path from stable to current. > > > > This way, pkgsrc was downloaded from > > https://ftp.netbsd.org/pub/pkgsrc/current/, where all files have been > > updated today in the morning. > > > > I would expect that these files are updated daily. There are exactly 7 > > days between 2020-05-02 and 2020-05-09 though, therefore it could also > > be that the files are updated weekly. I don't think that's the case, > > we'll see tomorrow. > > Indeed the archives in /pub/pkgsrc/current/ are only updated weekly. The > pkgsrc tree with the individual files is updated daily though. > > In such a case you can always "cvs update" locally since the archives > include the CVS metadata. > -- Ron Georgia “90% of my problems are due to ignorance, the other 10% is because I just don’t know any better.”
Re: arcmsr(4) update
On 11/05/2020 10:57, John Nemeth wrote: > I've been working on updating the arcmsr(4) driver which > supports Areca RAID controllers. This driver is originally from > OpenBSD's arc(4) driver but hasn't seen any updates since the > initial import (just maintenance). I have updated arcmsr(4) to > support all the devices currently support by OpenBSD's arc(4) > driver. It has been lightly tested on the 1280, 24 port PCIe SATA > controller and somewhat more on an 1880, PCIe 6 Gbps SAS controller. > I have not yet dealt with the bio(4) interface, so that part is > commented out. Please give it a try, especially with a card that > isn't currently supported. Also, people good with SMP, please have > a look. That's not my area, but I did my best to maintain the > locks as it is marked MPSAFE. I've been testing it with DIAGNOSTIC, > DEBUG, and LOCKDEBUG (this helping to find a locking bug that got > squashed). ARC-1882 with 1 disk attached works if I create a pass through disk with the controller in RAID mode, if I switch to JBOD mode, disk is never detected. Even though there is no RAID volume configured, kernel still waits with the following messages on reboot arcmsr0: timeout waiting to stop bg rebuild arcmsr0: timeout waiting to flush cache dmesg from a patched kernel with controller configured with a passthrough disk in RAID mode: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 9.99.60 (GENERIC) #0: Tue May 12 18:48:23 BST 2020 :/usr/obj/amd64/sys/arch/amd64/compile/GENERIC total memory = 16341 MB avail memory = 15811 MB entropy: entering seed from bootloader with 256 bits of entropy entropy: ready pool redzone disabled for 'buf4k' pool redzone disabled for 'buf64k' timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated running cgd selftest aes-xts-256 aes-xts-512 done RTC BIOS diagnostic error 0x3f timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 Dell Inc. OptiPlex 990 (01) mainbus0 (root) ACPI: RSDP 0x000FE300 24 (v02 DELL ) ACPI: XSDT 0xCF7FDE18 74 (v01 DELL CBX3 06222004 MSFT 00010013) ACPI: FACP 0xCF787D98 F4 (v04 DELL CBX3 06222004 MSFT 00010013) ACPI: DSDT 0xCF771018 007581 (v02 INT430 SYSFexxx 1001 INTL 20090903) ACPI: FACS 0xCF7E4E40 40 ACPI: FACS 0xCF7E4D40 40 ACPI: APIC 0xCF7FCF18 CC (v02 DELL CBX3 06222004 MSFT 00010013) ACPI: TCPA 0xCF7E5D18 32 (v02 ) ACPI: SSDT 0xCF788A98 0002F9 (v01 DELLTP TPM 3000 INTL 20090903) ACPI: MCFG 0xCF7E5C98 3C (v01 DELL SNDYBRDG 06222004 MSFT 0097) ACPI: HPET 0xCF7E5C18 38 (v01 A M I PCHHPET 06222004 AMI. 0003) ACPI: BOOT 0xCF7E5B98 28 (v01 DELL CBX3 06222004 AMI 00010013) ACPI: SSDT 0xCF77E818 0007C2 (v01 PmRef Cpu0Ist 3000 INTL 20090903) ACPI: SSDT 0xCF77D018 000996 (v01 PmRef CpuPm3000 INTL 20090903) ACPI: DMAR 0xCF7E4A18 B0 (v01 INTEL SNB 0001 INTL 0001) ACPI: 4 ACPI AML tables successfully acquired and loaded ioapic0 at mainbus0 apid 2: pa 0xfec0, version 0x20, 24 pins cpu0 at mainbus0 apid 0 cpu0: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7 cpu0: node 0, package 0, core 0, smt 0 cpu1 at mainbus0 apid 2 cpu1: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7 cpu1: node 0, package 0, core 1, smt 0 cpu2 at mainbus0 apid 4 cpu2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7 cpu2: node 0, package 0, core 2, smt 0 cpu3 at mainbus0 apid 6 cpu3: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7 cpu3: node 0, package 0, core 3, smt 0 acpi0 at mainbus0: Intel ACPICA 20200326 acpi0: X/RSDT: OemId , AslId acpi0: MCFG: segment 0, bus 0-63, address 0xf800 ACPI: Dynamic OEM Table Load: ACPI: SSDT 0x931DCB763448 000727 (v01 PmRef Cpu0Cst 3001 INTL 20090903) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0x9320D9417088 000303 (v01 PmRef ApIst3000 INTL 20090903) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0x931DCB74FD08 000119 (v01 PmRef ApCst3000 INTL 20090903) acpi0: SCI interrupting at int 9 acpi0: fixed power button present timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400) timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000 FWHD (INT0800) at acpi0 not configured LDRC (PNP0C02) at acpi0 not configured attimer1 at acpi0 (TIMR, PNP0100): io 0x40-0x43,0x50-0x53 irq 0 CWDT (INT3F0D) at acpi0 not configured COM1 (PNP0501) at acpi0 not configured PDRC (PNP0C02) at acpi0 not configured MEM2
Re: lang/mono6 fails build under -current
On Tue, 12 May 2020 at 14:03, wrote: > > On Mon, May 11, 2020 at 05:25:03PM +0100, Chavdar Ivanov wrote: > > Has anybody been able to build lang/mono6 under reasonably recent > > -current? I keep getting exciting crashes in various places, seem not > > to repeat, e.g. > > > I can build it. > > Setup: > userland: 9.99.51 (early March) > kernel: 9.99.59 (early May) Userland and kernel from yesterday, 11th of May > > GCC 8.4.0 Ditto > binutils 2.31.1 As far as I can see it, on this version of the system it is 2.34: nm -V GNU nm (NetBSD Binutils nb1) 2.34. I never run kernel and userland from different versions, as I use sysbuild and sysupgrade. > > Bare metal on a Ryzen 2700X. --
Re: lang/mono6 fails build under -current
On Mon, May 11, 2020 at 05:25:03PM +0100, Chavdar Ivanov wrote: > Has anybody been able to build lang/mono6 under reasonably recent > -current? I keep getting exciting crashes in various places, seem not > to repeat, e.g. I can build it. Setup: userland: 9.99.51 (early March) kernel: 9.99.59 (early May) GCC 8.4.0 binutils 2.31.1 Bare metal on a Ryzen 2700X.
Re: Problem with groff building 9.0
On Mon, May 11, 2020 at 10:30:28PM -0700, pimin inwa wrote: > HOST_CXX=/usr/pkg/gcc8/bin/g++ > HOST_CC=/usr/pkg/gcc8/bin/cc .. > configure: error: a working C++ compiler is required Removing these two lines will work around this issue. > checking that C++ static constructors and destructors are called... no If C++ static constructors rely on ELF constructors, this may be an issue that your binutils thinks your ld.so supports initfini array but does not. Or you are using GCC's crtstuff and it does not work for your setup. It needs more investigation like "which binutils, gcc, how was it built, was system..." Please ack that you are using mostly vanilla NetBSD 9.0 with vanilla lang/gcc8 for this setup.
Automated report: NetBSD-current/i386 test failure
This is an automatically generated notice of new failures of the NetBSD test suite. The newly failing test cases are: net/ipsec/t_ipsec_ah_keys:ipsec_ah_aesxcbcmac_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_hmacmd5_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_hmacripemd160_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_hmacsha1_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_hmacsha256_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_hmacsha384_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_hmacsha512_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_keyedmd5_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_keyedsha1_invalid_keys net/ipsec/t_ipsec_ah_keys:ipsec_ah_null_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_3descbc_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_aesctr_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_aesgcm16_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_aesgmac_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_blowfishcbc_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_camelliacbc_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_cast128cbc_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_descbc_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_desderiv_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_null_invalid_keys net/ipsec/t_ipsec_esp_keys:ipsec_esp_rijndaelcbc_invalid_keys The above tests failed in each of the last 4 test runs, and passed in at least 36 consecutive runs before that. The following commits were made between the last successful test and the failed test: 2020.05.10.19.36.49 maya src/lib/libc/gen/Makefile.inc,v 1.203 2020.05.10.19.54.49 christos src/crypto/dist/ipsec-tools/src/setkey/token.l,v 1.24 2020.05.10.21.40.38 riastradh src/sys/arch/aarch64/include/armreg.h,v 1.41 2020.05.10.21.41.19 riastradh src/sys/arch/aarch64/aarch64/cpu.c,v 1.44 2020.05.10.21.42.05 riastradh src/usr.sbin/cpuctl/arch/aarch64.c,v 1.9 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.05.html#2020.05.10.21.42.05
