[source-changes] relayd.conf.5 (an hex - a hex)
From: Jason McIntyre j...@cvs.openbsd.org Date: Thu, 18 Dec 2014 14:26:09 -0700 (MST) To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org 2014/12/18 14:26:09 Modified files: usr.sbin/relayd: relayd.conf.5 Log message: an hex - a hex; as far as i am aware, 'an hex' is actually correct english. 'h' is a special case for a consonant. i am not quite sure why, perhaps some more ancient pronunciation of 'a', but it is commonly used eg 'an historial event'. it is a somewhat more obscure nuance in the language, so i am actually slightly surprised someone got it right the first time.
Re: [source-changes] relayd.conf.5 (an hex - a hex)
On Mon, 22 Dec 2014 08:53:04 + Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Dec 22, 2014 at 03:29:13AM -0500, thev...@openmailbox.org wrote: From: Jason McIntyre j...@cvs.openbsd.org Date: Thu, 18 Dec 2014 14:26:09 -0700 (MST) To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org 2014/12/18 14:26:09 Modified files: usr.sbin/relayd: relayd.conf.5 Log message: an hex - a hex; as far as i am aware, 'an hex' is actually correct english. 'h' is a special case for a consonant. i am not quite sure why, perhaps some more ancient pronunciation of 'a', but it is commonly used eg 'an historial event'. it is a somewhat more obscure nuance in the language, so i am actually slightly surprised someone got it right the first time. it is correct only if you want to sound like a pillock. modern english does not routinely use an before words beginning h. it depends on the sound. you could have an h-bomb, but not an house. an historical event...well some folks would insist that reads better. of course, you *can* do it for comic effect, but it's best not to just drop an because the noun starts with an h. some folks do drop their aitches, so they might say an ex. that would be ok, but confusing. i'm sure if you scout online you'll find some better details (as well as some conflicting ones ;) jmc seems like this particular case may be in a grey area. a quick check of wikipedia (English_articles): Some speakers and writers use an before a word beginning with the sound /h/ in an unstressed syllable: an historical novel, an hotel.^[12] However, where the h is clearly pronounced, this usage is now less common, and a is preferred. ^[11] 11. ^ ^a ^b How to Use Articles (a/an/the) ? The OWL at Purdue 12. ^ Peters, Pam (2004). a or an. The Cambridge Guide to English Usage. Cambridge, England: Cambridge University Press. p. 1. ISBN 0-521-62181-X. so there is a conflict right there. by and large though i tend to give more credit to something from Cambridge University Press. 'an hex' sounds to me (literally) like it fits the words where this is more common, but it's hard to say, since it is based on how the individual word is pronounced, and so is relative to the accent, and thus there may not be a correct usage for some words across all english accents... it may also depend on how one pronounces 'a' too. 'an hex' sounds better than 'uh hex' (a common pronunciation of 'a'), but long 'a' sounds better than 'an'. so upon some reflection, i don't think there is a correct answer for this case. however, even if it is 'less common', it may be still be appropriate for the written word/documentation. whoever wrote that man page originally perhaps thought so. either way. natural languages aren't really mathematical.
Re: [source-changes] relayd.conf.5 (an hex - a hex)
On Mon, 22 Dec 2014 05:16:21 -0500 STeve Andre' and...@msu.edu wrote: On 12/22/14 05:02, thev...@openmailbox.org wrote: On Mon, 22 Dec 2014 08:53:04 + Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Dec 22, 2014 at 03:29:13AM -0500, thev...@openmailbox.org wrote: From: Jason McIntyre j...@cvs.openbsd.org Date: Thu, 18 Dec 2014 14:26:09 -0700 (MST) To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org 2014/12/18 14:26:09 Modified files: usr.sbin/relayd: relayd.conf.5 Log message: an hex - a hex; as far as i am aware, 'an hex' is actually correct english. 'h' is a special case for a consonant. i am not quite sure why, perhaps some more ancient pronunciation of 'a', but it is commonly used eg 'an historial event'. it is a somewhat more obscure nuance in the language, so i am actually slightly surprised someone got it right the first time. it is correct only if you want to sound like a pillock. modern english does not routinely use an before words beginning h. it depends on the sound. you could have an h-bomb, but not an house. an historical event...well some folks would insist that reads better. of course, you *can* do it for comic effect, but it's best not to just drop an because the noun starts with an h. some folks do drop their aitches, so they might say an ex. that would be ok, but confusing. i'm sure if you scout online you'll find some better details (as well as some conflicting ones ;) jmc seems like this particular case may be in a grey area. a quick check of wikipedia (English_articles): Some speakers and writers use an before a word beginning with the sound /h/ in an unstressed syllable: an historical novel, an hotel.^[12] However, where the h is clearly pronounced, this usage is now less common, and a is preferred. ^[11] 11. ^ ^a ^b How to Use Articles (a/an/the) ? The OWL at Purdue 12. ^ Peters, Pam (2004). a or an. The Cambridge Guide to English Usage. Cambridge, England: Cambridge University Press. p. 1. ISBN 0-521-62181-X. so there is a conflict right there. by and large though i tend to give more credit to something from Cambridge University Press. 'an hex' sounds to me (literally) like it fits the words where this is more common, but it's hard to say, since it is based on how the individual word is pronounced, and so is relative to the accent, and thus there may not be a correct usage for some words across all english accents... it may also depend on how one pronounces 'a' too. 'an hex' sounds better than 'uh hex' (a common pronunciation of 'a'), but long 'a' sounds better than 'an'. so upon some reflection, i don't think there is a correct answer for this case. however, even if it is 'less common', it may be still be appropriate for the written word/documentation. whoever wrote that man page originally perhaps thought so. either way. natural languages aren't really mathematical. This isn't grey. A hex something, not an hex. None of my teachers who stressed good writing would have let that pass. --STeve Andre' do you have a bit more than than? from what i cited above The Cambridge Guide to English Usage. says that 'an historical novel, an hotel' are valid, both of which are things. i found the Oxford Guide to the English Grammar which says that using 'a' or 'an' depends on how the 'h' is pronounced (or not), but also says that using 'an' is 'formal and old-fashioned' citing 'hotel' as an example. i found this paper here, which is very pertinent: http://www.harbeck.ca/James/harbeck_historic_r.pdf it's specifically about the 'an historic' vs 'a historic', but delves into historical and contemporary uses of 'a/an' with 'h', and criticisms. the issue is not so clear-cut, and apparently never has been. the trend seems to be towards 'a' rather than 'an', but it is not an absolute.
Re: [source-changes] relayd.conf.5 (an hex - a hex)
doing some grep, under /usr/share/man there are 99 'a hex' and only 2 'an hex'. $ grep -i 'an hex' man*/* man3p/Math::BigRat.3p:Create a BigRat from an hexadecimal, binary or octal number man3p/OpenBSD::md5.3p:\print $md5\-stringize # provides an hex representation i have a number of packages installed on an experimental machine, with 116 'a' and only one (devel/srecord) uses 'an'. at the very least 'a hex' is consistent with how things are, and utility should outweigh formality, especially as it seems to be mostly academic. some people may pronounce it in such a way as 'an' is preferred, but the north american pronunciations should probably have the greater weight by sheer numbers.
Re: [nitpicking] abort in arc4random?
The comment says, AS A WHOLE: /* * Entropy collection via /dev/urandom and sysctl have failed. * * No other API exists for collecting entropy. See the large * comment block above. * * We have very few options: * - Even syslog_r is unsafe to call at this low level, so * there is no way to alert the user or program. * - Cannot call abort() because some systems have unsafe * corefiles. * - Could raise(SIGKILL) resulting in silent program termination. * - Return EIO, to hint that arc4random's stir function * should raise(SIGKILL) * - Do the best under the circumstances * * This code path exists to bring light to the issue that Linux * does not provide a failsafe API for entropy collection. * * We hope this demonstrates that Linux should either retain their * sysctl ABI, or consider providing a new failsafe API which * works in a chroot or when file descriptors are exhausted. */ It is a list of reasons for why this API is designed like this. You are nitpicking about a comment which does not stand alone. there is a minor typo in this comment: s/sysctl ABI/sysctl API/
future direction of /var/tmp
On Wed, 26 Nov 2014 08:52:30 -0700 (MST) Antoine Jacoutot ajacou...@cvs.openbsd.org wrote: CVSROOT: /cvs Module name: src Changes by: ajacou...@cvs.openbsd.org 2014/11/26 08:52:30 Modified files: usr.sbin/sysmerge: sysmerge.8 sysmerge.sh Log message: Drop sysmerge.log ; it used to be handy for batch mode but now the console output is clear and clean in that mode. Since /var/tmp is now a symlink to /tmp: - directly use /tmp - if modifications were done; at the end of the run: - display our backup directory (in case we want to move it to survive a reboot) - display where and what files are still left for comparison discussed with and ok sthen@ what are the future plans with regards to /var/tmp? obviously it will be around for a while, but is there a general intention to change it to /tmp as implied above? this is timely for me, because i just thought about this when doing ports, where PKG_TMPDIR=/var/tmp, and was about to ask: are (some) diffs welcome for this?
xenocara make release clobbers SHA256
i don't know if this is expected behaviour or not, but doing a 'make release'
for xenocara using the same directory as for base overwrites SHA256. the line
in /usr/xenocara/Makefile is:
cksum -a sha256 x*tgz SHA256
looking back its been there for a while, one change in on 10Jan:
- sum -a sha256 x*tgz SHA256
+ cksum -a sha256 x*tgz SHA256
in the faq it says:
The RELEASEDIR can be the same directory as the main system RELEASEDIR, ...
is there something i am missing? otherwise,
--- Makefile.orig Tue Sep 30 22:02:11 2014
+++ MakefileTue Nov 4 22:10:43 2014
@@ -82,7 +82,7 @@ sha: release-clean release-install dist hash
hash: dist
-cd ${RELEASEDIR}; \
- cksum -a sha256 x*tgz SHA256
+ cksum -a sha256 x*tgz SHA256
.ORDER: release-clean release-install dist hash
.endif
Re: make release fails if SUDO is set in mk.conf
On Fri, 24 Oct 2014 08:35:40 +0200 Landry Breuil lan...@rhaalovely.net wrote: On Fri, Oct 24, 2014 at 02:34:54AM -0400, thev...@openmailbox.org wrote: with SUDO set in /etc/mk.conf: if make release is run as root it will not proceed. if run as a regular user it gets further, but fails on permissions. without SUDO in /etc/mk.conf (and i presume the environment) it works fine. is there any way around this allowing /etc/mk.conf (which is useful for ports)? i can always move it temporarily, add it to my automated scripts, but is there a better way? $ cat /etc/mk.conf SUDO=/usr/bin/sudo I think (and this is probably somewhere in the docs) you should use sudo -E. without it (and if you're not in wsrc) DESTDIR and RELEASEDIR are removed. check the default sudoers, and sudo manpage for details. Landry. if you are talking about this: $ sudo env DESTDIR=/usr/dst RELEASEDIR=/usr/release make release exec /usr/bin/sudo make distribution-etc-root-var setenv DESTDIR before doing that! *** Error 1 in /usr/src/etc (Makefile:77 'distribution-etc-root-var': @false) *** Error 1 in /usr/src/etc (Makefile:228 'distribution') that is the reason for this error, since root is not in group wsrc, and sudo is getting invoked twice, once by me and then again by make. that command does work without SUDO being set (by mk.conf or otherwise). i was trying to use sudo to invoke each command for logging, which is non-standard. however, what is recommended in release(8) and the faq is: # cd /usr/src/etc make release i was incomplete before, as this also fails: # cat /etc/mk.conf SUDO=/usr/bin/sudo # cd /usr/src/etc/ make release setenv DESTDIR before doing that! *** Error 1 in /usr/src/etc (Makefile:77 'release': @false) so this results from following the documentation, including the recommendations in ports(7) that SUDO can be set in /etc/mk.conf.
Re: make release fails if SUDO is set in mk.conf
On Fri, 24 Oct 2014 07:53:09 +0200 Alexander Hall alexan...@beard.se wrote: Maybe $ make SUDO= release works? indeed this works, thanks! $ sudo env DESTDIR=/usr/dst RELEASEDIR=/usr/release make SUDO= release That enforces the value of SUDO, but I've never tried it for an empty value. Or try $ make SUDO=' ' release /Alexander On October 24, 2014 8:34:54 AM CEST, thev...@openmailbox.org wrote: with SUDO set in /etc/mk.conf: if make release is run as root it will not proceed. if run as a regular user it gets further, but fails on permissions. without SUDO in /etc/mk.conf (and i presume the environment) it works fine. is there any way around this allowing /etc/mk.conf (which is useful for ports)? i can always move it temporarily, add it to my automated scripts, but is there a better way? $ cat /etc/mk.conf SUDO=/usr/bin/sudo $ sudo env DESTDIR=/usr/dst RELEASEDIR=/usr/release make release exec /usr/bin/sudo make distribution-etc-root-var setenv DESTDIR before doing that! *** Error 1 in /usr/src/etc (Makefile:77 'distribution-etc-root-var': @false) *** Error 1 in /usr/src/etc (Makefile:228 'distribution') $ env DESTDIR=/usr/dst RELEASEDIR=/usr/release make release
Re: make release fails if SUDO is set in mk.conf
On Fri, 24 Oct 2014 10:29:17 +0200 Landry Breuil lan...@rhaalovely.net wrote: On Fri, Oct 24, 2014 at 05:09:36AM -0400, thev...@openmailbox.org wrote: On Fri, 24 Oct 2014 08:35:40 +0200 Landry Breuil lan...@rhaalovely.net wrote: On Fri, Oct 24, 2014 at 02:34:54AM -0400, thev...@openmailbox.org wrote: with SUDO set in /etc/mk.conf: if make release is run as root it will not proceed. if run as a regular user it gets further, but fails on permissions. without SUDO in /etc/mk.conf (and i presume the environment) it works fine. is there any way around this allowing /etc/mk.conf (which is useful for ports)? i can always move it temporarily, add it to my automated scripts, but is there a better way? $ cat /etc/mk.conf SUDO=/usr/bin/sudo I think (and this is probably somewhere in the docs) you should use sudo -E. without it (and if you're not in wsrc) DESTDIR and RELEASEDIR are removed. check the default sudoers, and sudo manpage for details. Landry. if you are talking about this: $ sudo env DESTDIR=/usr/dst RELEASEDIR=/usr/release make release exec /usr/bin/sudo make distribution-etc-root-var setenv DESTDIR before doing that! *** Error 1 in /usr/src/etc (Makefile:77 'distribution-etc-root-var': @false) *** Error 1 in /usr/src/etc (Makefile:228 'distribution') that is the reason for this error, since root is not in group wsrc, and sudo is getting invoked twice, once by me and then again by make. You're mixing stuff here. IF the user doing sudo is in wsrc, DESTDIR and RELEASEDIR should be passed through to the underlying process. and you shouldnt need two sudo invocations. export DESTDIR=/usr/dst export RELEASEDIR=/usr/release $make release (as user iirc, if you're in wsrc and use the default sudoers that's supposed to work. (btw, i never build releases, so i might be wrong) Landry well, the first invocation is being done by me, and i am in wsrc, so they do get passed on to make. however, that make is being run as root, who is not in wsrc, and SUDO is being invoked again, presumably without those variables. i could be wrong too, though.
make release fails if SUDO is set in mk.conf
with SUDO set in /etc/mk.conf: if make release is run as root it will not proceed. if run as a regular user it gets further, but fails on permissions. without SUDO in /etc/mk.conf (and i presume the environment) it works fine. is there any way around this allowing /etc/mk.conf (which is useful for ports)? i can always move it temporarily, add it to my automated scripts, but is there a better way? $ cat /etc/mk.conf SUDO=/usr/bin/sudo $ sudo env DESTDIR=/usr/dst RELEASEDIR=/usr/release make release exec /usr/bin/sudo make distribution-etc-root-var setenv DESTDIR before doing that! *** Error 1 in /usr/src/etc (Makefile:77 'distribution-etc-root-var': @false) *** Error 1 in /usr/src/etc (Makefile:228 'distribution') $ env DESTDIR=/usr/dst RELEASEDIR=/usr/release make release exec /usr/bin/sudo make distribution-etc-root-var if [ ! -d /usr/dst/. ]; then install -d -o root -g wheel -m 755 /usr/dst; fi mtree -qdef mtree/4.4BSD.dist -p /usr/dst/ -U if [ ! -d /usr/dst/usr/src ]; then install -d -o root -g wsrc -m 775 /usr/dst/usr/src; fi cd /usr/dst/; ln -fhs usr/src/sys sys install -c -o root -g wheel -m 644 changelist csh.cshrc csh.login csh.logout daily etc.i386/disktab etc.i386/login.conf ftpusers gettytab group ksh.kshrc locate.rc mailer.conf man.conf moduli monthly netstart networks newsyslog.conf pf.os protocols rc rc.conf rpc services shells syslog.conf weekly /usr/dst/etc sh ttys.pty | cat etc.i386/ttys - /usr/dst/etc/ttys chown root /usr/dst/etc/ttys chgrp wheel /usr/dst/etc/ttys chmod 644 /usr/dst/etc/ttys cat examples/sysctl.conf etc.i386/sysctl.conf /usr/dst/etc/examples/sysctl.conf chown root /usr/dst/etc/examples/sysctl.conf chgrp wheel /usr/dst/etc/examples/sysctl.conf chmod 644 /usr/dst/etc/examples/sysctl.conf cat fbtab.head etc.i386/fbtab fbtab.tail /usr/dst/etc/fbtab chown root /usr/dst/etc/fbtab chgrp wheel /usr/dst/etc/fbtab chmod 644 /usr/dst/etc/fbtab install -c -o root -g operator -m 664 motd /usr/dst/etc install -c -o root -g crontab -m 600 crontab /usr/dst/var/cron/tabs/root ... === sys/arch/zaurus/stand/zboot install -c -o root -g bin -m 444 /usr/src/sys/arch/zaurus/stand/zboot/boot.8 /usr/dst/usr/share/man/man8/zaurus/boot.8 /usr/dst/usr/share/man/man5/zaurus/boot.conf.5 - /usr/dst/usr/share/man/man8/zaurus/boot.8 cd /usr/src/share/man exec make makedb /usr/sbin/makewhatis -Qv /usr/dst/usr/share/man cd /usr/src/distrib/sets exec make makedb /bin/sh /usr/src/distrib/sets/makelocatedb 56 /usr/dst/usr/lib/locate/src.db cp /usr/dst/usr/mdec/pxeboot /usr/release cp: /usr/release/pxeboot: Permission denied *** Error 1 in /usr/src/etc (etc.i386/Makefile.inc:6 'bootblocks')
have softraid crypto call crypto_dispatch appropriately instead of
i had a test install i could sacrifice, so i gave it a shot. this install had
-current base installed. i booted the patched kernel, and installed comp56.tgz.
everything seemed to work fine. rebooted into my non-test install, mounted the
test crypto partition, and sha1'd every hundredth file and compared against
originals, nothing seems amiss. is that a sufficient test?
On Mon, 20 Oct 2014 11:28:34 +1000 David Gwynne da...@gwynne.id.au wrote:
the distinct impression i get is crypto_invoke is an internal
abstraction to src/sys/crypto/crypto.c. it isnt documented in
crypto(9), and is only used outside crypto by softraid. softraid
should be calling crypto_dispatch with CRYPTO_F_NOQUEUE set if it
wants/needs those semantics.
can a softraid crypto user test this for me?
Index: softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.112
diff -u -p -r1.112 softraid_crypto.c
--- softraid_crypto.c 14 Sep 2014 14:17:24 - 1.112
+++ softraid_crypto.c 20 Oct 2014 01:25:12 -
@@ -1118,7 +1118,8 @@ sr_crypto_rw(struct sr_workunit *wu)
if (wu-swu_xs-flags SCSI_DATA_OUT) {
crwu = sr_crypto_prepare(wu, 1);
crwu-cr_crp-crp_callback = sr_crypto_write;
- rv = crypto_invoke(crwu-cr_crp);
+ crwu-cr_crp-crp_flags = CRYPTO_F_NOQUEUE;
+ rv = crypto_dispatch(crwu-cr_crp);
if (rv == 0)
rv = crwu-cr_crp-crp_etype;
} else
@@ -1195,9 +1196,10 @@ sr_crypto_done(struct sr_workunit *wu)
if (ISSET(xs-flags, SCSI_DATA_IN) xs-error == XS_NOERROR) {
crwu = sr_crypto_prepare(wu, 0);
crwu-cr_crp-crp_callback = sr_crypto_read;
- DNPRINTF(SR_D_INTR, %s: sr_crypto_done: crypto_invoke %p\n,
+ crwu-cr_crp-crp_flags = CRYPTO_F_NOQUEUE;
+ DNPRINTF(SR_D_INTR, %s: sr_crypto_done: crypto_dispatch %p\n,
DEVNAME(wu-swu_dis-sd_sc), crwu-cr_crp);
- crypto_invoke(crwu-cr_crp);
+ crypto_dispatch(crwu-cr_crp);
return;
}
let crypto.c pools protect themselves
tested this with your other patch. i applied both patches to the kernel at the
same time, so test results the same as with the other patch (good for softraid
at least).
On Mon, 20 Oct 2014 10:49:35 +1000 David Gwynne da...@gwynne.id.au wrote:
pools lock themselves, we just gotta tell them how hard.
can someone test this with ipsec or softraid crypto? or ok it?
Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.68
diff -u -p -r1.68 crypto.c
--- crypto.c 20 Oct 2014 00:40:33 - 1.68
+++ crypto.c 20 Oct 2014 00:46:44 -
@@ -453,20 +453,16 @@ void
crypto_freereq(struct cryptop *crp)
{
struct cryptodesc *crd;
- int s;
if (crp == NULL)
return;
- s = splvm();
-
while ((crd = crp-crp_desc) != NULL) {
crp-crp_desc = crd-crd_next;
pool_put(cryptodesc_pool, crd);
}
pool_put(cryptop_pool, crp);
- splx(s);
}
/*
@@ -477,20 +473,14 @@ crypto_getreq(int num)
{
struct cryptodesc *crd;
struct cryptop *crp;
- int s;
- s = splvm();
-
crp = pool_get(cryptop_pool, PR_NOWAIT | PR_ZERO);
- if (crp == NULL) {
- splx(s);
+ if (crp == NULL)
return NULL;
- }
while (num--) {
crd = pool_get(cryptodesc_pool, PR_NOWAIT | PR_ZERO);
if (crd == NULL) {
- splx(s);
crypto_freereq(crp);
return NULL;
}
@@ -499,7 +489,6 @@ crypto_getreq(int num)
crp-crp_desc = crd;
}
- splx(s);
return crp;
}
@@ -510,8 +499,10 @@ crypto_init(void)
pool_init(cryptop_pool, sizeof(struct cryptop), 0, 0,
0, cryptop, NULL);
+ pool_setipl(cryptop_pool, IPL_VM);
pool_init(cryptodesc_pool, sizeof(struct cryptodesc), 0, 0,
0, cryptodesc, NULL);
+ pool_setipl(cryptodesc_pool, IPL_VM);
}
/*
Re: maketz.sh problems with distrib build
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
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
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
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
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?
