After missing the 2000 days milestone:
Last login: Tue Jun 9 13:16:53 from kenny.gaertner.de
ULTRIX V4.4 (Rev. 69) System #17: Tue May 28 10:12:31 MET DST 1996
~~~
---
You have mail.
neitzel 1 > date
Tue Jun 9 13:18:47 MET DST 2020
neitzel 2 > uptime
1:18pm up 2222 days, 22:22, 8 users, load average: 0.21, 0.05, 0.00
neitzel 3 >
A good bug report goes a long way... Matthew Sporleder fixed the netbsd-8.x repositories within just a few hours. Thanks!
With the recent upgrade of
hackett
on the netbsd-8 stable track to "8.2-and-a-bit-later" I also switch the
pkgin(1)
repository from the 8.1 subdirectory to the 8.2 one. This was on May, 2nd.
For the first nine days after,
pkgin update
wouldn't find any new catalogue but eventually, on May 11th, there was one.
pkgin upgrade
then greeted me with something similar to this:
log 167 # pkgin upgrade
calculating dependencies...done.
30 packages to refresh:
p5-Socket6-0.29nb1 p5-IO-Socket-INET6-2.72nb5 dehydrated-0.6.5
p5-IO-CaptureOutput-1.1105 p5-Email-Valid-1.202nb3 Markdown-1.0.1nb7
p5-Net-Domain-TLD-1.75nb3 p5-Net-SMTP-SSL-1.04nb3 automake-1.16.1nb1
p5-TimeDate-2.30nb6 p5-Authen-SASL-2.16nb7 p5-Net-IP-1.26nb7
p5-GSSAPI-0.28nb10 p5-Mozilla-CA-20180117nb2 p5-Net-LibIDN-0.12nb11
p5-Digest-HMAC-1.03nb9 m4-1.4.18nb2 autoconf-2.69nb9 ytalk-3.3.0nb1
tig-1.2.1nb3 tcsh-6.22.02 rlwrap-0.43nb3 pcre2-10.34 lzo-2.10 lz4-1.9.2
libxml2-2.9.10nb1 libuuid-2.32.1 libunistring-0.9.10 iperf-2.0.5nb1
gmake-4.2.1nb1
19 packages to upgrade:
scrollz-2.2.3nb8 screen-4.8.0nb1 python37-3.7.7 perl-5.30.2 p5-Net-SSLeay-1.88
p5-Net-DNS-1.23 p5-MailTools-2.21 p5-IO-Socket-SSL-2.067 p5-Error-0.17029
openvpn-2.4.8nb2 nghttp2-1.40.0nb2 libidn-1.35 libffi-3.3nb2 iperf3-3.7nb1
git-docs-2.25.4 git-base-2.25.4 fossil-2.10nb2 curl-7.69.1 bash-5.0.16nb1
1 package to install:
heimdal-1.5.3nb24
30 to refresh, 19 to upgrade, 1 to install
14M to download, 15M to install
proceed ? [Y/n]
I welcome the
19 packages to upgrade
-- that's why I run the command.
I was very suprised by the
refresh
list, though. Why do need pkgs to get refreshed even when the pkg is already on board, with the exact same version? Different dependencies? Loss of local cache files? Whatever the reason may be, I was particularly surprised of the
ytalk
pkg appearing in this list. I had installed that package just five days earlier. And yes, at exactly
ytalk-3.3.0nb1
already.
Be that as it may, the real problem showed up when proceeding with this upgrade:
proceed ? [Y/n] y
p5-Authen-SASL-2.16nb7.tgz 100% 24KB 24.3KB/s 00:00
download error: p5-Authen-SASL-2.16nb7 size does not match pkg_summary
This error message is not new to me. I have seen it before (last summer) and suspect some inconsistencies within the Fastly CDN hosting the NetBSD repositories.
The relevant commands to debug this:
pkgin 75 > pwd
/var/db/pkgin
pkgin 76 > sqlite3 pkgin.db
SQLite version 3.17.0 2017-02-13 16:02:40
Enter ".help" for usage hints.
sqlite> .mode line
sqlite> select * from remote_pkg where pkgname like 'p5-Authen-SASL' ;
PKG_ID = 6173
FULLPKGNAME = p5-Authen-SASL-2.16nb7
PKGNAME = p5-Authen-SASL
PKGVERS = 2.16nb7
BUILD_DATE = 2020-04-01 03:57:23 +0000
COMMENT = Perl module to handle SASL authentication
LICENSE = gnu-gpl-v2 OR artistic
PKGTOOLS_VERSION = 20091115
HOMEPAGE = https://metacpan.org/release/Authen-SASL
OS_VERSION = 8.0
DESCRIPTION =
PKGPATH = security/p5-Authen-SASL
PKG_OPTIONS = gssapi
CATEGORIES = security perl5
SIZE_PKG = 119267
FILE_SIZE = 24892
OPSYS = NetBSD
REPOSITORY = http://cdn.Netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.2/All
sqlite> ^D
pkgin 76 > echo 0 1 2 | xargs -n1 -I XX lynx -head -dump \
? http://cdn.Netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.XX/All/p5-Authen-SASL-2.16nb7.tgz |\
? grep Length
Content-Length: 24900
Content-Length: 24892
Content-Length: 24900
So there's the "size does not match". Others on the
netbsd-users@
mailing list are seeing this download error, too, and I just joined in with my findings.
fred.marshlabs.gaertner.de
is now running DragonflyBSD-5.8.1, a bugfix release from three days ago.
quick
builds did the job. Total time for this source upgrade including everthing from
git pull
to merging
/etc
files, rebooting, updating pkgs, and a final
make initrd
: some 45min.
fred
is an Intel E6550 Core2 Duo CPU with exactly that: 2 cores, running at 2.33GHz, has 4 GB RAM, and 230 GB spinning rust.
One of the open problems shifting my "marshlabs" mail to
hackett
was how to deal with HTML mails. (I mean
you, Paypal, and all the non-tech friends naively using webmail accounts and/or smart-phones.)
NetBSD's
mail
(1) (aka
Mail
and
mailx
) originates from Kurt Shoen's BSD-mail 8.1 but has been brought into the current millenium with basic support for MIME. It will
(If you need to know: nope, OpenBSD and FreeBSD are still sticking to the orginal.)
The basic pipeline to process a message (as stated in the man page):
mail -> MIME-decoder -> MIME-hook -> pager -> screen
The man page also provides an example how to deal with HTML parts:
set mime-body-text-html="+/usr/pkg/bin/lynx -force_html -dump -stdin"
The "+" is a flag to prefer the HTML version over others in a
multipart/alternative
mail. The
-dump
option makes lynx not to behave interactively but to push the rendered message to
stdout
where it gets passed on to the
pager
stage of the pipeline.
Of course an interactive lynx would be much nicer. It would allow you to use any embedded links. However, just leaving off the
-dump
option didn't cut it. It works as bad as
lynx https://gaertner.de/~neitzel/nb/ | less
does -- you end up with just an empty page.
Today I dived further into the
mail(1)
manpage and found a workaround:
set mime-body-text-html="lynx -stdin"
. Before displaying an HTML mail, eitherset pager-off
(NetBSD-mail-specific) orunset crt
(old-school) to suppress the pager stage.
Lynx can be used interactively then. Toggling the pager off and on again, is a nuisance, though. It would be nicer to have that as another flag in the handler.
Strongly related: The currently defined flags for a mime-hook are:
!
: use a sub-shell instead of doing an
exec(3)
.+
: mark as preferred alternate type-
: disable the transfer-decoding stageI already know that the "
-
" feature, i.e. an easy activation/deactivation of the transfer-encoding decoder is important. Gunnar Ritter's fabulous Heirloom-mailx (aka
nail
) provides two variations of the classic
|
command to filter a message:
pipe
(=
|
) and
Pipe
(preserve headers and MIME sections), and you can use
set raw
/
unset raw
to toggle the transfer decoding. I need all of these, and quite often.
With NetBSD, the
|
won't do the transfer-decoding, ever. You need to provide it yourself, as in
& | base64 -d | grep foo
You get the decoding but also the (abridged) mail header with this command:
& set enable-pipes
& p . | grep foo
I wasn't able to make the
write
command work with a
|foo
command destination.
Summary:
I should hack bit more on the NetBSD
mail
source and add a "no-pager" flag for the mime-hooks.
I need to install the
metamail
package and tie that in, too. It's the oldest MIME support kit I am aware of, and I have existing setups with various other MUAs. Thi should make more things work rather quickly, without relying on MUA-specific MIME-hooks.
i just updated
hackett.marshlabs.gaertner.de
on its netbsd-8 STABLE track. We are now at "8.2 and a bit". (The last update had been on 2019-12-27.)
fred.marshlabs.gaertner.de
is now running DragonflyBSD-5.8.0, released five days ago.
A painless source upgrade from the 5.6-stable track.
It's done:
% pcc hw.c && ./a.out
hello world!
This is
pcc(1)
on
eddie
, an i386 running netbsd-9.99.thirtyish. The Portable C Compiler is currently not among the official build targets of netbsd because gcc refuses to build it as-is. That needed to be fixed.
It turned out I had to give a little TLC to just three files, a bit of work spread across a month:
% pwd
/usr/src/external/bsd/pcc/dist/pcc/cc
% ls -lrt ccom/pftn.c cxxcom/builtins.c driver/driver.c
-rw-rw-r-- 1 neitzel wsrc 74886 Jan 22 02:24 ccom/pftn.c
-rw-rw-r-- 1 neitzel wsrc 20350 Jan 29 00:28 driver/driver.c
-rw-rw-r-- 1 neitzel wsrc 22602 Feb 17 21:40 cxxcom/builtins.c
The required changes where small and need further review by someone more competent than me:
% cvs -q diff -u
Index: ccom/pftn.c
===================================================================
RCS file: /cvsroot/src/external/bsd/pcc/dist/pcc/cc/ccom/pftn.c,v
retrieving revision 1.10
diff -u -r1.10 pftn.c
--- ccom/pftn.c 9 Feb 2016 20:37:32 -0000 1.10
+++ ccom/pftn.c 12 May 2020 20:30:52 -0000
@@ -2544,8 +2544,11 @@
if (apole != NULL)
uerror("too many arguments to function");
-build: if (apary)
+build: if (apary) {
+ /* MN: braces because gcc thinks the following
+ stmt is not existing */
FUNFREE(apary);
+ }
if (sp != NULL && (sp->sflags & SINLINE) && (w = inlinetree(sp, f, a)))
return w;
return buildtree(a == NIL ? UCALL : CALL, f, a);
Index: cxxcom/builtins.c
===================================================================
RCS file: /cvsroot/src/external/bsd/pcc/dist/pcc/cc/cxxcom/builtins.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 builtins.c
--- cxxcom/builtins.c 9 Feb 2016 20:28:56 -0000 1.1.1.4
+++ cxxcom/builtins.c 12 May 2020 20:30:52 -0000
@@ -537,7 +537,13 @@
#ifdef LDBL_128
static const unsigned char vLDOUBLE[] = { 0,0,0,0,0,0,0, 0, 0, 0, 0, 0, 0, 0x80, 0xff, 0x7f };
#else /* LDBL_80 */
-static const unsigned char vLDOUBLE[] = { 0, 0, 0, 0, 0, 0, 0, 0x80, 0xff, 0x7f };
+/*
+ * MN: create 2 extra bytes for a total of 96 bits, as with nLDOUBLE;
+ * gcc's sizeof(long double) is 12 bytes = 96 bits, this may be an ABI issue.
+ * the hardware-supported "extended precision floating point" is 80 bits,
+ * 64 bit significant + 16 bits exponent, each signed.
+ */
+static const unsigned char vLDOUBLE[] = { 0, 0, 0, 0, 0, 0, 0, 0x80, 0xff, 0x7f, 0, 0 };
#endif
static const unsigned char nFLOAT[] = { 0, 0, 0xc0, 0x7f };
static const unsigned char nDOUBLE[] = { 0, 0, 0, 0, 0, 0, 0xf8, 0x7f };
@@ -552,6 +558,7 @@
#ifdef LDBL_128
static const unsigned char vLDOUBLE[] = { 0x7f, 0xff, 0x80, 0, 0, 0, 0, 0, 0, 0,0,0,0,0,0,0 };
#else /* LDBL_80 */
+/* MN: this appears to fall short of the 12 byte ABI size, cf. TARGET_LE: */
static const unsigned char vLDOUBLE[] = { 0x7f, 0xff, 0x80, 0, 0, 0, 0, 0, 0, 0 };
#endif
static const unsigned char nFLOAT[] = { 0x7f, 0xc0, 0, 0 };
@@ -559,6 +566,7 @@
#ifdef LDBL_128
static const unsigned char nLDOUBLE[] = { 0x7f, 0xff, 0xc0, 0, 0, 0, 0, 0, 0, 0,0,0,0,0,0,0 };
#else /* LDBL_80 */
+/* MN: this appears to fall short of the 12 byte ABI size, cf. TARGET_LE: */
static const unsigned char nLDOUBLE[] = { 0x7f, 0xff, 0xc0, 0, 0, 0, 0, 0, 0, 0 };
#endif
#endif
Index: driver/driver.c
===================================================================
RCS file: /cvsroot/src/external/bsd/pcc/dist/pcc/cc/driver/driver.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 driver.c
--- driver/driver.c 1 Sep 2011 12:47:04 -0000 1.1.1.1
+++ driver/driver.c 12 May 2020 20:30:53 -0000
@@ -193,7 +193,7 @@
strlist_make_array(l, &argv, &argc);
if (verbose_mode) {
printf("Calling ");
- strlist_print(l, stdout);
+ strlist_print(l, stdout, 1 /* MN XXX guessed! */);
printf("\n");
}
(This is nota proper diff -- the white space was mangled during cutnpaste and the markup may also do funny things to the tabs.)
As you can see I rather coaxed it through gcc than really knowing what's correct. This needs some further shaking out. However, there's some light at the end of the tunnel, and the tunnel seems not to be as endless as someone argued on a netbsd mailing list.
The most difficult part for me was to find out how to run the proper
make
from the proper place in the netbsd
/usr/src
tree. Building the entire system is no option when tackling just a small part of the system.
eddie.marshlabs.gaertner.de
, my i386 EeePc 1000H for primarily compiling and testing netbsd-current systems, got a hardware upgrade:
Out with the 160GB harddisk drive (and nbsd 8.1 on it), and in with a new shiny 120GB SSD (and back to the current
-current
branch, tracking 9.99.x; I had skipped the 8.99.x track).
First impressions about 9.99.x:
i915drmkms
is still broken for the EeePc,
i915drm
instead still works.classic console beeps / terminal bells work again, they are now routed through the HDA system:
% dmesg | grep -Ei 'hda|audio|bell|spk|beep'
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
spkr0 at pcppi1: PC Speaker
wsbell0 at spkr0 mux 1
sysbeep0 at pcppi1
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at msi0 vec 0
hdaudio0: HDA ver. 1.0, OSS 4, ISS 4, BSS 0, SDO 1, 64-bit
hdafg0 at hdaudio0: vendor 10ec product 0269
hdafg0: DAC00 2ch: Speaker [Built-In], HP Out [Jack]
hdafg0: ADC01 2ch: Mic In [Built-In]
hdafg0: ADC02 2ch: Mic In [Jack]
hdafg0: 2ch/2ch 32000Hz 44100Hz 48000Hz 88200Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: playback, capture, full duplex, independent
audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording
spkr1 at audio0: PC Speaker (synthesized)
wsbell1 at spkr1 mux 1
the built-in wireless works now out-of-the-box:
% dmesg | grep ral0
ral0 at pci3 dev 0 function 0: Ralink Technologies RT2790 (rev. 0x00)
ral0: interrupting at ioapic0 pin 19
ral0: 802.11 address 00:22:43:53:42:ac
ral0: MAC/BBP RT2872 (rev 0x0200), RF RT2720 (MIMO 1T2R)
% ifconfig ral0
ral0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ssid ml2 nwkey *****
powersave off
bssid c8:0e:14:fb:ba:3a chan 4
address: 00:22:43:53:42:ac
media: IEEE802.11 autoselect (DS1 mode 11g)
status: active
Nice!
As so often in the past, I just dedicated 20GB to this NetBSD system:
% fdisk wd0
Disk: /dev/rwd0
NetBSD disklabel disk geometry:
cylinders: 232581, heads: 16, sectors/track: 63 (1008 sectors/cylinder)
total sectors: 234441648, bytes/sector: 512
BIOS disk geometry:
cylinders: 1024, heads: 246, sectors/track: 3 (738 sectors/cylinder)
total sectors: 234441648
Partitions aligned to 2048 sector boundaries, offset 2048
Partition table:
0: NetBSD (sysid 169)
start 2048, size 41943040 (20480 MB, Cyls 0-56836/39/3), Active
1: <UNUSED>
2: <UNUSED>
3: <UNUSED>
Bootselector enabled, timeout 5 seconds.
First active partition: 0
Drive serial number: 0 (0x00000000)
The NetBSD is by no means cramped:
% df -h | grep -v fs
Filesystem Size Used Avail %Cap Mounted on
/dev/wd0a 1.9G 1.0G 840M 55% /
/dev/mapper/vg0-local 1.9G 41M 1.8G 2% /usr/local
/dev/mapper/vg0-pkg 993M 17M 926M 1% /usr/pkg
/dev/mapper/vg0-scratch 4.9G 2.4G 2.2G 51% /scratch
/dev/mapper/vg0-src 3.9G 2.8G 948M 74% /usr/src
% lvm vgs
WARNING: Using LVM as operator you have only read access.
VG #PV #LV #SN Attr VSize VFree
vg0 1 4 0 wz--n- 17.00g 5.00g
So there are still 90GB ( realGB out of of 111 realGB as opposed to the 120 metric marketing GB) left for other systems.
On Tuesday, the NetBSD source tree got tagged with
netbsd-8-0-RELEASE
. The announcement is not out yet, but that's no reason not to move from -RC2 to -RELEASE on
eddie
, the Asus EeePC 1000H dedicated to bleeding edge things. So the netbook was seriously burning CPU cycles in the last two days, and welcome, 8.0!
Small things learned:
build.sh
the kernel
modules
explicitly, this is implied in the standard (userland)
build.sh build
. The
build.sh installmodules=/
step is required, though.rm compile/EDDIE
-- a
make clean
or
make cleandir
won't do the job.While
eddie
was busily chugging along on the systems sources, I used the time and updated the "beeper" blog notes from Sunday with further findings on the (now) 8.0 system.