Date: Sun, 28 Oct 2018 20:41:42 -0700 From: "Kristof Provost" <kp@FreeBSD.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: "Ernie Luzar" <luzar722@gmail.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, "FreeBSD current" <freebsd-current@freebsd.org> Subject: Re: 12.0-BETA1 vnet with pf firewall Message-ID: <7D8AB225-061D-4EEC-BC08-5B168F1B44E8@FreeBSD.org> In-Reply-To: <201810282139.w9SLdO58054096@pdx.rh.CN85.dnsmgr.net> References: <201810282139.w9SLdO58054096@pdx.rh.CN85.dnsmgr.net>
index | next in thread | previous in thread | raw e-mail
On 28 Oct 2018, at 14:39, Rodney W. Grimes wrote:
>> Bjoern A. Zeeb wrote:
>>> On 28 Oct 2018, at 15:31, Ernie Luzar wrote:
>>>
>>>> Tested with host running ipfilter and vnet running pf. Tried
>>>> loading
>>>> pf from host console or from vnet console using kldload pf.ko
>>>> command
>>>> and get this error message;
>>>>
>>>> linker_load_file: /boot/kernel/pf.ko-unsupported file type.
>>>>
>>>> Looks like the 12.0 version of pf which is suppose to work in vnet
>>>> independent of what firewall is running on the host is not working.
>>>
>>> You cannot load pf from inside a jail (with or without vnet).
>>> Kernel
>>> modules are global objects loaded from the base system or you
>>> compile
>>> the devices into the kernel; it is their state which is
>>> virtualised.
>>>
>>> If you load multiple firewalls they will all be available to the
>>> base
>>> system and all jails+vnet. Whichever you configure in which one is
>>> up
>>> to you. Just be careful as an unconfigured firewall might have a
>>> default action affecting the outcome of the overall decision.
>>>
>>> For example you could have:
>>>
>>> a base system using ipfilter and setting pf to default accept
>>> everything
>>> and a jail+vnet using pf and setting ipfilter there to accept
>>> everything.
>>>
>>>
>>> Hope that clarifies some things.
>>>
>>> /bz
>>>
>>
>> Hello Bjoern.
>>
>> What you said is correct for 10.x & 11.x. But I an talking about
>> 12.0-beta1. I have the ipfilter options enabled in rc.conf of the
>> host
>> and on boot ipfilter starts just like it all ways does. Now to prep
>> the
>> host for pf in a vnet jail, I issue from the host console the
>> "kldload pf.ko" command and get this error message;
>>
>> linker_load_file: /boot/kernel/pf.ko-unsupported file type.
>>
>> Something is wrong here. This is not suppose to happen according to
>> your
>> post above.
>>
>> Remember that in 12.0 vimage is included in the base system kernel.
>
> Confirmed, if I boot a clean install and issue:
> kldload ipfilter.ko
> kldload pf.ko
> my dmesg has:
> IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled
> linker_load_file: /boot/kernel/pf.ko - unsupported file type
>
Yeah, something’s very, very broken somewhere.
On head loading both pf and ipfilter panics:
Fatal trap 12: page fault while in kernel mode
cpuid = 5; apic id = 05
fault virtual address = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80c8a1d0
stack pointer = 0x28:0xfffffe0088955340
frame pointer = 0x28:0xfffffe0088955340
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 940 (kldload)
[ thread pid 940 tid 100473 ]
Stopped at strncmp+0x10: movzbl (%rdi,%rcx,1),%r8d
db> bt
Tracing pid 940 tid 100473 td 0xfffff80007599000
strncmp() at strncmp+0x10/frame 0xfffffe0088955340
link_elf_lookup_set() at link_elf_lookup_set+0x64/frame
0xfffffe0088955390
sdt_kld_unload_try() at sdt_kld_unload_try+0x39/frame
0xfffffe00889553d0
linker_file_unload() at linker_file_unload+0xeb/frame
0xfffffe0088955430
link_elf_load_file() at link_elf_load_file+0x152/frame
0xfffffe00889554f0
linker_load_module() at linker_load_module+0x97a/frame
0xfffffe0088955800
kern_kldload() at kern_kldload+0xf1/frame 0xfffffe0088955850
sys_kldload() at sys_kldload+0x5b/frame 0xfffffe0088955880
amd64_syscall() at amd64_syscall+0x278/frame 0xfffffe00889559b0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfffffe00889559b0
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002d2f7a, rsp =
0x7fffffffe588, rbp = 0x7fffffffeb00 ---
While I’d recommend very strongly against trying to mix firewalls we
obviously shouldn’t panic.
This doesn’t appear to be specifically either firewalls fault though,
as the panic happens during the linking of the module, not
initialisation of the firewall. Also, it happens regardless of load
order (so ipfilter first or pf first).
(kgdb) bt
#0 __curthread () at ./machine/pcpu.h:230
#1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:366
#2 0xffffffff8046576b in db_dump (dummy=<optimized out>,
dummy2=<unavailable>, dummy3=<unavailable>, dummy4=<unavailable>) at
/usr/src/sys/ddb/db_command.c:574
#3 0xffffffff80465539 in db_command (last_cmdp=<optimized out>,
cmd_table=<optimized out>, dopager=<optimized out>) at
/usr/src/sys/ddb/db_command.c:481
#4 0xffffffff804652b4 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:534
#5 0xffffffff804684cf in db_trap (type=<optimized out>,
code=<optimized out>) at /usr/src/sys/ddb/db_main.c:252
#6 0xffffffff80be71c7 in kdb_trap (type=12, code=0,
tf=0xfffffe0088955280) at /usr/src/sys/kern/subr_kdb.c:693
#7 0xffffffff81073f51 in trap_fatal (frame=0xfffffe0088955280, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:921
#8 0xffffffff81074072 in trap_pfault (frame=0xfffffe0088955280,
usermode=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:765
#9 0xffffffff8107369a in trap (frame=0xfffffe0088955280) at
/usr/src/sys/amd64/amd64/trap.c:441
#10 <signal handler called>
#11 strncmp (s1=0x0, s2=0xffffffff812b970d "set_", n=4) at
/usr/src/sys/libkern/strncmp.c:44
#12 0xffffffff811ade34 in link_elf_lookup_set (lf=0xfffff8000dc43a00,
name=0xffffffff82fcaca2 "sdt_providers_set", startp=0xfffffe00889553a0,
stopp=0xfffffe00889553a8,
countp=0x0) at /usr/src/sys/kern/link_elf_obj.c:1285
#13 0xffffffff82fca5f9 in sdt_kld_unload_try (arg=<optimized out>,
lf=0xfffff8000dc43800, error=0xfffffe0088955404) at
/usr/src/sys/cddl/dev/sdt/sdt.c:321
#14 0xffffffff80b6f3bb in linker_file_unload (file=0xfffff8000dc43a00,
flags=1) at /usr/src/sys/kern/kern_linker.c:656
#15 0xffffffff811ac382 in link_elf_load_file (cls=<optimized out>,
filename=<optimized out>, result=<optimized out>) at
/usr/src/sys/kern/link_elf_obj.c:1016
#16 0xffffffff80b6ecca in LINKER_LOAD_FILE (cls=0xffffffff81b817c0
<link_elf_class>, result=0x0, filename=<optimized out>) at
./linker_if.h:180
#17 linker_load_file (filename=<optimized out>, result=<optimized out>)
at /usr/src/sys/kern/kern_linker.c:447
#18 linker_load_module (kldname=<optimized out>,
modname=0xfffff8000d141c00 "ipfilter", parent=0x0, verinfo=<optimized
out>, lfpp=0xfffffe0088955818)
at /usr/src/sys/kern/kern_linker.c:2110
#19 0xffffffff80b70661 in kern_kldload (td=<optimized out>,
file=<optimized out>, fileid=0xfffffe0088955864) at
/usr/src/sys/kern/kern_linker.c:1089
#20 0xffffffff80b7078b in sys_kldload (td=0xfffff80007599000,
uap=<optimized out>) at /usr/src/sys/kern/kern_linker.c:1115
#21 0xffffffff81074b28 in syscallenter (td=0xfffff80007599000) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#22 amd64_syscall (td=0xfffff80007599000, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:1154
#23 <signal handler called>
#24 0x00000008002d2f7a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffe588
(kgdb) fr 12
#12 0xffffffff811ade34 in link_elf_lookup_set (lf=0xfffff8000dc43a00,
name=0xffffffff82fcaca2 "sdt_providers_set", startp=0xfffffe00889553a0,
stopp=0xfffffe00889553a8,
countp=0x0) at /usr/src/sys/kern/link_elf_obj.c:1285
1285 if ((strncmp(ef->progtab[i].name, "set_", 4) ==
0) &&
(kgdb) p *ef
$1 = {lf = {ops = 0xfffff800040fb000, refs = 1, userrefs = 0, flags =
0, link = {tqe_next = 0x0, tqe_prev = 0xfffff8004b37e418}, filename =
0xfffff8000df9d120 "ipl.ko",
pathname = 0xfffff8000df9f2a0 "/boot/kernel/ipl.ko", id = 17,
address = 0xffffffff83646000 <sysctl_ipf_int>
"UH\211\345AWAVSPH\211\313I\211\366I\211\377H\211U\340H\213C(M\205\366t\r\272\004",
size = 445056, ctors_addr = 0x0,
ctors_size = 0, ndeps = 0, deps = 0x0, common = {stqh_first = 0x0,
stqh_last = 0xfffff8000dc43a70}, modules = {tqh_first = 0x0, tqh_last =
0xfffff8000dc43a80}, loaded = {
tqe_next = 0x0, tqe_prev = 0x0}, loadcnt = 17, nenabled = 0,
fbt_nentries = 0}, preloaded = 0,
address = 0xffffffff83646000 <sysctl_ipf_int>
"UH\211\345AWAVSPH\211\313I\211\366I\211\377H\211U\340H\213C(M\205\366t\r\272\004",
object = 0xfffff800399ec500,
e_shdr = 0xfffff8004b45d800, progtab = 0xfffff8000dc43800, nprogtab =
13, relatab = 0xfffff80015413b00, nrelatab = 9, reltab = 0x0, nreltab =
0,
ddbsymtab = 0xfffffe0090374000, ddbsymcnt = 3446, ddbstrtab =
0xfffffe00903c9000 "", ddbstrcnt = 161248, shstrtab = 0xfffff8000dc43600
"", shstrcnt = 297, ctftab = 0x0,
ctfcnt = 0, ctfoff = 0x0, typoff = 0x0, typlen = 0}
(kgdb) p i
$2 = 12
(kgdb) p *ef->progtab
$3 = {addr = 0xffffffff83646000 <sysctl_ipf_int>, size = 300898, flags
= 0, sec = 1, name = 0xfffff8000dc43620 ".text"}
(kgdb) p ef->progtab[12]
$4 = {addr = 0x0, size = 0, flags = 0, sec = 0, name = 0x0}
(kgdb)
So we panic because we dereference a NULL pointer in strncmp(), which
happens because nprogtab = 13 but ef->progtab[12] has NULL pointers.
It’s not clear to me why that happens, but it’s something to go on.
I do wonder if this isn’t a bit of a red herring too. It might be an
error in the error path (because we pass through linker_file_unload()).
link_elf_load_file() increments ef->nprogtab for SHT_X86_64_UNWIND, so
perhaps the error handling doesn’t cope with that.
(I likely won’t be able to look at this further in the next day or
two. I’m flying home from MeetBSD.)
Best regards,
Kristof
From owner-freebsd-current@freebsd.org Mon Oct 29 04:13:33 2018
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CFE110EF2F3
for <freebsd-current@mailman.ysv.freebsd.org>;
Mon, 29 Oct 2018 04:13:33 +0000 (UTC)
(envelope-from grahamperrin@gmail.com)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
[IPv6:2a00:1450:4864:20::236])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 6D6817CD3F
for <freebsd-current@freebsd.org>; Mon, 29 Oct 2018 04:13:32 +0000 (UTC)
(envelope-from grahamperrin@gmail.com)
Received: by mail-lj1-x236.google.com with SMTP id v6-v6so6377490ljc.11
for <freebsd-current@freebsd.org>; Sun, 28 Oct 2018 21:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s 161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-transfer-encoding;
bh=tjvNlWyH6Gm3EDl0/x9fQI3d0OMIbkfMZlIA+qptlzQ=;
b=jWl1huGOMXMZB695ZSoc1Y9Gn4F3ylHlHf8JjVUW1LKUVol+ILdMRq8NcnDOs3uDmN
eJQdFEJXirFU7UTU0bfWbGdcK9lnA/xw3PyY+wG5yPUQMWX4V/Igf+e59egEmhk2xh3N
DKg9Dv9Ook8oteJMt8XuqIgYnr93nRacv5+CMTEM5XKD1/BnNI/TK5DlKkkKLE/8PxnX
2OpzfO1mXzdNecScNvUPsagTtaCRmUxNFlsLosGycIQraYMajoTefFdmQsye7oaqsvzO
LcV68v74aC5ovtGadYSjHL7U1xJmBlyqfi2lZMszDXSybJ2zSZv8IJEG5bys4vyGw5XG
05cw=X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d 100.net; s 161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=tjvNlWyH6Gm3EDl0/x9fQI3d0OMIbkfMZlIA+qptlzQ=;
b=DnDyEJG7d/AqXAuZejCcbTNpgMe4DjSX0r6G34vx/53x3V4k4BIfx1IW8HHmtyxYfj
8fwjjCf1WVNOfaobIbizufLPxryu7ypY5KkRpmJLboHdJQ2RhRR6lIMPEqYcwzSSUZOO
2q//zdIocfBkY+LuY1RB07/aPp6cVk+8FFywAN42bTRloiNfylruGjqEt0qkmuBvoAdR
u9IFWyhx17Lrl+3r9qzBWO7VPy9G286BvL0Evurw57UqObC3YSRAqwkD4XEr7X4+a7PQ
gM2WLPloBLQl7foMv1/SARquFjKnjDw3XwhgspWWXdB25f7xbIMC8PAviKENBytiPbnv
srJQ=X-Gm-Message-State: AGRZ1gKchfNqSfWVFSGYwDt2UOXdgNR3c9osK+DNz60M5DyEJD/0AEhp
hNsF+X1gTDU5/HlPn+LFcxnf0/KlTCDHB/Eiygjy8yaY
X-Google-Smtp-Source: AJdET5ffrpMXTHNtvS79zcDUT4GPLN7lgfyHvVnb3K3t3K9+SiQfBFpABN9iW5Qh6yuXpq7OK7o+Lq7HXl7ricN4phoX-Received: by 2002:a2e:215a:: with SMTP id
h87-v6mr8879103ljh.102.1540786409402;
Sun, 28 Oct 2018 21:13:29 -0700 (PDT)
MIME-Version: 1.0
References: <5f99c2a6-7626-7457-65e1-bbca99fc343b@gmail.com>
<4ld5-sleo-wny@FreeBSD.org>
In-Reply-To: <4ld5-sleo-wny@FreeBSD.org>
From: Graham Perrin <grahamperrin@gmail.com>
Date: Mon, 29 Oct 2018 04:13:11 +0000
Message-ID: <CALvFMRzG3m7H0GzzUyZZhvh73nd8cs=teCczPW_3kgqkwqVkow@mail.gmail.com>
Subject: Waterfox: downgrading to icu-62.1_2,1 and rebuilding consumers
To: FreeBSD Current <freebsd-current@freebsd.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>;
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2018 04:13:33 -0000
Thanks, people! devel/icu was the hint that I needed.
On Sun, 28 Oct 2018 at 23:26, Jan Beich <jbeich@freebsd.org> wrote:
> … Either rebuild www/waterfox from the last revision before removal or
> downgrade devel/icu to 62.1 if nothing else requires 63.1. In the former
> case you can also update the port (adjust DISTVERSION then run "make
> makesum") assuming no patch conflicts. …
For now, I chose a quick dowgrade (breaking everything other than
Waterfox that currently depends on icu). Success: Waterfox works.
First in line for a rebuild is Thunderbird,
<https://www.freshports.org/mail/thunderbird#requiredtobuild>;
specifies icu>=59.1,1 so I'm probably OK there with devel/icu 62.1.
Below, with poudriere:
- is this DEFAULT_VERSIONS= line correct/sufficient for
Thunderbird etc. to be built with the inferior version of icu?
DEFAULT_VERSIONS= icu=62.1_2,1
----
# date ; uname -v
Mon 29 Oct 2018 02:53:29 GMT
FreeBSD 13.0-CURRENT r339737 GENERIC-NODEBUG
# pkg info -r devel/icu
icu-63.1,1:
waterfox-56.2.3_2
qt5-core-5.11.2_1
spidermonkey52-52.8.0_2
boost-libs-1.68.0_2
harfbuzz-icu-2.0.2_1
webkit2-gtk3-2.20.5_2
qt5-webkit-5.212.0.a2_14
libical-3.0.3_1
texlive-base-20150521_29
evolution-data-server-3.28.3_1
tesseract-3.05.02_3
libqalculate-2.6.1_1
tracker-2.0.4_1
webkit-gtk2-2.4.11_18
raptor2-2.0.15_10
qt4-corelib-4.8.7_14
tracker-miners-2.0.5_1
webkit-gtk3-2.4.11_17
seamonkey-2.49.4_14
node-10.12.0_1
libzmf-0.0.2_11
libvisio01-0.1.6_8
libqxp-0.0.0_6
libmspub01-0.1.4_6
libe-book-0.1.3_7
libcdr01-0.1.4_11
gnome-shell-3.28.2_1
freerdp-2.0.0.r3_3
thunderbird-60.2.1_2
palemoon-27.9.4_1
libreoffice-6.0.5_6
iridium-browser-2018.5.67_5
evolution-3.28.3_1
epiphany-3.28.3.1_1
chromium-68.0.3440.106_5
calibre-3.33.1_1
firefox-63.0_2,1
# pkg remove -f devel/icu
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0
packages in the universe):
Installed packages to be REMOVED:
icu-63.1,1
Number of packages to be removed: 1
The operation will free 46 MiB.
Proceed with deinstalling packages? [y/N]: y
[1/1] Deinstalling icu-63.1,1...
[1/1] Deleting files for icu-63.1,1: 100%
# pkg add /var/cache/pkg/icu-62.1_2,1.txz
Installing icu-62.1_2,1...
Extracting icu-62.1_2,1: 100%
# pkg lock devel/icu
icu-62.1_2,1: lock this package? [y/N]: y
Locking icu-62.1_2,1
# exit
root@momh167-gjp4-hpelitebook8570p-freebsd:~ # exit
logout
[grahamperrin@momh167-gjp4-hpelitebook8570p-freebsd] ~% waterfox -p everyday
Fontconfig warning: "/usr/local/etc/fonts/local.conf", line 1093: saw
number, expected matrix
console.log: *** aboutsync: starting up
…
[grahamperrin@momh167-gjp4-hpelitebook8570p-freebsd] ~% su -
Password:
root@momh167-gjp4-hpelitebook8570p-freebsd:~ # sh
# poudriere ports -u
[00:00:00] Updating portstree "default" with portsnap...Looking up
portsnap.FreeBSD.org mirrors... 5 mirrors found.
Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Sun Oct 28 21:43:27 GMT 2018 to Mon Oct 29 02:28:37 GMT 2018.
Fetching 5 metadata patches... done.
Applying metadata patches... done.
Fetching 0 metadata files... done.
Fetching 6 patches.
(6/6) 100.00% done.
done.
Applying patches...
done.
Fetching 3 new ports or files... done.
Removing old files and directories... done.
Extracting new files:
/usr/local/poudriere/ports/default/biology/iqtree/
/usr/local/poudriere/ports/default/databases/mysql57-client/
/usr/local/poudriere/ports/default/databases/mysql57-server/
/usr/local/poudriere/ports/default/devel/Makefile
/usr/local/poudriere/ports/default/devel/libpcl/
/usr/local/poudriere/ports/default/graphics/Makefile
/usr/local/poudriere/ports/default/graphics/radiance/
/usr/local/poudriere/ports/default/misc/Makefile
/usr/local/poudriere/ports/default/misc/lastools/
Building new INDEX files... done.
done
# grep DEFAULT_VERSIONS /usr/local/etc/poudriere.d/make.conf
DEFAULT_VERSIONS+= samba=4.8
DEFAULT_VERSIONS= icu=62.1_2,1
# poudriere bulk -j current mail/thunderbird
[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for current-default
[00:00:01] Mounting ports/packages/distfiles
[00:00:01] Stashing existing package repository
[00:00:01] Mounting ccache from: /var/cache/ccache
[00:00:01] Mounting packages from:
/usr/local/poudriere/data/packages/current-default
[00:00:01] Copying /var/db/ports from:
/usr/local/etc/poudriere.d/current-options
[00:00:01] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf ->
/usr/local/poudriere/data/.m/current-default/ref/etc/resolv.conf
[00:00:01] Starting jail current-default
[00:00:04] Logs:
/usr/local/poudriere/data/logs/bulk/current-default/2018-10-29_03h06m42s
[00:00:04] Loading MOVED for
/usr/local/poudriere/data/.m/current-default/ref/usr/ports
[00:00:05] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:05] Gathering ports metadata
[00:00:13] Calculating ports order and dependencies
[00:00:14] Sanity checking the repository
[00:00:14] Checking packages for incremental rebuild needs
[00:00:24] Deleting stale symlinks... done
[00:00:24] Deleting empty directories... done
[00:00:24] Cleaning the build queue
[00:00:25] Sanity checking build queue
[00:00:25] Processing PRIORITY_BOOST
[00:00:25] Balancing pool
[00:00:25] Recording filesystem state for prepkg... done
[00:00:34] Building 3 packages using 3 builders
[00:00:34] Starting/Cloning builders
[00:00:37] Hit CTRL+t at any time to see build progress and stats
[00:00:37] [01] [00:00:00] Building devel/llvm70 | llvm70-7.0.0
[00:00:37] [02] [00:00:00] Building lang/rust | rust-1.30.0
----
– it'll be a few hours before the build of Thunderbird can begin.
As an aside,
> … devel/icu major updates aren't ABI-compatible, so each update
> requires rebuilding every consumer. …
I _had_ planned to stick with 12 for a while, but the first beta
didn't work out and re:
<https://github.com/FreeBSDDesktop/kms-drm/issues/101>; after a week of
being limited to VESA and just one display, I got itchy feet and
stepped up to 13 :-)
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7D8AB225-061D-4EEC-BC08-5B168F1B44E8>