Re: maketz.sh problems with distrib build

2014-09-27 Thread Philip Guenther 
On Sat, Sep 27, 2014 at 7:10 AM,  thev...@openmailbox.org 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.)


Philip Guenther

Re: maketz.sh problems with distrib build

2014-09-27 Thread THEvoid 
On Sat, 27 Sep 2014 09:02:52 +0300
 On Sat, Sep 27, 2014 at 7:10 AM,  thev...@openmailbox.org 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.)
 
 
 Philip Guenther

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.

also, i am subscribed to the list.

Re: maketz.sh problems with distrib build

2014-09-27 Thread Philip Guenther 
On Sat, Sep 27, 2014 at 10:46 AM,  thev...@openmailbox.org wrote:
 On Sat, 27 Sep 2014 09:02:52 +0300
 On Sat, Sep 27, 2014 at 7:10 AM,  thev...@openmailbox.org 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.

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?


 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.


Philip Guenther

Re: maketz.sh problems with distrib build

2014-09-27 Thread THEvoid 
 On Sat, Sep 27, 2014 at 10:46 AM,  thev...@openmailbox.org wrote:
  On Sat, 27 Sep 2014 09:02:52 +0300
  On Sat, Sep 27, 2014 at 7:10 AM,  thev...@openmailbox.org 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.origFri 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

Re: maketz.sh problems with distrib build

2014-09-27 Thread Theo de Raadt 
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.

tough.

I'm sorry, but this is the build process that makes snapshots.  It serves
that purpose and is designed for that.  It is not carveable in the way
you want to use it.  It will not be changed.  You are on your own, really.

Re: maketz.sh problems with distrib build

2014-09-27 Thread THEvoid 
On Sat, 27 Sep 2014 03:38:30 -0600 (MDT)
 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.
 
 tough.

i wasn't whining, i was ASKING, and that was only an aside, not the main point
of my last message, which was an analysis of 'maketz.sh'.

this is only what got me looking at 'maketz.sh' and 'list2sh.awk'. my findings
there are relevant.

 I'm sorry, but this is the build process that makes snapshots.
 It serves that purpose and is designed for that.

did i ever say or suggest otherwise?

 It is not carveable in the way you want to use it.

obviously it is, even if 'unsupported'. i got the idea from a user on one of
the lists years ago, so it works for at least two people.

and that's still not relevant to what i said about 'maketz.sh'.

 It will not be changed.

i don't expect it to be changed for ME. my points about 'maketz.sh' are still
valid until someone show otherwise. THEY HAVE NOTHING TO DO WITH MY
'UNSUPPORTED' USE.

 You are on your own, really.

let me quote myself, the paragraph above what you quoted:
  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.

which by the way is irrelevant to the point i was making about 'maketz.sh'.
this 'unsupported use' is merely why i was poking around there.

and me again:
  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'.

and to clarify 'nobody here makes music for the fans', means, to quote you:
 You are on your own, really.

so we are in complete agreement here.


and this is all irrelevant. someone address what i said about 'maketz.sh'.
the fix i made ONLY eliminates 'maketz.sh', not its functionality, which
is only *2 lines* and can be put in 'list2sh.awk' instead.

the fact that it allows my 'blasphemous' behaviour was also irrelevant, i
didn't care about that. i can just add 'DESTDIR=/' to my automated scripts
to make this kernel, no biggie. i don't NEED a change to the system, and
never asked for one for myself, to quote myself again:
  and once more, i ONLY brought this up because of maketz.sh looks irrelevent.

now, did you read any of what i said about 'maketz.sh'? the proposed fix was to
eliminate it completely, placing its meager contents in 'list2sh.awk'.
i know you probably get dumb requests all the time, but maybe you shouldn't
jump to conclusions. i think i was pretty explicit, and if not, i would love
to know where i was ambiguous, to avoid it in the future.

back to 'maketz.sh':

simply, all 'maketz.sh' does is run:
cd $destdir/usr/share/zoneinfo
ls -1dF `tar cvf /dev/null [A-Za-y]*`

and this can be done in 'list2sh.awk' instead of said script calling 'maketz.sh'
was:
printf((cd ${TARGDIR}; sh $UTILS/maketz.sh $DESTDIR)\n);

i proposed:
printf((cd $DESTDIR/usr/share/zoneinfo  ls -1dF `tar cvf /dev/null 
[A-Za-y]*` ${TARGDIR}/var/tzlist)\n);

for a measly two lines of script. the error check is irrelevant if used
properly because $DESTDIR should always be set, thus the arg check is useless,
it should always be true (if used 'THE RIGHT WAY') and that leave 2 lines of
code. does 'maketz.sh' need to exist for two lines of code that can be put in
'list2sh.awk'?

