Re: awk behaviour?
Am 29.07.21 um 18:42 schrieb Michael Butler via freebsd-current:
> On 7/29/21 6:09 AM, Michael Gmelin wrote:
>>
>>
>> On Wed, 28 Jul 2021 16:02:30 -0400
>> Ed Maste wrote:
>>
>>> On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
>>> wrote:
What prompted the question was my (obviously poor) attempt to debug
and resolve this failure when attempting to build a release for
i386 on an amd64 ..
>>>
>>> This will be due to my 4e224e4be7c3. I'm not sure exactly what's
>>> happening yet, but I can provoke this behaviour if `${PKG_CMD}
>>> --version` outputs something other than a single line with the version
>>> number.
>>>
>>
>> Could it be, that the pkg binary isn't installed in $LOCALBASE/sbin/pkg,
>> (whatever LOCALBASE is at that point)? This would make pkg --version
>> shows its bootstrap message:
>>
>> The package management tool is not yet installed on your system.
>> Do you want to fetch and install it now? [y/N]:
>>
>> which could explain the behavior.
>>
>> Just speculating...
>
> This is consistent with the behaviour I'm now seeing after the most recent
> patch.
>
> In the chroot environment used by a cross-compilation, there is no installed
> pkg port. When pkg is invoked in the target environment, it now waits on the
> yes/no response,
Passing "ASSUME_ALWAYS_YES=yes" in the environment should cause the
installation to proceed without a wait for user input.
Regards, STefan
OpenPGP_signature
Description: OpenPGP digital signature
Re: awk behaviour?
On 7/29/21 6:09 AM, Michael Gmelin wrote:
On Wed, 28 Jul 2021 16:02:30 -0400
Ed Maste wrote:
On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
wrote:
What prompted the question was my (obviously poor) attempt to debug
and resolve this failure when attempting to build a release for
i386 on an amd64 ..
This will be due to my 4e224e4be7c3. I'm not sure exactly what's
happening yet, but I can provoke this behaviour if `${PKG_CMD}
--version` outputs something other than a single line with the version
number.
Could it be, that the pkg binary isn't installed in $LOCALBASE/sbin/pkg,
(whatever LOCALBASE is at that point)? This would make pkg --version
shows its bootstrap message:
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]:
which could explain the behavior.
Just speculating...
This is consistent with the behaviour I'm now seeing after the most
recent patch.
In the chroot environment used by a cross-compilation, there is no
installed pkg port. When pkg is invoked in the target environment, it
now waits on the yes/no response,
imb
Re: awk behaviour?
On Wed, 28 Jul 2021 16:02:30 -0400
Ed Maste wrote:
> On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
> wrote:
> >
> > What prompted the question was my (obviously poor) attempt to debug
> > and resolve this failure when attempting to build a release for
> > i386 on an amd64 ..
>
> This will be due to my 4e224e4be7c3. I'm not sure exactly what's
> happening yet, but I can provoke this behaviour if `${PKG_CMD}
> --version` outputs something other than a single line with the version
> number.
>
Could it be, that the pkg binary isn't installed in $LOCALBASE/sbin/pkg,
(whatever LOCALBASE is at that point)? This would make pkg --version
shows its bootstrap message:
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]:
which could explain the behavior.
Just speculating...
-m
--
Michael Gmelin
Re: awk behaviour?
On Wed, 28 Jul 2021 at 15:15, Michael Butler via freebsd-current
wrote:
>
> What prompted the question was my (obviously poor) attempt to debug and
> resolve this failure when attempting to build a release for i386 on an
> amd64 ..
This will be due to my 4e224e4be7c3. I'm not sure exactly what's
happening yet, but I can provoke this behaviour if `${PKG_CMD}
--version` outputs something other than a single line with the version
number.
Can you give this change a try:
diff --git a/Makefile.inc1 b/Makefile.inc1
index 23fb4b5581ac..9ef954e0678c 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1860,7 +1860,7 @@ _pkgbootstrap: .PHONY
.if make(create-world-packages-jobs) || make(create-kernel-packages*)
|| make(real-update-packages) || make(sign-packages)
PKG_ABI!=${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/usr/bin/uname config ABI
.endif
-PKG_BIN_VERSION!=${PKG_CMD} --version | awk -F. '{print $$1 * 1 +
$$2 * 100 + $$3}'
+PKG_BIN_VERSION!=${PKG_CMD} --version | awk -F. '/^[0-9.]+$$/ {print
$$1 * 1 + $$2 * 100 + $$3}'
.if ${PKG_BIN_VERSION} < 11700
PKG_EXT= ${PKG_FORMAT}
.else
Re: awk behaviour?
On Wed, Jul 28, 2021 at 1:12 PM Michael Butler
wrote:
> On 7/28/21 1:36 PM, Warner Losh wrote:
> > On Wed, Jul 28, 2021 at 11:31 AM Michael Butler via freebsd-current <
> > freebsd-current@freebsd.org> wrote:
> >
> >> I tripped over this while trying to build a local release ..
> >>
> >> imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2
> *
> >> 100 + $$3}'
> >> 10001
> >>
> >> imb@toshi:/home/imb> pkg --version
> >> 1.17.1
> >>
> >> Is this expected?
> >>
> >
> > Why $$ instead of $? $ isn't expanded in '' expressions, so doubling
> isn't
> > necessary
> > unlike in make... With single quotes it works for me:
> >
> > % pkg --version | awk -F. '{print $1 * 1 + $2 * 100 + $3}'
> > 11603
> > % pkg --version
> > 1.16.3
> >
> > In awk $$n is $($n), so $$ in this context would evaluate $1 to 1 and
> then
> > $1 to be 1. And then $2 to be 16
> > and then $17 to be 0 and then $3 to be 1 and then $1 to be 1 which leads
> to
> > 10001.
>
> What prompted the question was my (obviously poor) attempt to debug and
> resolve this failure when attempting to build a release for i386 on an
> amd64 ..
>
> make -C /usr/src/release obj
> make -C /usr/src/release ftp cdrom memstick.img mini-memstick.img
> mkdir -p dist
> cd /usr/src/release/.. && make TARGET_ARCH=i386 TARGET=i386
> distributeworld DISTDIR=/usr/obj/usr/src/i386.i386/release/dist
> make[3]: "/usr/obj/usr/src/i386.i386/toolchain-metadata.mk" line 1:
> Using cached toolchain metadata from build at
> vm01.auburn.protected-networks.net on Wed Jul 28 18:01:01 UTC 2021
>
> make[3]: "/usr/src/Makefile.inc1" line 1864: String comparison operator
> must be either == or !=
> make[3]: "/usr/src/Makefile.inc1" line 2073: String comparison operator
> must be either == or !=
> make[3]: Fatal errors encountered -- cannot continue
> make[3]: stopped in /usr/src
> *** Error code 1
>
I've cc'd emaste to see if this is related to his recent changes.
Warner
Re: awk behaviour?
On 7/28/21 1:36 PM, Warner Losh wrote:
On Wed, Jul 28, 2021 at 11:31 AM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:
I tripped over this while trying to build a local release ..
imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
100 + $$3}'
10001
imb@toshi:/home/imb> pkg --version
1.17.1
Is this expected?
Why $$ instead of $? $ isn't expanded in '' expressions, so doubling isn't
necessary
unlike in make... With single quotes it works for me:
% pkg --version | awk -F. '{print $1 * 1 + $2 * 100 + $3}'
11603
% pkg --version
1.16.3
In awk $$n is $($n), so $$ in this context would evaluate $1 to 1 and then
$1 to be 1. And then $2 to be 16
and then $17 to be 0 and then $3 to be 1 and then $1 to be 1 which leads to
10001.
What prompted the question was my (obviously poor) attempt to debug and
resolve this failure when attempting to build a release for i386 on an
amd64 ..
make -C /usr/src/release obj
make -C /usr/src/release ftp cdrom memstick.img mini-memstick.img
mkdir -p dist
cd /usr/src/release/.. && make TARGET_ARCH=i386 TARGET=i386
distributeworld DISTDIR=/usr/obj/usr/src/i386.i386/release/dist
make[3]: "/usr/obj/usr/src/i386.i386/toolchain-metadata.mk" line 1:
Using cached toolchain metadata from build at
vm01.auburn.protected-networks.net on Wed Jul 28 18:01:01 UTC 2021
make[3]: "/usr/src/Makefile.inc1" line 1864: String comparison operator
must be either == or !=
make[3]: "/usr/src/Makefile.inc1" line 2073: String comparison operator
must be either == or !=
make[3]: Fatal errors encountered -- cannot continue
make[3]: stopped in /usr/src
*** Error code 1
Stop.
imb
Re: awk behaviour?
On Wed, 28 Jul 2021 13:29:20 -0400
Michael Butler via freebsd-current wrote:
> I tripped over this while trying to build a local release ..
>
> imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 +
> $$2 * 100 + $$3}'
> 10001
>
> imb@toshi:/home/imb> pkg --version
> 1.17.1
>
> Is this expected?
Yes, as you're using $$ instead of $.
With single dollar sign you'll get the expected value of:
11701
With double dollar you reference the content of the field, so in case
of 1.17.1:
$$1 * 1 + $$2 * 100 + $$3
is equal to
$1 * 1 + $17 + $1
Which is:
1 + 0 + 1
Which equals
10001
-m
>
> imb
--
Michael Gmelin
Re: awk behaviour?
On Wed, Jul 28, 2021 at 11:31 AM Michael Butler via freebsd-current <
freebsd-current@freebsd.org> wrote:
> I tripped over this while trying to build a local release ..
>
> imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
> 100 + $$3}'
> 10001
>
> imb@toshi:/home/imb> pkg --version
> 1.17.1
>
> Is this expected?
>
Why $$ instead of $? $ isn't expanded in '' expressions, so doubling isn't
necessary
unlike in make... With single quotes it works for me:
% pkg --version | awk -F. '{print $1 * 1 + $2 * 100 + $3}'
11603
% pkg --version
1.16.3
In awk $$n is $($n), so $$ in this context would evaluate $1 to 1 and then
$1 to be 1. And then $2 to be 16
and then $17 to be 0 and then $3 to be 1 and then $1 to be 1 which leads to
10001.
Warner
Re: awk behaviour?
NVM .. it's the escaping of '$' ..
On 7/28/21 1:29 PM, Michael Butler via freebsd-current wrote:
I tripped over this while trying to build a local release ..
imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
100 + $$3}'
10001
imb@toshi:/home/imb> pkg --version
1.17.1
Is this expected?
imb
awk behaviour?
I tripped over this while trying to build a local release ..
imb@toshi:/home/imb> pkg --version | awk -F. '{print $$1 * 1 + $$2 *
100 + $$3}'
10001
imb@toshi:/home/imb> pkg --version
1.17.1
Is this expected?
imb
