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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =3D pass all, Logging =3D enabl=
ed
> linker_load_file: /boot/kernel/pf.ko - unsupported file type
>
Yeah, something=E2=80=99s very, very broken somewhere.
On head loading both pf and ipfilter panics:
Fatal trap 12: page fault while in kernel mode
cpuid =3D 5; apic id =3D 05
fault virtual address =3D 0x0
fault code =3D supervisor read data, page not present
instruction pointer =3D 0x20:0xffffffff80c8a1d0
stack pointer =3D 0x28:0xfffffe0088955340
frame pointer =3D 0x28:0xfffffe0088955340
code segment =3D base 0x0, limit 0xfffff, type 0x1b
=3D DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags =3D interrupt enabled, resume, IOPL =3D 0
current process =3D 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 =3D 0x8002d2f7a, rsp =
=3D =
0x7fffffffe588, rbp =3D 0x7fffffffeb00 ---
While I=E2=80=99d recommend very strongly against trying to mix firewalls=
we =
obviously shouldn=E2=80=99t panic.
This doesn=E2=80=99t appear to be specifically either firewalls fault tho=
ugh, =
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=3D0) at /usr/src/sys/kern/kern_shutdown.c:366
#2 0xffffffff8046576b in db_dump (dummy=3D<optimized out>, =
dummy2=3D<unavailable>, dummy3=3D<unavailable>, dummy4=3D<unavailable>) a=
t =
/usr/src/sys/ddb/db_command.c:574
#3 0xffffffff80465539 in db_command (last_cmdp=3D<optimized out>, =
cmd_table=3D<optimized out>, dopager=3D<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=3D<optimized out>, =
code=3D<optimized out>) at /usr/src/sys/ddb/db_main.c:252
#6 0xffffffff80be71c7 in kdb_trap (type=3D12, code=3D0, =
tf=3D0xfffffe0088955280) at /usr/src/sys/kern/subr_kdb.c:693
#7 0xffffffff81073f51 in trap_fatal (frame=3D0xfffffe0088955280, eva=3D=
0) =
at /usr/src/sys/amd64/amd64/trap.c:921
#8 0xffffffff81074072 in trap_pfault (frame=3D0xfffffe0088955280, =
usermode=3D<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:765
#9 0xffffffff8107369a in trap (frame=3D0xfffffe0088955280) at =
/usr/src/sys/amd64/amd64/trap.c:441
#10 <signal handler called>
#11 strncmp (s1=3D0x0, s2=3D0xffffffff812b970d "set_", n=3D4) at =
/usr/src/sys/libkern/strncmp.c:44
#12 0xffffffff811ade34 in link_elf_lookup_set (lf=3D0xfffff8000dc43a00, =
name=3D0xffffffff82fcaca2 "sdt_providers_set", startp=3D0xfffffe00889553a=
0, =
stopp=3D0xfffffe00889553a8,
countp=3D0x0) at /usr/src/sys/kern/link_elf_obj.c:1285
#13 0xffffffff82fca5f9 in sdt_kld_unload_try (arg=3D<optimized out>, =
lf=3D0xfffff8000dc43800, error=3D0xfffffe0088955404) at =
/usr/src/sys/cddl/dev/sdt/sdt.c:321
#14 0xffffffff80b6f3bb in linker_file_unload (file=3D0xfffff8000dc43a00,=
=
flags=3D1) at /usr/src/sys/kern/kern_linker.c:656
#15 0xffffffff811ac382 in link_elf_load_file (cls=3D<optimized out>, =
filename=3D<optimized out>, result=3D<optimized out>) at =
/usr/src/sys/kern/link_elf_obj.c:1016
#16 0xffffffff80b6ecca in LINKER_LOAD_FILE (cls=3D0xffffffff81b817c0 =
<link_elf_class>, result=3D0x0, filename=3D<optimized out>) at =
=2E/linker_if.h:180
#17 linker_load_file (filename=3D<optimized out>, result=3D<optimized ou=
t>) =
at /usr/src/sys/kern/kern_linker.c:447
#18 linker_load_module (kldname=3D<optimized out>, =
modname=3D0xfffff8000d141c00 "ipfilter", parent=3D0x0, verinfo=3D<optimiz=
ed =
out>, lfpp=3D0xfffffe0088955818)
at /usr/src/sys/kern/kern_linker.c:2110
#19 0xffffffff80b70661 in kern_kldload (td=3D<optimized out>, =
file=3D<optimized out>, fileid=3D0xfffffe0088955864) at =
/usr/src/sys/kern/kern_linker.c:1089
#20 0xffffffff80b7078b in sys_kldload (td=3D0xfffff80007599000, =
uap=3D<optimized out>) at /usr/src/sys/kern/kern_linker.c:1115
#21 0xffffffff81074b28 in syscallenter (td=3D0xfffff80007599000) at =
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#22 amd64_syscall (td=3D0xfffff80007599000, traced=3D0) 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=3D0xfffff8000dc43a00, =
name=3D0xffffffff82fcaca2 "sdt_providers_set", startp=3D0xfffffe00889553a=
0, =
stopp=3D0xfffffe00889553a8,
countp=3D0x0) at /usr/src/sys/kern/link_elf_obj.c:1285
1285 if ((strncmp(ef->progtab[i].name, "set_", 4) =3D=
=3D =
0) &&
(kgdb) p *ef
$1 =3D {lf =3D {ops =3D 0xfffff800040fb000, refs =3D 1, userrefs =3D 0, =
flags =3D =
0, link =3D {tqe_next =3D 0x0, tqe_prev =3D 0xfffff8004b37e418}, filename=
=3D =
0xfffff8000df9d120 "ipl.ko",
pathname =3D 0xfffff8000df9f2a0 "/boot/kernel/ipl.ko", id =3D 17,
address =3D 0xffffffff83646000 <sysctl_ipf_int> =
"UH\211\345AWAVSPH\211\313I\211\366I\211\377H\211U\340H\213C(M\205\366t\r=
\272\004", =
size =3D 445056, ctors_addr =3D 0x0,
ctors_size =3D 0, ndeps =3D 0, deps =3D 0x0, common =3D {stqh_first =
=3D 0x0, =
stqh_last =3D 0xfffff8000dc43a70}, modules =3D {tqh_first =3D 0x0, tqh_la=
st =3D =
0xfffff8000dc43a80}, loaded =3D {
tqe_next =3D 0x0, tqe_prev =3D 0x0}, loadcnt =3D 17, nenabled =3D =
0, =
fbt_nentries =3D 0}, preloaded =3D 0,
address =3D 0xffffffff83646000 <sysctl_ipf_int> =
"UH\211\345AWAVSPH\211\313I\211\366I\211\377H\211U\340H\213C(M\205\366t\r=
\272\004", =
object =3D 0xfffff800399ec500,
e_shdr =3D 0xfffff8004b45d800, progtab =3D 0xfffff8000dc43800, nprogta=
b =3D =
13, relatab =3D 0xfffff80015413b00, nrelatab =3D 9, reltab =3D 0x0, nrelt=
ab =3D =
0,
ddbsymtab =3D 0xfffffe0090374000, ddbsymcnt =3D 3446, ddbstrtab =3D =
0xfffffe00903c9000 "", ddbstrcnt =3D 161248, shstrtab =3D 0xfffff8000dc43=
600 =
"", shstrcnt =3D 297, ctftab =3D 0x0,
ctfcnt =3D 0, ctfoff =3D 0x0, typoff =3D 0x0, typlen =3D 0}
(kgdb) p i
$2 =3D 12
(kgdb) p *ef->progtab
$3 =3D {addr =3D 0xffffffff83646000 <sysctl_ipf_int>, size =3D 300898, f=
lags =
=3D 0, sec =3D 1, name =3D 0xfffff8000dc43620 ".text"}
(kgdb) p ef->progtab[12]
$4 =3D {addr =3D 0x0, size =3D 0, flags =3D 0, sec =3D 0, name =3D 0x0}
(kgdb)
So we panic because we dereference a NULL pointer in strncmp(), which =
happens because nprogtab =3D 13 but ef->progtab[12] has NULL pointers.
It=E2=80=99s not clear to me why that happens, but it=E2=80=99s something=
to go on. =
I do wonder if this isn=E2=80=99t 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=E2=80=99t cope with that.
(I likely won=E2=80=99t be able to look at this further in the next day o=
r =
two. I=E2=80=99m 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=20161025;
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=1e100.net; s=20161025;
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+Lq7HXl7ricN4pho=
X-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:
> =E2=80=A6 Either rebuild www/waterfox from the last revision before remov=
al 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. =E2=80=A6
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>=3D59.1,1 so I'm probably OK there with devel/icu 62.1.
Below, with poudriere:
- is this DEFAULT_VERSIONS=3D line correct/sufficient for
Thunderbird etc. to be built with the inferior version of icu?
DEFAULT_VERSIONS=3D icu=3D62.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 everyda=
y
Fontconfig warning: "/usr/local/etc/fonts/local.conf", line 1093: saw
number, expected matrix
console.log: *** aboutsync: starting up
=E2=80=A6
[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+=3D samba=3D4.8
DEFAULT_VERSIONS=3D icu=3D62.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
----
=E2=80=93 it'll be a few hours before the build of Thunderbird can begin.
As an aside,
> =E2=80=A6 devel/icu major updates aren't ABI-compatible, so each update
> requires rebuilding every consumer. =E2=80=A6
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 :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7D8AB225-061D-4EEC-BC08-5B168F1B44E8>