once again, that this fixed *MY* problem is irrelevant. i don't want your help.
i don't want anyone's help. never did. to quote myself again on this point:
  and once more, i ONLY brought this up because of maketz.sh looks irrelevent.

i left $DESTDIR in the fix, since i now know it's relevant.

now here is what i said again, if there is a logical flaw in my argument, i
would love to hear it:

  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
  
  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'

Re: maketz.sh problems with distrib build

2014-09-27 Thread THEvoid 
i think this was sent to me personally by mistake (i had reply-to set). it
seems part of the conversation, and nothing seems confidential, so i am posting
my reply to tech@

especially as it is relevant to those who may want to know this later.

On Sat, 27 Sep 2014 05:13:42 -0600 (MDT)
 Your diff is wrong.  the script exists to avoid the long wrapping line.

ok, but also in 'list2sh.awk' is:

printf((cd ${TARGDIR}; tic -C -x -r -e %s 
${UTILS}/../../share/termtypes/termtypes.master | sed -e '/^#.*/d' -e '/^$$/d' 
 %s)\n,

wouldn't that have the same issue?

either way, this seems something worthy of a comment in 'maketz.sh'.

--- maketz.sh.orig  Wed May  6 23:43:02 2009
+++ maketz.sh   Sat Sep 27 08:26:14 2014
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+#this script exists to avoid the long wrapping line.
+
 destdir=$1
 
 if [ $# -lt 1 ]; then

maketz.sh problems with distrib build

2014-09-26 Thread THEvoid 
i encounter this error when building the (RAMDISK_CD) distrib kernel:
usage: maketz.sh DESTDIR

(in context:)
COPY${DESTDIR}/etc/firmware/run-rt3071  etc/firmware/run-rt3071
COPY${DESTDIR}/etc/firmware/zd1211  etc/firmware/zd1211
COPY${DESTDIR}/etc/firmware/zd1211b etc/firmware/zd1211b
TZ
usage: maketz.sh DESTDIR
rm /mnt/instbin
Filesystem  512-blocks  Used Avail Capacity iused   ifree  %iused  Mount
/dev/vnd0a3615  3164   45188% 173 33734%   /mnt
umount /mnt
vnconfig -u vnd0


the kernel builds, but when i boot from it, there is no 'var/tzlist'.

i trace the problem to 'distrib/miniroot/list2sh.awk', 'maketz.sh' is being
called with an empty variable

--- list2sh.awk.origFri Feb 21 14:33:31 2014
+++ list2sh.awk Fri Sep 26 22:48:12 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 ${TARGDIR}; sh $UTILS/maketz.sh ${TARGDIR})\n);
next;
 }
 $1 == COPYDIR {


then i rerun build, and instead get:
/usr/src/distrib/i386/ramdisk_cd/../../miniroot/maketz.sh[13]: cd: /mnt/usr/shar
e/zoneinfo - No such file or directory

it builds, and 'mr.fs' contains 'var/tzlist', but said file contains the
contents of the miniroot filesystem, and not the timezone list, since it runs
maketz.sh in /mnt, which does:
  ls -1dF `tar cvf /dev/null [A-Za-y]*`

there is no 'usr/share/zoneinfo' in the miniroot (and as far as i know never
has been), which is where 'maketz.sh' tries to get the list.

now i am possibly missing something, but 'distrib/miniroot/maketz.sh' makes no
sense in this respect:
  #!/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

now why is $destdir here? is it in any way useful? this could be reduced to:
  #!/bin/sh

  cd /usr/share/zoneinfo
  ls -1dF `tar cvf /dev/null [A-Za-y]*` var/tzlist


--- maketz.sh.orig  Wed May  6 23:43:02 2009
+++ maketz.sh   Fri Sep 26 23:33:49 2014
@@ -1,13 +1,4 @@
 #!/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
+cd /usr/share/zoneinfo
+ls -1dF `tar cvf /dev/null [A-Za-y]*` var/tzlist


of course there doesn't seem to be any need for 'maketz.sh' at all.
'list2sh.awk' could be changed thus:

--- list2sh.awk.origFri Feb 21 14:33:31 2014
+++ list2sh.awk Fri Sep 26 23:39:39 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 /usr/share/zoneinfo  ls -1dF `tar cvf /dev/null 
[A-Za-y]*` ${TARGDIR}/var/tzlist));
next;
 }
 $1 == COPYDIR {

i used this last 'list2sh.awk' patch that bypasses 'maketz.sh' completely, and
everything is as it should be.

that is, unless there was some need for $DESTDIR to be used in the original
'list2sh.awk', to be passed on to 'maketz.sh'. where is the tzlist SUPPOSED to
come from anyway?

i think i have seen this bug for years, but the release kernel has the proper
'var/tzlist'. how is it succeeding for them? does whoever is compiling releases
have $DESTDIR set? does $DESTDIR _need_ to be set (manually)?

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?