From owner-freebsd-hackers@freebsd.org Thu Apr 8 07:25:31 2021 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 73B725D29DD for ; Thu, 8 Apr 2021 07:25:31 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FGCTk2mSKz4Vyj for ; Thu, 8 Apr 2021 07:25:29 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Thu, 08 Apr 2021 09:25:20 +0200 id 00DD0407.606EAFE0.00018236 Date: Thu, 8 Apr 2021 09:25:20 +0200 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: newvers.sh request Message-ID: <20210408092520.401b3772@zeta.dino.sk> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; i386-portbld-freebsd11.4) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4FGCTk2mSKz4Vyj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-2.81 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[84.245.65.72:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[84.245.65.72:from:127.0.2.255]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.51)[-0.508]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 07:25:31 -0000 Hi, in old svn days, uname output reflected svn revision number. We had svnlite in base system (if not set WITHOUT_SVN) and everything was done automagically when doing buildkernel process. Now, this is gone. Support for various revision string generation is built in sys/conf/newvers.sh script. When source tree is being tracket with git (recently gitup support is added), box where kernel is being built needs git installed (or gitup as an alternative) to be able to include this information in version string. For my use case, this is not practical. I am using git to track sources (or I am learning how to do it, first steps are done but still, it is different and I am figuring new features as I am trying), but I'd strongly prefer to use one box with larger disk capacity to hold all sources, mount needed worktree via nfs on box running buildkernel process, where I have minimal install, sometimes no port at all. Note: only worktree, not a full repository, so even having git installed would not help. Looking in newvers.sh script I found gitup was added and this inspired me to add just one more method covering my needs for such a distributed or detached build. Gitup loads its revision string from file .gituprevision, which is created when doing gitup src (exact invocation not relevant here). This file is just included verbatim in version string... so I hacked together similar thing: --- newvers.sh.orig 2021-04-08 07:35:02.506801000 +0200 +++ newvers.sh 2021-04-08 08:08:32.100985000 +0200 @@ -230,6 +230,11 @@ done fi +if findvcs .drevision; then + drevision="${VCSTOP}/.drevision" + echo "drevision ${drevision}" > ${VCSTOP}/.drevision-check +fi + if [ -n "$svnversion" ] ; then svn=$(cd ${SYSDIR} && $svnversion 2>/dev/null) case "$svn" in @@ -275,12 +280,16 @@ fi fi +if [ -n "$drevision" ] ; then + raw=" $(cat $drevision)" +fi + [ ${include_metadata} = "if-modified" -a ${modified} = "yes" ] && include_metadata=yes if [ ${include_metadata} != "yes" ]; then - VERINFO="${VERSION}${svn}${git}${hg} ${i}" + VERINFO="${VERSION}${svn}${git}${hg}${raw} ${i}" VERSTR="${VERINFO}\\n" else - VERINFO="${VERSION} #${v}${svn}${git}${hg}: ${t}" + VERINFO="${VERSION} #${v}${svn}${git}${hg}${raw}: ${t}" VERSTR="${VERINFO}\\n ${u}@${h}:${d}\\n" fi just using .drevision file for that purpose in order to explicitly signal usage of different mechanism for revision string generation. Variable names used are arbitrary. It is hard to invent something new, nice and meaningfull :) Usage is then - git fetch to update repository - git checkout to (new) worktree as needed, altering files as needed, adding patches as needed etc. for intended test - run some script generating .drevision file (site dependent, it could be based on how git hash et al. is used to generate revision string in order to remain compatible with the rest of the world) - mount worktree on a box where buildkernel is intended to run - run make buildkernel as usual I did this experiment on older 13-CURRENT tree, but idea could be used on newer tree as well. For curious: I am hacking on Zynq kernel and modules, there are generally not much resources, storage on SD card can wear fast, my setup allows me to minimize some bad side effects by reduced number of writes using nfs for large storage requirements. Also, editing is done on another box, only build process runs directly on Zynq board. Regards, Milan