Re: documentation on release build process change (svn -> git)?
On 8/29/20 5:48 PM, Glen Barber wrote: > On Sat, Aug 29, 2020 at 09:43:25PM +, Glen Barber wrote: >> On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote: [ .. ] >>> Nevermind, I see the problem. Standby. >>> >> >> r364966 should fix it. Thank you again for your help here. >> > > Sigh. r364968 should *really* fix it.. It does and without pulling ~1.2GB of GIT pack down :-) > Is it Friday yet? LOL :-) imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On 8/29/20 5:17 PM, Glen Barber wrote: > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote: >> The build-from-existing mode fails with .. >> >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf >> fatal: not a git repository (or any parent up to mount point /usr) >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). >> umount: /usr/local/release-builds/i386/dev: not a file system root directory >> > > Here's the fun part - Which revision was this? The host system is check-out from SVN r364964, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On 8/29/20 12:04 PM, Glen Barber wrote: > On Sat, Aug 29, 2020 at 03:51:23PM +, Glen Barber wrote: >> I added a way to update an existing tree in r364959. I have only done >> very trivial testing on this change, however, so please let me know if >> it does not work as expected. >> > r364960 further refines how this works; that would be a better revision > to use to test. The build-from-scratch mode now works to produce tar-balls and ISOs :-) However, I noticed that after building a clean amd64 tool-chain, it does fetch the amd64 GIT packages and dependencies (~76MB in all) before building 'all' for the target. No big deal but I usually prefer to build everything locally. The build-from-existing mode fails with .. imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf fatal: not a git repository (or any parent up to mount point /usr) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). umount: /usr/local/release-builds/i386/dev: not a file system root directory Many thanks for your efforts! imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenZFS support merged
On Sat, Aug 29, 2020 at 08:47 Kurt Jaeger wrote: > Hi! > > > > > r364746 merged OpenZFS support in to HEAD. > > > > > > The change should be transparent unless you want to use new features. > > > I caution against 'zpool upgrade' for the next few weeks. > > > https://svnweb.freebsd.org/base?view=revision=364746 > > > > A system running r363767 can upgrade to some revision after r364746 > > and reboot and come up without big issues, running the new openzfs code ? > > > > Or is some additional step required ? > Barring some unusual configuration that no one else there should not be a problem. The only known issue of immediate concern (that was only raised a day or two ago :-/) is zfs delegation in poudriere. If you rely on that I’d say wait a couple days, otherwise proceed. -M > > > -- > > p...@opsec.eu+49 171 3101372Now what ? > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 05:54:31PM -0400, Michael Butler wrote: > On 8/29/20 5:48 PM, Glen Barber wrote: > > On Sat, Aug 29, 2020 at 09:43:25PM +, Glen Barber wrote: > >> On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote: > > [ .. ] > > >>> Nevermind, I see the problem. Standby. > >>> > >> > >> r364966 should fix it. Thank you again for your help here. > >> > > > > Sigh. r364968 should *really* fix it.. > > It does and without pulling ~1.2GB of GIT pack down :-) > Awesome! Thank you very much for testing! > > Is it Friday yet? > > LOL :-) > :-) Glen signature.asc Description: PGP signature
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 09:43:25PM +, Glen Barber wrote: > On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote: > > On Sat, Aug 29, 2020 at 09:30:02PM +, Glen Barber wrote: > > > On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote: > > > > On 8/29/20 5:17 PM, Glen Barber wrote: > > > > > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote: > > > > >> The build-from-existing mode fails with .. > > > > >> > > > > >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf > > > > >> fatal: not a git repository (or any parent up to mount point /usr) > > > > >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not > > > > >> set). > > > > >> umount: /usr/local/release-builds/i386/dev: not a file system root > > > > >> directory > > > > >> > > > > > > > > > > Here's the fun part - Which revision was this? > > > > > > > > The host system is check-out from SVN r364964, > > > > > > > > > > Can you please try the attached patch against your release.sh? > > > > > > > Nevermind, I see the problem. Standby. > > > > r364966 should fix it. Thank you again for your help here. > Sigh. r364968 should *really* fix it.. Is it Friday yet? Glen signature.asc Description: PGP signature
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote: > On Sat, Aug 29, 2020 at 09:30:02PM +, Glen Barber wrote: > > On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote: > > > On 8/29/20 5:17 PM, Glen Barber wrote: > > > > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote: > > > >> The build-from-existing mode fails with .. > > > >> > > > >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf > > > >> fatal: not a git repository (or any parent up to mount point /usr) > > > >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not > > > >> set). > > > >> umount: /usr/local/release-builds/i386/dev: not a file system root > > > >> directory > > > >> > > > > > > > > Here's the fun part - Which revision was this? > > > > > > The host system is check-out from SVN r364964, > > > > > > > Can you please try the attached patch against your release.sh? > > > > Nevermind, I see the problem. Standby. > r364966 should fix it. Thank you again for your help here. Glen signature.asc Description: PGP signature
APM BIOS set to go in FreeBSD
Greetings, APM BIOS support will likely be removed from FreeBSD for FreeBSD 13. This was once quite important for LAPTOP users. However, it is now no longer relevant. It stopped being supported around the time that ACPI started to be released for laptops. This was around the Pentium 200MHz laptop generation, give or take. ACPI was released in 1996 to replace APM, and had largely done so by 2000. As such, this is 20-year obsolete technology. The current APM code has been basically untested for a long time. So it's unclear if the many blind changes to it have broken it or not. In addition, there are some timekeeping improvements I'd like to make to the kernel that APM is standing in the way of. I have no APM laptops that are still working (my last one I retired in 1998 or so and is no longer powering on). Rather than make yet another set of blind changes to a technology that's no longer relevant and surely completely unused, I'd like to retire APM in 13.0. To that end, I'm looking for actual users of this APM that have used the technology successfully in FreeBSD 12.0 or newer. Are there any such users left? Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 09:30:02PM +, Glen Barber wrote: > On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote: > > On 8/29/20 5:17 PM, Glen Barber wrote: > > > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote: > > >> The build-from-existing mode fails with .. > > >> > > >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf > > >> fatal: not a git repository (or any parent up to mount point /usr) > > >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not > > >> set). > > >> umount: /usr/local/release-builds/i386/dev: not a file system root > > >> directory > > >> > > > > > > Here's the fun part - Which revision was this? > > > > The host system is check-out from SVN r364964, > > > > Can you please try the attached patch against your release.sh? > Nevermind, I see the problem. Standby. Glen signature.asc Description: PGP signature
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote:
> On 8/29/20 5:17 PM, Glen Barber wrote:
> > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
> >> The build-from-existing mode fails with ..
> >>
> >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> >> fatal: not a git repository (or any parent up to mount point /usr)
> >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> >> umount: /usr/local/release-builds/i386/dev: not a file system root
> >> directory
> >>
> >
> > Here's the fun part - Which revision was this?
>
> The host system is check-out from SVN r364964,
>
Can you please try the attached patch against your release.sh?
Glen
Index: release/release.sh
===
--- release/release.sh (revision 364960)
+++ release/release.sh (working copy)
@@ -223,6 +223,8 @@ chroot_setup() {
if [ -z "${SRC_UPDATE_SKIP}" ]; then
if [ -d "${CHROOTDIR}/usr/src/.git" ]; then
${VCSUPDATE} -C ${CHROOTDIR}/usr/src
+ elif [ -d "${CHROOTDIR}/usr/src/.svn" ]; then
+ svn up ${CHROOTDIR}/usr/src
else
${VCSCMD} ${SRC} -b ${SRCBRANCH} ${CHROOTDIR}/usr/src
fi
@@ -230,6 +232,8 @@ chroot_setup() {
if [ -z "${NODOC}" ] && [ -z "${DOC_UPDATE_SKIP}" ]; then
if [ -d "${CHROOTDIR}/usr/doc/.git" ]; then
${VCSUPDATE} -C ${CHROOTDIR}/usr/doc
+ elif [ -d "${CHROOTDIR}/usr/doc/.svn" ]; then
+ svn up ${CHROOTDIR}/usr/doc
else
${VCSCMD} ${DOC} -b ${DOCBRANCH} ${CHROOTDIR}/usr/doc
fi
@@ -237,6 +241,8 @@ chroot_setup() {
if [ -z "${NOPORTS}" ] && [ -z "${PORTS_UPDATE_SKIP}" ]; then
if [ -d "${CHROOTDIR}/usr/ports/.git" ]; then
${VCSUPDATE} -C ${CHROOTDIR}/usr/ports
+ elif [ -d "${CHROOTDIR}/usr/ports/.svn" ]; then
+ svn up ${CHROOTDIR}/usr/ports
else
${VCSCMD} ${PORT} -b ${PORTBRANCH}
${CHROOTDIR}/usr/ports
fi
signature.asc
Description: PGP signature
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote: > On 8/29/20 12:04 PM, Glen Barber wrote: > > On Sat, Aug 29, 2020 at 03:51:23PM +, Glen Barber wrote: > >> I added a way to update an existing tree in r364959. I have only done > >> very trivial testing on this change, however, so please let me know if > >> it does not work as expected. > >> > > r364960 further refines how this works; that would be a better revision > > to use to test. > > The build-from-scratch mode now works to produce tar-balls and ISOs :-) > However, I noticed that after building a clean amd64 tool-chain, it does > fetch the amd64 GIT packages and dependencies (~76MB in all) before > building 'all' for the target. No big deal but I usually prefer to build > everything locally. > > The build-from-existing mode fails with .. > > imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf > fatal: not a git repository (or any parent up to mount point /usr) > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). > umount: /usr/local/release-builds/i386/dev: not a file system root directory > Here's the fun part - Which revision was this? > Many thanks for your efforts! > Many thanks for your bug reports! Glen signature.asc Description: PGP signature
Re: documentation on release build process change (svn -> git)?
On 8/29/20 11:14 AM, Glen Barber wrote: > NOPORTS=yes is the problem, and I forgot to address it before merging > the project branch back. Please try with r364956. Trying now but, in the interim, I noted .. With SVN, I could re-use a previously existing build directory and it would simply apply the relevant diffs to bring the tree up to date. In the move to GIT, now it seems I have to pull the whole tree down or it complains .. imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf fatal: destination path '/usr/local/release-builds/i386/usr/src' already exists and is not an empty directory. I'm not that familiar with GIT but .. Is there an incremental update option I can use? If so, should this be the default? As is, it seems like a colossal waste of bandwidth and unwanted load on the parent GIT repo, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On 8/28/20 1:44 PM, Glen Barber wrote: > Note, not entirely tested, however, since future snapshots and 13.0 will > be exclusively built from the git sources. When building with .. ## Set miscellaneous 'make release' settings. NODOC=yes NOPORTS=yes WITH_DVD=yes The build fails after building the target kernel but before building either the tar-balls or ISOs with .. >>> Kernel(s) GENERIC-NODEBUG built in 765 seconds, ncpu: 8, make -j4 -- make: "/usr/src/release/Makefile.inc1" line 14: "Git binary not found. Set GIT_CMD appropriately." It seems to want GIT in the chroot environment, because it's there on the host, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 03:51:23PM +, Glen Barber wrote: > On Sat, Aug 29, 2020 at 11:34:15AM -0400, Michael Butler wrote: > > On 8/29/20 11:14 AM, Glen Barber wrote: > > > NOPORTS=yes is the problem, and I forgot to address it before merging > > > the project branch back. Please try with r364956. > > > > Trying now but, in the interim, I noted .. > > > > With SVN, I could re-use a previously existing build directory and it > > would simply apply the relevant diffs to bring the tree up to date. > > > > In the move to GIT, now it seems I have to pull the whole tree down or > > it complains .. > > > > imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf > > fatal: destination path '/usr/local/release-builds/i386/usr/src' already > > exists and is not an empty directory. > > > > I'm not that familiar with GIT but .. Is there an incremental update > > option I can use? If so, should this be the default? As is, it seems > > like a colossal waste of bandwidth and unwanted load on the parent GIT repo, > > > > I added a way to update an existing tree in r364959. I have only done > very trivial testing on this change, however, so please let me know if > it does not work as expected. > r364960 further refines how this works; that would be a better revision to use to test. Glen signature.asc Description: PGP signature
Re: loading modules from loader | KLD file ... could not finalize loading
On 29 Aug 2020, at 0:16, Bjoern A. Zeeb wrote: Hi, I’ve been seeing on both i386 and arm64 builds where I tested that loading modules from loader will then fail by the kernel link in certain situations. I’ve created an i386 example where I do load a few modules from loader to show what I think the problem is. You may notice in the example output below that it seems modules depending on other loaded modules which seem to fail; e.g., ipfw seems to load but ipfw_* not; pf.ko seems to load but pflog.ko not, netgraph.ko seems to load but ng_*.ko fail. Anyone any ideas how I manage this? Trying to load them from console later using kldload seems to have similar issues. I wonder if I am missing something essential in my custom kernel builds or if this is a regression in head? Turns out this was a leaked strip command without --strip-debug which removed all the symbols. Sadly I checked inside the install tree but not on the finalized filesystem image. /bz Preloaded elf kernel "/boot/kernel/kernel" at 0x2da2000. Preloaded md_image "/base13-r364939" at 0x2daa650. Preloaded elf module "/boot/kernel/pf.ko" at 0x2daa6a0. Preloaded elf module "/boot/kernel/pflog.ko" at 0x2daaa58. Preloaded elf module "/boot/kernel/ipfw_nat.ko" at 0x2daadec. Preloaded elf module "/boot/kernel/ipfw.ko" at 0x2dab184. Preloaded elf module "/boot/kernel/libalias.ko" at 0x2dab540. Preloaded elf module "/boot/kernel/ipfw_nat64.ko" at 0x2dab900. Preloaded elf module "/boot/kernel/ipfw_nptv6.ko" at 0x2dabcc0. Preloaded elf module "/boot/kernel/ipfw_pmod.ko" at 0x2dac058. Preloaded elf module "/boot/kernel/mac_ntpd.ko" at 0x2dac3f0. Preloaded elf module "/boot/kernel/netgraph.ko" at 0x2dac760. Preloaded elf module "/boot/kernel/ng_ksocket.ko" at 0x2dacb20. Preloaded elf module "/boot/kernel/ng_l2tp.ko" at 0x2dace90. Preloaded elf module "/boot/kernel/ng_ppp.ko" at 0x2dad1fc. Preloaded elf module "/boot/kernel/ng_iface.ko" at 0x2dad568. Preloaded elf module "/boot/kernel/ng_tcpmss.ko" at 0x2dad928. Preloaded elf module "/boot/kernel/ng_socket.ko" at 0x2dadc70. Preloaded elf module "/boot/kernel/ng_tee.ko" at 0x2dae030. link_elf: symbol pf_rules_lock undefined KLD file pflog.ko - could not finalize loading link_elf: symbol LibAliasAddServer undefined KLD file ipfw_nat.ko - could not finalize loading link_elf: symbol layer3_chain undefined KLD file ipfw_nat64.ko - could not finalize loading link_elf: symbol layer3_chain undefined KLD file ipfw_nptv6.ko - could not finalize loading link_elf: symbol layer3_chain undefined KLD file ipfw_pmod.ko - could not finalize loading link_elf: symbol M_NETGRAPH undefined KLD file ng_ksocket.ko - could not finalize loading link_elf: symbol M_NETGRAPH_MSG undefined KLD file ng_l2tp.ko - could not finalize loading link_elf: symbol M_NETGRAPH_MSG undefined KLD file ng_ppp.ko - could not finalize loading link_elf: symbol M_NETGRAPH_MSG undefined KLD file ng_iface.ko - could not finalize loading link_elf: symbol M_NETGRAPH undefined KLD file ng_tcpmss.ko - could not finalize loading link_elf: symbol M_NETGRAPH_MSG undefined KLD file ng_socket.ko - could not finalize loading link_elf: symbol M_NETGRAPH undefined KLD file ng_tee.ko - could not finalize loading ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 11:34:15AM -0400, Michael Butler wrote: > On 8/29/20 11:14 AM, Glen Barber wrote: > > NOPORTS=yes is the problem, and I forgot to address it before merging > > the project branch back. Please try with r364956. > > Trying now but, in the interim, I noted .. > > With SVN, I could re-use a previously existing build directory and it > would simply apply the relevant diffs to bring the tree up to date. > > In the move to GIT, now it seems I have to pull the whole tree down or > it complains .. > > imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf > fatal: destination path '/usr/local/release-builds/i386/usr/src' already > exists and is not an empty directory. > > I'm not that familiar with GIT but .. Is there an incremental update > option I can use? If so, should this be the default? As is, it seems > like a colossal waste of bandwidth and unwanted load on the parent GIT repo, > I added a way to update an existing tree in r364959. I have only done very trivial testing on this change, however, so please let me know if it does not work as expected. Glen signature.asc Description: PGP signature
Re: OpenZFS support merged
Hi! > r364746 merged OpenZFS support in to HEAD. > > The change should be transparent unless you want to use new features. > I caution against 'zpool upgrade' for the next few weeks. > https://svnweb.freebsd.org/base?view=revision=364746 A system running r363767 can upgrade to some revision after r364746 and reboot and come up without big issues, running the new openzfs code ? Or is some additional step required ? -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: documentation on release build process change (svn -> git)?
On Sat, Aug 29, 2020 at 10:30:24AM -0400, Michael Butler wrote: > On 8/28/20 1:44 PM, Glen Barber wrote: > > > Note, not entirely tested, however, since future snapshots and 13.0 will > > be exclusively built from the git sources. > > When building with .. > > ## Set miscellaneous 'make release' settings. > NODOC=yes > NOPORTS=yes > WITH_DVD=yes > > The build fails after building the target kernel but before building > either the tar-balls or ISOs with .. > > >>> Kernel(s) GENERIC-NODEBUG built in 765 seconds, ncpu: 8, make -j4 > -- > make: "/usr/src/release/Makefile.inc1" line 14: "Git binary not found. > Set GIT_CMD appropriately." > > It seems to want GIT in the chroot environment, because it's there on > the host, > NOPORTS=yes is the problem, and I forgot to address it before merging the project branch back. Please try with r364956. Thank you for reporting this. Glen signature.asc Description: PGP signature
Re: Does FreeBSD have an assigned Internet OID?
Rick Macklem writes: > Poul-Henning Kamp wrote: > Is https://reviews.freebsd.org/D26225 > sufficient to allow me to use 1.3.6.1.4.1.2238.1.1.1 for a user@domain > name in this otherName component of subjAltName in the X.509 cert? > (I didn't list the UserName as the first item of the subtree. Should I?) You should add a comment about how suballocations (if allowed) happens under that branch. > Do I need to update the date/time for LAST-UPDATED and REVISION > when I commit it, I'd guess? Yes please. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
