> On Sat, Sep 27, 2014 at 10:46 AM, <[email protected]> wrote:
> > On Sat, 27 Sep 2014 09:02:52 +0300
> >> On Sat, Sep 27, 2014 at 7:10 AM, <[email protected]> wrote:
> >> > i encounter this error when building the (RAMDISK_CD) distrib kernel:
> >> > usage: maketz.sh DESTDIR
> >> ...
> >> > maybe the method i have been using to build distrib is outdated.
> >> > currently i do:
> >> > # (cd /usr/src/distrib/special/libstubs && make)
> >> > # cd /usr/src/distrib/i386/ramdisk_cd && make
> >> > which i got some years ago from one of these lists. is this still the
> >> > preferred
> >> > method?
> >>
> >> I don't think that was ever correct. The procedure for building a
> >> release is documented in release(8).
> >>
> >> (Why does that procedure install into a clean directory and assemble
> >> the release out of that? To absolutely guarantee that it cannot pick
> >> up a file left over in the running install from a previous version.)
> >
> > i guess it isn't clear, but i was never trying to make the release, only the
> > kernel. i've reconfigured them for live cd's and such.
>
> You are building the ramdisk, which is part of the release. You may
> be able to skip some of the steps involved because you don't want the
> .tgz outputs, but if you want to use the scripts that OpenBSD provides
> for this then you need to follow the base steps, including setting
> DESTDIR and installing into that.
so DESTDIR is set by some earlier process, so my first suggestion was wrong
($DESTDIR -> ${TARGDIR}). but that's only what got me looking, and is
irrelevent to the issue of the use of 'maketz.sh'.
what i am concerned with there is when distrib/miniroot/list2sh.awk is run, to
create the bsd.rd miniroot 'var/tzlist', the relevant line in list2sh.awk is:
printf("(cd ${TARGDIR}; sh $UTILS/maketz.sh $DESTDIR)\n");
which calls maketz.sh:
#!/bin/sh
destdir=$1
if [ $# -lt 1 ]; then
echo usage: maketz.sh DESTDIR
exit 0
fi
(
cd $destdir/usr/share/zoneinfo
ls -1dF `tar cvf /dev/null [A-Za-y]*`
) > var/tzlist
however my questioning of 'maketz.sh' use is sound, and it can be bypassed
altogether in 'list2sh.awk':
printf("(cd $DESTDIR/usr/share/zoneinfo && ls -1dF `tar cvf /dev/null
[A-Za-y]*`) >var/tzlist");
as it stands, if $DESTDIR is unset it gives the error i first mentioned:
usage: maketz.sh DESTDIR
and no 'var/tzlist' is created, which presumably will not happen if i were
using it 'properly'.
with the change to 'list2sh.awk' above, if $DESTDIR is unset, then it merely
does the same thing as if $DESTDIR=/
so if $DESTDIR is unset, it does 'cd /usr/share/zoneinfo'.
and if $DESTDIR is set (to / as in release(8)) then it does
'cd //usr/share/zoneinfo'
and if there is no $DESTDIR/usr/share/zoneinfo, it doesn't create a file of
potentially random crap (the &&).
so, with the below patch, if $DESTDIR is set, is should function as it does
now, and 'maketz.sh' can be eliminated altogether. and if DESTDIR is unset,
it still works (presumably there will always be a /usr/share/zoneinfo on
any system building release)
--- list2sh.awk.orig Fri Feb 21 14:33:31 2014
+++ list2sh.awk Sat Sep 27 05:35:09 2014
@@ -60,7 +60,7 @@ $1 == "CRUNCHSPECIAL" {
}
$1 == "TZ" {
printf("echo '%s'\n", $0);
- printf("(cd ${TARGDIR}; sh $UTILS/maketz.sh $DESTDIR)\n");
+ printf("(cd $DESTDIR/usr/share/zoneinfo && ls -1dF `tar cvf /dev/null
[A-Za-y]*` >${TARGDIR}/var/tzlist)");
next;
}
$1 == "COPYDIR" {
and i knew i was probably missing something, this was the reason for all the
question marks. i knew DESTDIR had to have been set if releases were to be
built at all. i was just questioning what the situation was, and now i know.
i didn't look at release(8) because i hadn't considered its relevance, thought
in retrospect should have. i just ran across this using a procedure i was
perhaps overly familiar with and forgot what it was a part of. but this is
sometimes how bugs are discovered and other improvements made, by using things
in ways that are not common, and looking at things not commonly looked at. the
common things get noticed.
and i wouldn't have said anything at all if i didn't think i had something
with 'maketz.sh'.
i know what i was doing was 'unsupported', and things could get broken, but it
hasn't failed me yet. i would've just ignored the maketz.sh error as i have
been.
so is there a better way to just build a kernel? i'm not going to build a
whole release just for one kernel, especially when experimenting. and i mean
a RAMDISK kernel. i think its great the things i can do with openbsd, even
when it is not what is intended.
> Is it worth your time to change those scripts locally (and maintain
> those changes as we evolve the scripts for *our* purposes) instead of
> just running them and then ignoring half the results? How much is
> your time worth?
are you saying i should just build the whole release and ignore half the
results? i have old, slow computers, which is another plus for openbsd, no
bloat.
as to maintaining my own versions, i customize things, it goes with the
territory. is it any more complicated than upgrading /etc? i have my own
scripts to automate things too. it's not hard to check if something has
changed.
and once more, i ONLY brought this up because of maketz.sh looks irrelevent.
i have been using openbsd for more years than i can honestly remember, i know
nobody here 'makes music for the fans'.
> > also, i am subscribed to the list.
>
> <shurg> We can't tell that or read your mind. The default assumption
> is that replies should go to both the poster and the list; you're
> welcome to set the Reply-To on your messages to point to the list if
> you don't want the direct message.
i didn't mean anything by it, i understand the (sensible) assumption and was
merely giving feedback, otherwise obviously you wouldn't know. i'll remember
the reply-to bit.
