From: Roger Marquis wrote on
Date: Sun, 19 Dec 2021 08:33:09 -0800 (PST) :
> mail/postfix is in git though, so the question then is why is it not
> also on www.freebsd.org.
When I look for postfix-3 it finds such (without also matching
a bunch of other things with a "postfix-"[non-digit] prefix:
On 2021-Dec-13, at 23:16, Mark Millard wrote:
> From: Larry Rosenman wrote on
> Date: Mon, 13 Dec 2021 18:48:52 -0600 :
>
>> https://home.lerctr.org:/data/p130-S-amd64-host-ports/2021-12-13_18h14m58s/logs/errors/go-1.17.5,1.log
>>
>>
>> # cmd/compile/internal/ssa
>> fatal error: unexpecte
From: Larry Rosenman wrote on
Date: Mon, 13 Dec 2021 18:48:52 -0600 :
> https://home.lerctr.org:/data/p130-S-amd64-host-ports/2021-12-13_18h14m58s/logs/errors/go-1.17.5,1.log
>
>
> # cmd/compile/internal/ssa
> fatal error: unexpected signal during runtime execution
> [signal SIGBUS: bus err
On 2021-Nov-27, at 06:04, Mark Millard wrote:
> Notably amd64 targeting did not have this problem. I've not
> tried aarch64 targeting yet.
I've now built for aarch64 based on the same /usr/ports
as used for the other builds and iperf3 built fione.
I do not know about 32-bit or 64-bit powerpc bu
Notably amd64 targeting did not have this problem. I've not
tried aarch64 targeting yet.
Still, it looks like iperf3 needs the #define _WITH_CPU_SET_T
opt-in someplace:
--- iperf_api.lo ---
iperf_api.c:4460:5: error: unknown type name 'cpu_set_t'; did you mean
'cpuset_t'?
cpu_set_t cpu_set;
I do not remember the output from poudriere builds having reports
like the following before:
pid 35298 comm conftest has trashed its stack, killing
. . .
pid 36773 comm conftest has trashed its stack, killing
(There are 16 builders active in the bulk run. The output
does not make it clear which b
On 2021-Nov-16, at 08:42, Tijl Coosemans wrote:
> On Sun, 14 Nov 2021 17:57:23 -0800 Mark Millard
> wrote:
>> poudriere output:
>>
>> [00:24:23] [09] [00:01:20] Saved devel/automake | automake-1.16.4 wrkdir to:
>> /usr/local/poudriere/data/wrkdirs/13_0R-CA72-default/default/automake-1.16.4.t
In the following output from poudriere-devel there is no report
of devel/llvm13 in [02] being "Finished" or [02] starting
devel/qt5-help but there is a report of [02] finishing
devel/qt5-help . The "Built ports" list does include devel/llvm13 .
. . .
load: 32.63 cmd: sh 40873 [runnable] 0.01r 0
poudriere output:
[00:24:23] [09] [00:01:20] Saved devel/automake | automake-1.16.4 wrkdir to:
/usr/local/poudriere/data/wrkdirs/13_0R-CA72-default/default/automake-1.16.4.tbz
[00:24:23] [09] [00:01:20] Finished devel/automake | automake-1.16.4: Failed:
configure
. . .
logs/errors/automake-1.16
The following is from during a www/chromium build attempt after the
perquisites have built --so only builder 1 is active. (The context
happens to be ZFS in case that matters.)
# df -m | grep "^tmpfs " | sort | more
. . .
tmpfs 519369
As part of an experiment with building something else with
poudriere-devel, I ended up indirectly attempting to build
print/freetype2 but with WITH_DEBUG= .
The build failed with (note the *d.so* naming in the first
part and the lack of the "d" in the second part):
-- Installing:
/wrkdirs/usr/
On 2021-Oct-23, at 16:49, Piotr Kubaj wrote:
>
> Yes, but powerpc64 package builder is down anyway, and ETA is unknown.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259104
From seeing just:
QUOTE
devel/llvm12: fix/workaround liblzma incorrect compress/uncompress
Apply https:/
This update did not change enough to cause poudriere-devel to automatically
rebuild
to pick up the fix.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
This update did not change enough to cause poudriere-devel to automatically
rebuild
to pick up the fix.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
On aarh64 my poudriere=-devel builds of lang/mono6.8 get stuck
(and so evenutally time out with a lack of output to stdout).
. . .
[00:02:42] Building 1 packages using 1 builders
[00:02:42] Starting/Cloning builders
[00:02:43] Hit CTRL+t at any time to see build progress and stats
[00:02:43] [01]
Piotr Kubaj wrote on
Date: Tue, 5 Oct 2021 22:41:38 +0200 :
> But I agree that building everything with LTO may require memory upgrades
> for builders. The extreme example is mongodb (has an LTO option enabled by
> default) which allocates close to 30GB RAM during linking.
Sounds like armv7, arm
On 2021-Sep-23, at 15:07, Mark Millard wrote:
> So far my attempts at an aarch64 native bulk -a have had
> www/chromium fail with:
>
> . . .
> python3 ../../build/util/python2_action.py
> ../../third_party/blink/renderer/bindings/scripts/generate_bindings.py
> --web_idl_database
> gen/thir
On 2021-Oct-1, at 21:52, Mark Millard wrote:
> I've a case of my poudriere-devel builds of www/chromium in
> python code that is executing but the builds on the FreeBSD
> servers do not get the error.
>
> This lead me to look at my log vs. one from the servers
> and I found a difference that I t
I've a case of my poudriere-devel builds of www/chromium in
python code that is executing but the builds on the FreeBSD
servers do not get the error.
This lead me to look at my log vs. one from the servers
and I found a difference that I think might change python
behavior, not that I've proved tha
On 2021-Sep-26, at 10:02, Ian Lepore wrote:
> On Sun, 2021-09-26 at 02:27 -0700, Mark Millard via freebsd-current
> wrote:
>> On 2021-Sep-25, at 23:25, Mark Millard wrote:
>>
>>
>> [...]
>> if (argc == 3 && strcmp(argv[2], "-nsec") == 0)
>> printf("%ld.%ld\n", ts.tv_sec
I get odd time reports from poudriere on an armv7 under main [so: 14]:
# poudriere bulk -jmain-CA7 lang/rust
[00:00:00] Creating the reference jail... done
. . .
[00:00:00] Balancing pool
[main-CA7-default] [2021-09-25_23h11m13s] [balancing_pool:] Queued: 70 Built: 0
Failed: 0 Skipped: 0 Ign
On 2021-Sep-25, at 10:04, Bryan Drewery wrote:
> On 9/25/2021 12:31 AM, Mark Millard wrote:
>>
>>
>> On 2021-Sep-24, at 12:06, Bryan Drewery wrote:
>>
>>> On 9/22/2021 12:26 PM, Mark Millard wrote:
When I just tried to pkgclean -a I got:
# poudriere pkgclean -jmain-CA7 -a -y
>
On 2021-Sep-24, at 12:06, Bryan Drewery wrote:
> On 9/22/2021 12:26 PM, Mark Millard wrote:
>> When I just tried to pkgclean -a I got:
>>
>> # poudriere pkgclean -jmain-CA7 -a -y
>> [00:00:00] Gathering all expected packages
>> [00:00:00] Creating the reference jail... done
>> [00:00:03] Moun
So far my attempts at an aarch64 native bulk -a have had
www/chromium fail with:
. . .
python3 ../../build/util/python2_action.py
../../third_party/blink/renderer/bindings/scripts/generate_bindings.py
--web_idl_database
gen/third_party/blink/renderer/bindings/web_idl_database.pickle --r
oot_src
When I just tried to pkgclean -a I got:
# poudriere pkgclean -jmain-CA7 -a -y
[00:00:00] Gathering all expected packages
[00:00:00] Creating the reference jail... done
[00:00:03] Mounting system devices for main-CA7-default
[00:00:03] Mounting ports from: /usr/ports
[00:00:03] Mounting packages fr
On 2021-Sep-20, at 17:47, Mark Millard wrote:
> On 2021-Sep-20, at 15:10, Mark Millard wrote:
>
>> On 2021-Sep-20, at 13:58, Mark Millard wrote:
>>
>>>
>>> On 2021-Sep-20, at 12:54, Lucas Nali de Magalhães
>>> wrote:
>>>
On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolch
On 2021-Sep-20, at 15:10, Mark Millard wrote:
> On 2021-Sep-20, at 13:58, Mark Millard wrote:
>
>>
>> On 2021-Sep-20, at 12:54, Lucas Nali de Magalhães
>> wrote:
>>
>>> On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain
>>> wrote:(…)
>>>
>>> (…)
>>>
>>> The HoneyComb failur
On 2021-Sep-20, at 13:58, Mark Millard wrote:
>
> On 2021-Sep-20, at 12:54, Lucas Nali de Magalhães
> wrote:
>
>> On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain
>> wrote:(…)
>>
>> (…)
>>
>> The HoneyComb failure looks to me like like hitting the process
>> size limitation
On 2021-Sep-20, at 12:54, Lucas Nali de Magalhães wrote:
> On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain
> wrote:(…)
>
> (…)
>
> The HoneyComb failure looks to me like like hitting the process
> size limitations for armv7, something that did not happen on the
> MACCHIATObi
On 2021-Sep-14, at 09:12, Bryan Drewery wrote:
> On 9/13/2021 3:57 PM, Mark Millard wrote:
>> [31:27:49] [14] [00:00:00] Building devel/erlang-cf | erlang-cf-0.3.1
>> [31:27:49] [14] [31:27:49] Finished devel/erlang-cf | erlang-cf-0.3.1:
>> Failed: starting
>> [31:27:50] [14] [31:27:50] Skipp
On 2021-Sep-14, at 09:05, Bryan Drewery wrote:
> On 9/14/2021 7:08 AM, Mark Millard wrote:
>>
>>
>> On 2021-Sep-13, at 15:57, Mark Millard wrote:
>>
>>> I've no clue how to reproduce such. It has not repeated so far as
>>> the bulk -a continued.
>>>
>>> . . .
>>> [31:27:49] [14] [00:00:00
On 2021-Sep-13, at 15:57, Mark Millard wrote:
> I've no clue how to reproduce such. It has not repeated so far as
> the bulk -a continued.
>
> . . .
> [31:27:49] [14] [00:00:00] Building devel/erlang-cf | erlang-cf-0.3.1
> [31:27:49] [14] [31:27:49] Finished devel/erlang-cf | erlang-cf-0.3.1:
I've no clue how to reproduce such. It has not repeated so far as
the bulk -a continued.
. . .
[31:27:49] [14] [00:00:00] Building devel/erlang-cf | erlang-cf-0.3.1
[31:27:49] [14] [31:27:49] Finished devel/erlang-cf | erlang-cf-0.3.1: Failed:
starting
[31:27:50] [14] [31:27:50] Skipping devel/er
It looks like emulators/mame should be marked broken for the likes
of armv7 (and armv6) because of process size limitations for armv7
(or armv6).
From an attempted poudreire bulk -a that is ongoing:
[42:47:44] [10] [20:53:04] Finished emulators/mame | mame-0.226_1: Failed: build
for which:
. .
I recently updated ports on multiple systems (amd64m aarch64)
to:
# ~/fbsd-based-on-what-commit.sh
branch: main
merge-base: 1af1b4caa25a2d4dcee07939369e988c996bffe5
merge-base: CommitDate: 2021-09-06 00:39:11 +
1af1b4caa25a (HEAD -> main, freebsd/main, freebsd/HEAD) www/webkit2-gtk3:
convert
From: bob prohaska wrote on
Date: Tue, 24 Aug 2021 08:35:54 -0700 :
> On Tue, Aug 24, 2021 at 11:09:54AM +0200, Ronald Klop wrote:
> >
> > Van: Mark Millard via freebsd-ports
> > Datum: dinsdag, 24 augustus 2021 10:58
> > Aan: freebsd-ports_at_freebsd.org, bob
From: bob prohaska wrote on
Date: Tue, 31 Aug 2021 12:04:35 -0700 :
> A recent attempt to compile gimp under poudriere stopped, reporting
> a failure to build graphics/librsvg2-rust. The offending directory
> was deleted then restored using git restore graphics/librsvg2-rust
> and the build of
bob prohaska wrote on
Date: Mon, 23 Aug 2021 08:27:33 -0700 :
> When trying to build www/chromium on a 1 GB Pi3 the system
> gets bogged down by five instances of python2.7 running
> simultaneously. This happens using both poudriere and make.
>
> It wasn't a problem a year ago, so presumably
On 2021-Aug-16, at 07:39, bob prohaska wrote:
> On Mon, Aug 16, 2021 at 06:46:18AM -0700, Mark Millard wrote:
>> [257:10:19][ 85% 41061/47953] c++ -MMD -MF . . .
>> [257:10:25]=>> Killing timed out build after 904800 seconds
>> [257:10:39][ 85% 41062/47953] c++ -MMD -MF . . .
>> . . .
>> [260:10:
From: Robert Clausecker wrote on
Date: Wed, 28 Jul 2021 14:43:26 +0200 :
> A port for MEGAsync [1] has been requested [2]. Unfortunately,
> MEGAsync comes with a license [3] that is too restrictive to allow
> for a port to be made. So I went ahead and asked the project, if
> they would give per
On 2021-Jul-16, at 11:11, Mark Millard wrote:
> From: bob prohaska wrote on
> Date: Fri, 16 Jul 2021 08:40:24 -0700 :
>
>> While compiling www/chromium on an 8GB RPI4 poudriere stopped with
>> FAILED: v8_context_snapshot_generator
>>
>> Does anybody recognize this error? If it helps I can put
From: bob prohaska wrote on
Date: Fri, 16 Jul 2021 08:40:24 -0700 :
> While compiling www/chromium on an 8GB RPI4 poudriere stopped with
> FAILED: v8_context_snapshot_generator
>
> Does anybody recognize this error? If it helps I can put the
> machine on the net via http so folks can browse rel
On 2021-Jul-10, at 15:54, bob prohaska wrote:
> On Sat, Jul 10, 2021 at 02:17:46PM -0700, Mark Millard wrote:
>> Your latest build did not run out of swap/paging space.
>> It just hit the time limits that you have set, in this
>> case a 172800 second one:
>>
>> . . .
>> [49:09:17] [ 40% 19569/47
Your latest build did not run out of swap/paging space.
It just hit the time limits that you have set, in this
case a 172800 second one:
. . .
[49:09:17] [ 40% 19569/47953] c++ . . . -o
obj/net/third_party/quiche/quiche/quic_server_initiated_spdy_stream.o
[49:09:39] =>> Killing timed out build af
On 2021-Jul-10, at 10:40, bob prohaska wrote:
>
> On Fri, Jul 09, 2021 at 05:12:57PM -0700, Mark Millard wrote:
>> On 2021-Jul-9, at 16:07, bob prohaska wrote:
> [big snip]
>
>
>
>>> Just to be clear, after updating kernel and world I gather the
>>> suggestion is to repeat
>>>
>>> # cd
On 2021-Jul-9, at 16:07, bob prohaska wrote:
> On Fri, Jul 09, 2021 at 12:46:47PM -0700, Mark Millard wrote:
>>
>> Going in different direction, when you updated:
>>
>> /usr/local/poudriere/poudriere-system
>>
>> to have Jail OSVERSION: 1400024 (and probably
>> matching the host OS main-n24759
On 2021-Jul-8, at 14:11, Mark Millard wrote:
> On 2021-Jul-8, at 10:54, bob prohaska wrote:
>
>> On Thu, Jul 08, 2021 at 09:41:13AM -0700, Mark Millard wrote:
>>>
>>>
>>> On 2021-Jul-8, at 08:45, bob prohaska wrote:
>>>
Even with -J1 and no ALLOW_MAKE_JOBS I'm still
seeing five py
On 2021-Jul-8, at 15:47, Mark Millard wrote:
> From: Tatsuki Makino wrote on
> Date: Fri, 9 Jul 2021 05:59:52 +0900 :
>
>> bob prohaska wrote on 2021/07/09 02:54:
>>> Started a new swaplog:
>>
>> Connect a USB mass storage device that you have no use for.
>> Mount the file system in it.
>>
From: Tatsuki Makino wrote on
Date: Fri, 9 Jul 2021 05:59:52 +0900 :
> bob prohaska wrote on 2021/07/09 02:54:
> > Started a new swaplog:
>
> Connect a USB mass storage device that you have no use for.
> Mount the file system in it.
> Create a file in that file system like dd if=/dev/zero of=/mn
On 2021-Jul-8, at 10:54, bob prohaska wrote:
> On Thu, Jul 08, 2021 at 09:41:13AM -0700, Mark Millard wrote:
>>
>>
>> On 2021-Jul-8, at 08:45, bob prohaska wrote:
>>
>>> Even with -J1 and no ALLOW_MAKE_JOBS I'm still
>>> seeing five pythons occupying at least 3 GB on
>>> the loose.
>>
>>
On 2021-Jul-8, at 08:45, bob prohaska wrote:
> Even with -J1 and no ALLOW_MAKE_JOBS I'm still
> seeing five pythons occupying at least 3 GB on
> the loose.
Actually I just looked and saw:
Swapinfo 7.36%
(Unlike the 83% or so I saw somewhat around 3 hours ago.)
Load Averages (220%) 2.20 2.1
On 2021-Jul-7, at 19:11, Mark Millard wrote:
> On 2021-Jul-7, at 19:04, Mark Millard wrote:
>
>> From: bob prohaska wrote on
>> Date: Wed, 7 Jul 2021 14:53:20 -0700 :
>>
>>> In trying to compile www/chromium under poudriere on a Pi3 there
>>> comes a point when five python2.7 sessions totalin
On 2021-Jul-7, at 19:04, Mark Millard wrote:
> From: bob prohaska wrote on
> Date: Wed, 7 Jul 2021 14:53:20 -0700 :
>
>> In trying to compile www/chromium under poudriere on a Pi3 there
>> comes a point when five python2.7 sessions totaling more than 2 GB
>> in size are running at once.
I s
From: bob prohaska wrote on
Date: Wed, 7 Jul 2021 14:53:20 -0700 :
> In trying to compile www/chromium under poudriere on a Pi3 there
> comes a point when five python2.7 sessions totaling more than 2 GB
> in size are running at once. Obviously, swap is swamped and the Pi3
> is running at a crawl.
On 2021-Jul-3, at 21:32, Mark Millard wrote:
> [Just correcting a bad placement of some of the new text.]
>
> On 2021-Jul-3, at 21:25, Mark Millard wrote:
>
>> On 2021-Jul-3, at 21:15, Mark Millard wrote:
>>
>>> Summary: You need to update /usr/local/poudriere/poudriere-system
>>>
>>> Upda
[Just correcting a bad placement of some of the new text.]
On 2021-Jul-3, at 21:25, Mark Millard wrote:
> On 2021-Jul-3, at 21:15, Mark Millard wrote:
>
>> Summary: You need to update /usr/local/poudriere/poudriere-system
>>
>> Updating your HOST environment does not automatically update tha
On 2021-Jul-3, at 21:15, Mark Millard wrote:
> Summary: You need to update /usr/local/poudriere/poudriere-system
>
> Updating your HOST environment does not automatically update that
> area.
>
> One possibility for an update procedure is:
>
> # cd /usr/src
> # make installworld DESTDIR=/usr
Summary: You need to update /usr/local/poudriere/poudriere-system
Updating your HOST environment does not automatically update that
area.
One possibility for an update procedure is:
# cd /usr/src
# make installworld DESTDIR=/usr/local/poudriere/poudriere-system DB_FROM_SRC=1
# make distrib-dirs
On 2021-Jul-3, at 14:54, bob prohaska wrote:
> On Sat, Jul 03, 2021 at 01:15:19PM -0700, Mark Millard wrote:
>>
>>
>>
>> So you still have not tried an artifacts or snapshot kernel+world?
>>
> Not yet.
>
>>> Eventually I resorted to running make in devel/llvm10, to my surprise it
>>> ran
On 2021-Jul-3, at 14:54, bob prohaska wrote:
> On Sat, Jul 03, 2021 at 01:15:19PM -0700, Mark Millard wrote:
>>
>>
>>
>> So you still have not tried an artifacts or snapshot kernel+world?
>>
> Not yet.
>
>>> Eventually I resorted to running make in devel/llvm10, to my surprise it
>>> ran to
On 2021-Jul-3, at 13:15, Mark Millard wrote:
> On 2021-Jul-3, at 11:25, bob prohaska wrote:
>
> On 2021-Jul-2, at 19:23, Mark Millard wrote:
>> Side note:
>>
>> It llooks like http://www.zefox.org/~bob/swaplogs/poudrierellvm10.log
>> shows that you tried with:
>>
On 2021-Jul-3, at 11:25, bob prohaska wrote:
On 2021-Jul-2, at 19:23, Mark Millard wrote:
>>>
> Side note:
>
> It llooks like http://www.zefox.org/~bob/swaplogs/poudrierellvm10.log
> shows that you tried with:
>
> Device 1K-blocks UsedAvail Cap
On 2021-Jul-3, at 01:45, Mark Millard wrote:
> On 2021-Jul-2, at 21:47, Mark Millard wrote:
>
>> On 2021-Jul-2, at 19:23, Mark Millard wrote:
>>>
>>> I just noticed that in several prior messasges I quoted the llvm-tblgen
>>> command that generates the *.inc files with the odd contents ins
On 2021-Jul-2, at 21:47, Mark Millard wrote:
> On 2021-Jul-2, at 19:23, Mark Millard wrote:
>>
>> I just noticed that in several prior messasges I quoted the llvm-tblgen
>> command that generates the *.inc files with the odd contents instead
>> of the later compile that tried to use the output
On 2021-Jul-2, at 19:21, Mark Millard wrote:
> On 2021-Jul-2, at 19:16, bob prohaska wrote:
>
>> On Fri, Jul 02, 2021 at 05:38:12PM -0700, Mark Millard wrote:
>>> From: bob prohaska wrote on
>>> Date: Fri, 2 Jul 2021 14:08:12 -0700 :
>>>
There's an option to
SAVE_WRKDIR=yes
in
• Re: llvm10 build failure on Rpi3 Mark Millard via
> freebsd-ports (Wed Jun 23 2021 - 08:34:55 UTC)
> • Re: llvm10 build failure on Rpi3 bob prohaska (Wed
> Jun 23 2021 - 17:43:38 UTC)
> • Re: llvm10 build failure on Rpi3 Mark Milla
uild failure on Rpi3 bob prohaska (Wed Jun 23 2021 - 05:09:58
UTC)
• Re: llvm10 build failure on Rpi3 Mark Millard via
freebsd-ports (Wed Jun 23 2021 - 08:34:55 UTC)
• Re: llvm10 build failure on Rpi3 bob prohaska (Wed
Jun 23 2021
On 2021-Jul-2, at 19:23, Mark Millard wrote:
>
> I just noticed that in several prior messasges I quoted the llvm-tblgen
> command that generates the *.inc files with the odd contents instead
> of the later compile that tried to use the output files in question.
>
> This leaves open the possi
http://www.zefox.org/~bob/poudriere/bulk.log shows that you had
the RPi3b (whatever variant) with the following builders (jobs)
going in parallel as of whe llvm10 reported the failure:
. . .
[00:03:20] Building 81 packages using 4 builders
. . .
[00:07:07] [04] [00:00:00] Building lang/rust | rust
I just noticed that in several prior messasges I quoted the llvm-tblgen
command that generates the *.inc files with the odd contents instead
of the later compile that tried to use the output files in question.
This leaves open the possibility that I had incorrectly checked on if
the build had fail
From: bob prohaska wrote on
Date: Fri, 2 Jul 2021 14:08:12 -0700 :
> There's an option to
> SAVE_WRKDIR=yes
> in /usr/local/etc/poudriere.conf
>
> What is its intended use?
It avoids having to remember to type -w on the
poudriere bulk command line.
Both cause a crash in the jail to produce a
On 2021-Jun-25, at 21:41, Mark Millard wrote:
>> . . .
>
> Note that system-clang just got updates for stable/11 stable/12
> stable/13 and main for a defect that prevents building
> www/chromium with a clang that has assertions enabled (a form
> of debug build contribution):
>
> The branch ma
On 2021-Jun-26, at 15:29, Mark Millard wrote:
>
> [freebsd-arm+owner at FreeBSD.org sent a notice of rejection
> of the original of the below because, according to it, I was
> not a subscriber to freebsd-arm. So this is a resend after
> (re-)subscribing. We will see if it is again rejected.]
>
>
[freebsd-arm+owner at FreeBSD.org sent a notice of rejection
of the original of the below because, according to it, I was
not a subscriber to freebsd-arm. So this is a resend after
(re-)subscribing. We will see if it is again rejected.]
On 2021-Jun-25, at 22:14, Mark Millard wrote:
> On 2021-Jun
On 2021-Jun-25, at 22:14, Mark Millard wrote:
> On 2021-Jun-25, at 20:52, bob prohaska wrote:
>
>> If you replicate the problem I'll be very pleased.
>> And just slightly relieved.
>
>
> No luck on the 1st try:
>
> [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build &&
> /wrk
On 2021-Jun-25, at 20:52, bob prohaska wrote:
> If you replicate the problem I'll be very pleased.
> And just slightly relieved.
No luck on the 1st try:
[ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build &&
/wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-i
On 2021-Jun-25, at 20:52, bob prohaska wrote:
> On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote:
> [huge snip, hope the quotes are still correct]
>>> So I'm going to suggest using an official kernel build
>>> as built by the ci.freebsd.org systems, one that is not
>>> GENERIC-MMCCAM.
On 2021-Jun-24, at 17:54, Mark Millard wrote:
> On 2021-Jun-24, at 17:16, bob prohaska wrote:
>
>> On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote:
>> [huge snip]
>>>
>>> So: Even going back to June 9 may messed up nfs
>>> use. (I've no clue what services you depend on
>>> or in w
On 2021-Jun-24, at 17:16, bob prohaska wrote:
> On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote:
> [huge snip]
>>
>> So: Even going back to June 9 may messed up nfs
>> use. (I've no clue what services you depend on
>> or in what contexts.) You might need to disable
>> nfs even tr
On 2021-Jun-24, at 09:01, bob prohaska wrote:
> [What about trying a new kernel? details at end]
> On Wed, Jun 23, 2021 at 11:02:02PM -0700, Mark Millard wrote:
>> On 2021-Jun-23, at 21:30, bob prohaska wrote:
>>
>>> On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote:
On 2021-Jun
On 2021-Jun-23, at 21:30, bob prohaska wrote:
> On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote:
>> On 2021-Jun-23, at 15:28, bob prohaska wrote:
>> . . .
>
>>
> [snipped for brevity]
>>
For example, 0xA5u byte values might be the value that newly
allocated memory is in
On 2021-Jun-23, at 18:15, Mark Millard wrote:
> On 2021-Jun-23, at 17:58, Mark Millard wrote:
>
>> Misc notes . . .
>>
>> Looking at your logs, I expect trying to build both
>> llvm10 and rust in parallel is likely to run into
>> resource issues on teh RPi3B+. For builds in that
>> context, it
On 2021-Jun-23, at 17:58, Mark Millard wrote:
> Misc notes . . .
>
> Looking at your logs, I expect trying to build both
> llvm10 and rust in parallel is likely to run into
> resource issues on teh RPi3B+. For builds in that
> context, it may be better to do something like:
>
> # poudriere buld
Misc notes . . .
Looking at your logs, I expect trying to build both
llvm10 and rust in parallel is likely to run into
resource issues on teh RPi3B+. For builds in that
context, it may be better to do something like:
# poudriere buld -j main devel/llvm10
# poudriere buld -j main lang/rust
# poudr
On 2021-Jun-23, at 15:28, bob prohaska wrote:
> On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote:
>> On 2021-Jun-23, at 10:43, bob prohaska wrote:
>>
>>> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote:
Not that it helps much, but: 2779096485 == 0xA5A5A5A5
>>
On 2021-Jun-23, at 10:43, bob prohaska wrote:
> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote:
>>
>> Not that it helps much, but: 2779096485 == 0xA5A5A5A5
>>
>> It appears that such somehow was involved-in/generated by:
>>
>> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/w
On 2021-Jun-22, at 22:09, bob prohaska wrote:
> Attempts to compile devel/llvm10 on a RPi3 under poudriere using
> poudriere bulk -J 2 -j main devel/llvm10 > bulk.log &
> are failing with:
>
> In file included from
> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUI
EDK2 fails to build via lang/gcc11-devel (or lang/gcc11). But it
turns out that EDK2 uses an external git submodule that is a
source for why.
That submodule has code that changed a header to use the newer
C variably modified types for a couple of functions but did not
change the function definitio
On 2021-Jun-15, at 02:20, Michael Gmelin wrote:
> On Tue, 15 Jun 2021 01:31:32 -0700
> Mark Millard wrote:
>
>> Michael Gmelin wrote on
>> Date: Tue, 15 Jun 2021 09:31:26 +0200 :
>>
>> On Mon, 14 Jun 2021 18:02:33 -0700
>> bob prohaska wrote:
>>>
On Mon, Jun 14, 2021 at 09:52:22PM +020
Michael Gmelin wrote on
Date: Tue, 15 Jun 2021 09:31:26 +0200 :
On Mon, 14 Jun 2021 18:02:33 -0700
bob prohaska wrote:
>
> > On Mon, Jun 14, 2021 at 09:52:22PM +0200, Michael Gmelin wrote:
> > >
> > >
> > > > On 14. Jun 2021, at 20:30, bob prohaska
> > > > wrote:
> > > >
> > > > ???On M
On 2021-Jun-14, at 12:03, Mark Millard wrote:
> bob prohaska wrote on
> Date: Mon, 14 Jun 2021 09:28:39 -0700 :
>
>> Thanks to much support on the lists it looks like poudriere _almost_
>> worked on the Pi3.
>
> I'm presuming the RPi3B+ is being used as aarch64 instead
> of armv7.
>
>> In
bob prohaska wrote on
Date: Mon, 14 Jun 2021 09:28:39 -0700 :
> Thanks to much support on the lists it looks like poudriere _almost_
> worked on the Pi3.
I'm presuming the RPi3B+ is being used as aarch64 instead
of armv7.
> In earlier tries builds of llvm10 failed from lack of memory. Restrain
On 2021-Jun-8, at 10:54, Mark Millard wrote:
>
> bob prohaska wrote on
> Date: Tue, 8 Jun 2021 07:56:24 -0700 :
>
>> Is it possible to restart a poudriere build session so it picks up
>> where it left off?
>>
>> I mistakenly hit a control-c in the controlling terminal of a long
>> build and w
bob prohaska wrote on
Date: Tue, 8 Jun 2021 07:56:24 -0700 :
> Is it possible to restart a poudriere build session so it picks up
> where it left off?
>
> I mistakenly hit a control-c in the controlling terminal of a long
> build and would like to restart it with minimum lost work.
Packages th
On 2021-Jun-5, at 04:09, Jan Beich wrote:
> Mark Millard writes:
>
>> On 2021-Jun-5, at 03:10, Jan Beich wrote:
>> It does appear that getting to all the individual-port
>> information requires going to the Server and finding
>> the matching build there. Clicking on a Build link
>> in https
On 2021-Jun-5, at 03:10, Jan Beich wrote:
> Mark Millard via freebsd-ports writes:
>
>> On 2021-Jun-4, at 22:11, Kevin Oberman wrote:
>>
>>> . . .
>>>
>>> Sorry. I now see that I was unclear, but you seem to have figured it
>>> o
On 2021-Jun-4, at 22:11, Kevin Oberman wrote:
> . . .
>
> Sorry. I now see that I was unclear, but you seem to have figured it out. I
> believe that I am aware of all of the things you mention but I can't find a
> way to track back beyond the current build, the only one marked as
> "parall
On 2021-Jun-3, at 20:05, Mark Millard wrote:
> Kevin Oberman wrote on
> Date: Thu, 3 Jun 2021 15:49:47 -0700 :
>
>> When ports were in svn, the revision caused a listing of package builds to
>> be listed in order by default, but now git hashes are used and the order
>> seems effectively rand
Kevin Oberman wrote on
Date: Thu, 3 Jun 2021 15:49:47 -0700 :
> When ports were in svn, the revision caused a listing of package builds to
> be listed in order by default, but now git hashes are used and the order
> seems effectively random. There is no column for start time and the
> elapsed ti
Ronald Klop wrote on
Date: Wed, 2 Jun 2021 16:32:58 +0200 (CEST) :
> It can take a couple of hours before the new packages are copied to the
> mirror servers.
> Your computer does not directly download the pkgs from the build servers.
http://beefy16.nyi.freebsd.org/data/latest-per-pkg/firefox/
1 - 100 of 103 matches
Mail list logo
