r migrating user files. I'm guessing this
will require a repeat of sendmail/TLS configuration. Is that right?
It's been suggested elsewhere that postfix is a better MTA these days.
I've no deep preference for sendmail, might postfix be easier, or at
least more accessibly documented?
Thank you very much!
bob prohaska
On Wed, Jul 10, 2024 at 12:02:20AM +0200, Dag-Erling Smørgrav wrote:
> bob prohaska writes:
> > It looks like all I need is SPF and TLS, [...]
>
> You also need DKIM.
>
Going by: https://support.google.com/a/answer/81126?hl=en
If I'm reading right, that requirement app
On Sun, Jul 07, 2024 at 10:14:37AM +0200, Helge Oldach wrote:
> bob prohaska wrote on Sat, 06 Jul 2024 20:09:18 +0200 (CEST):
> > What are the constraints preventing its use for receiving external mail?
> > It looks as if simply setting it to listen on port 25 will do the job.
&
On Sat, Jul 06, 2024 at 10:42:17PM +0100, Keith Gaughan wrote:
>
> The FeeBSD handbook includes some documentation on the basics of setting
> it up and how to replace DMA with a fully-featured MTA, though it uses
> Postfix as its example.
Thanks to both you and Doug for instructive r
with
gmail users. I find explicit instructions for setting up dma for this
purpose but have yet to find similar instruction for sendmail.
Thanks for reading and any guidance. Descriptions of setting up dma with
similar goals in mind would be very helpful.
bob prohaska
On Sun, Apr 14, 2024 at 03:51:37PM -0400, LuMiWa wrote:
> On Sun, 14 Apr 2024 10:51:53 -0700
> bob prohaska wrote:
>
> > While trying to fix mail rejection errors from grmail when using
> > sendmail I noticed that the man page for mailwrapper ends with:
> >
While trying to fix mail rejection errors from grmail when using sendmail
I noticed that the man page for mailwrapper ends with:
FreeBSD 14.0-RELEASE-p5October 29, 2014FreeBSD 14.0-RELEASE-p5
Looks like there's a typo somewhere on that line.
Thanks for reading,
bob prohaska
h the
base system, cyrus-sasl was installed later using pkg.
Pkg installed files in /usr/local/share containing
instructions, but those instructions required /usr/src.
Would installing sendmail via pkg get around lack of
source files?
Thanks for writing!
bob prohaska
> See pkg query %M se
zations. Might it be sufficent to run
pkg install cyrus-sasl
and accept the defaults?
Thanks for writing!
bob prohaska
case
of a binary-only installation based on freebsd-update and pkg?
Thanks for reading,
bob prohaska
;m sure it's somewhere in the docs.
Maybe cores?
Is it still true that unbound is caching-only? A DNS that's part
of FreeBSD base would be much better for me.
Thanks for everyone's help!
bob prohaska
Named.conf has so many comments it's somewhat hard to read, but in som
On Sat, Feb 17, 2024 at 07:34:14PM +0100, Moin Rahman wrote:
>
>
> > On Feb 17, 2024, at 7:26 PM, bob prohaska wrote:
> >
> > A releng/14 armv7 system using bind918 from pkg has been
snip
> > I did not adopt the convention of naming directories primary and seconda
sticking
with the old master and slave nomenclature. Could that be the culprit? I'm
hesitant
to mess with zone files that work 8-)
Any hints on where to look in the man pages would be much appreciated. I thought
there was a configuration test somewhere in the bind package but don't find it.
Thanks for reading,
bob prohaska
ory
*** Error code 1
This happens to be on a Pi4 running -current.
Is there a fix or workaround?
Can the build be restarted where it left off?
Thanks for reading,
bob prohaska
e what I was intending.
>
Ahhh, now I get it.
Thanks for writing!
bob prohaska
/obj/*" in order to force a from-scratch build
> (even if WITH_META_MODE is also later specified)? If not,
> what does "clean source tree" correspond to?
>
Again, I'm confused too. It's gone.
> The "FreeBSD" in the below is intended funny:
>
> QUOTE
> and /usr/local/etc/pkg/repos/FreeBSD.conf containing
> FreeBSD: {
> enabled: no
> }
> END QUOTE
I'm a great believer in comic relief, but it certainly
wasn't intended here. Please explain (yes, I know
explaining spoils any joke)
Thanks for all your help, and any further corrections!
bob prohaska
io
--- maninstall ---
...
Make installworld for the host system ran successfully,
which suggests there is an error in my notes. They were
prepared somewhat after the fact, so it wouldn't be a
huge surprise if a unique initial step got lost.
If you could take a look at the steps listed at
http://www.zefox.net/~fbsd/poudriere_on_rpi4
it would be much appreciated!
Thanks for reading, and all your help!
bob prohaska
quick re-run of git pull in /usr/ports reported up to date,
is there something else to try? Poudriere reports status of
stopped; crashed on the web page.
Thanks for reading,
bob prohaska
topped in /usr/ports/www/node18
I've tried git reset --hard in /usr/ports, no change.
It's unclear if this is a housekeeping problem on my
end or something larger. www/chromium has built in the
past, so the machine is up to the task.
The system is at
FreeBSD nemesis.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #73
main-2176c9ab71:
Sun Jul 2 19:24:19 PDT 2023
b...@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
Thanks for reading,
bob prohaska
comment out USE_TMPFS=yes further down in the file.
My error, last entry prevails.
Apologies for the needless noise, and many thanks for asking!
bob prohaska
>
7;s tempting to try running make in /usr/ports/devel/llvm15, just
to see if there's a difference in behavior.
Thanks for reading,
bob prohaska
On Tue, Jun 27, 2023 at 10:16:57AM -0700, bob prohaska wrote:
> On Tue, Jun 27, 2023 at 09:59:40AM -0700, Mark Millard wrote:
> > >
> > > If you want to identify system hangs, please
> > > put back:
> > >
> > > vm.swap_enabled=0
> > >
On Sat, May 06, 2023 at 12:45:55PM -0700, Mark Millard wrote:
> bob prohaska wrote on
> Date: Sat, 06 May 2023 18:43:52 UTC :
>
> > Pkg search git now reports
> > pkg: repository FreeBSD contains packages for wrong OS version:
> > FreeBSD:14:armv7
> > wh
:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
At this point -current and 14 seem likely to be quite close.
Can pkg be persuaded to install the available version as an
experiment?
Thanks for reading,
bob prohaska
le. Maybe not.
Thanks for reading, and all your help!
bob prohaska
On Wed, May 03, 2023 at 12:38:58PM -0700, Mark Millard wrote:
> bob prohaska wrote on
> Date: Wed, 03 May 2023 18:43:09 UTC :
>
> > Don't the package servers keep an old package until
> > a new one is successfully built to supercede it?
>
> That would work only
t started.
> The fix availability for main waits on the next
> build of main's latest.
Don't the package servers keep an old package until
a new one is successfully built to supercede it?
Thanks for writing!
bob prohaska
pickle?
Thanks for reading,
bob prohaska
e it beforehand, saying file not found.
It isn't obvious why administrator permissions should be needed
and I can't find a man page. It's also not obvious how to look
for readme files when using poudriere.
Thanks for reading, and any guidance!
bob prohaska
On Wed, Apr 19, 2023 at 10:51:13PM +0200, Yuri wrote:
> bob prohaska wrote:
> > It appears that installing mail/mutt erased a user account. Mutt
> > was compiled locally using poudriere and installed via pkg from the
> > local repository. After installation it was still poss
GENERIC arm
In the meantime sendmail was reinstated as the MTA. That's been done
before with no ill effects, but it was a near-simultaneous change that
might have contributed to the confusion.
I'll chalk this up to faulty wetware unless advised otherwise.
Thanks for reading,
bob prohaska
On Thu, Apr 13, 2023 at 12:21:39PM +0900, Tatsuki Makino wrote:
> bob prohaska wrote on 2023/04/13 11:18:
> > Running www/chromium (from ports via poudriere) on a Pi4
> > reports a stream of
> > [30033:1100602368:0412/190147.848068:ERROR:bus.cc(399)] Failed to connect
>
hat, if any, significance it has.
Thanks for reading,
bob prohaska
On Fri, Feb 03, 2023 at 10:25:26AM -0800, Steve Kargl wrote:
> On Fri, Feb 03, 2023 at 10:03:16AM -0800, bob prohaska wrote:
> > When trying to start inkscape on a Pi4 running -current the
> > system reports:
> > ld-elf.so.1: Shared object "libicuuc.so.70" not found,
s doesn't see it, no man page.
Can anybody see what I've done wrong? For the moment I'm rebuilding xorg.
Thanks for reading,
bob prohaska
On Sat, Dec 03, 2022 at 10:56:14AM +0100, Ronald Klop wrote:
> On 12/2/22 04:42, bob prohaska wrote:
> > While trying to build lang/gcc11 on an PPi2 (armv7) running -current
> > the process keeps stopping with:
> >
> > ===> Configuring for help2man-1.49.2
> >
contrast, a Pi3 running -current had no such problems,
a Pi3 running stable/13 got bogged down with excessive
swap use. Neither made complaints such as seen on armv7.
In case it matters, the motive is to build sysutils/u-boot-rpi2,
Thanks for reading,
bob prohaska
[sent also to ub...@freebsd.org. If that's verboten or needless
please indicate]
On Tue, Sep 27, 2022 at 08:33:33PM +0200, Klaus K??chemann wrote:
>
> > Am 27.09.2022 um 19:58 schrieb Klaus K??chemann :
> >
> >
> >> Am 27.09.2022 um 18:03 schrieb bob prohask
ne
can turn on the logging feature so as to report more errors
to the console.
Thanks for reading and replying!
bob prohaska
at forces u-boot on the
microSD card to search for usb devices again it might do
the trick for me. Or, do I misunderstand your intent?
Thanks for writing!
bob prohaska
On Sun, Sep 25, 2022 at 03:57:34PM -0700, Mark Millard wrote:
> On 2022-Sep-25, at 12:34, bob prohaska wrote:
> >
> > . . .
> >
> > IIRC I did try replacing the Sabrent enclosure with the Startech
> > enclosure, which worked and seemed to implicate the Sab
On Sun, Sep 25, 2022 at 10:39:23AM -0700, Mark Millard wrote:
> On 2022-Sep-25, at 09:05, bob prohaska wrote:
>
> > On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote:
> >>
> >> After setting initial_turbo=60 in config.txt the first reboot
> >
On Wed, Sep 21, 2022 at 06:45:00PM -0700, bob prohaska wrote:
>
> After setting initial_turbo=60 in config.txt the first reboot
> found the disk, the second did not. Running usb reset then
> found the disk, but run bootcmd_usb0 seemingly caused a reset
> that _then_ found the disk
/usr/ports/Mk/bsd.gecko.mk activity.
>
Ok, it's finaly starting to sink in..
Thank you!
bob prohaska
refox would not
> have built.
>
>
Thanks, using pkg upgrade nss fixed the problem. My puzzle
now is how the mismach developed. Firefox was built using
poudriere and installed with pkg. Shouldn't pkg install firefox
have also updated nss?
Thanks for everyone's help (and patience!)
bob prohaska
4
Thanks for reading,
bob prohaska
:21, Mark Millard wrote:
>
> > On 2021-Oct-28, at 12:16, bob prohaska wrote:
> >
> >> To make a clean start on this thread I've turned on the UART
> >> for bootcode.bin per Mark's instructions and done a few boot
> >> attempts with the US
uild u-boot-rpi2 and will try to update the USB3
disk with it once complete.
The actual boot sequence using bootcode.bin is still a bit hazy:
Is it microSD/dos -> USB/dos ->USB/freebsd ?
Thanks for reading!
bob prohaska
On Sun, Oct 24, 2021 at 08:43:32PM -0700, bob prohaska wrote:
> I've got an early Pi2B (not plus) that has been booting reliably
> from a USB2 disk connected via a USB3 hub using just bootcode.bin
> and timeout on the DOS partition of the microSD card.
>
It turns out the USB3 di
27;
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Any hints what might be wrong? I'm especially perplexed by the seemingly
successful "done" status combined with the failed dependency. The complete
log is at
http://www.zefox.net/~fbsd/rpi4/librsvg2-rust-2.50.3_5.log
Thanks for reading,
bob prohaska
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-po...@freebsd.org, bob prohaska
> Onderwerp: Re: Controlling python when building www/chromium
> >
> >
ime?
Most likely two could be accomodated, possibly three. On an 8 GB
Pi4 the five pythons coexist happily, so the behavior is probably
not considered a bug.
Thanks for reading,
bob prohaska
re finally quits and cleans up I'll give make in
www/chromium another try, as a sanity check. Perhaps something
new has gone wrong
Thanks very much for all your help!
bob prohaska
erenced by cpu.c
>>> thinlto-cache/Thin-922af5.tmp.o:(dav1d_init_cpu)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
I'll start preparing to put the machine on a public network, though it sounds
like this is a chromium problem, unrelated to FreeBSD.
Thanks for writing,
bob prohaska
reading,
bob prohaska
r a coherent/clean build context.
>
Ahh, I didn't notice that it was a timeout and thought
something serious triggered the "subcommand failed" message.
As you've guided me through poudriere I'm starting realize
it's a textile mill and my goal calls for a needle and thread.
Thank you for much patient good counsel!
bob prohaska
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 /usr/src
> > # make installw
/poudriere
poudriere jail -d main -C all
to get rid of the old jail and packages, then re-make the jail with
# poudriere ports -c -m null -M /usr/ports
# poudriere jail -c -j main -m null -M /usr/local/poudriere/poudriere-system -S
/usr/src -v 14.0-CURRENT
Have I got this right? One thing I'm hesitant about is
the -C all option.
Thanks for all your help!
bob prohaska
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.
>
> Actually
Thanks for reading!!
bob prohaska
/poudriere/data/logs/bulk/main-default/2021-07-05_14h06m26s/build.html
The last time www/chromium was compiled (using make) on this machine
I don't remember seeing such a python jam. If it happened at all the
Pi3 worked through it faster than presently.
Thanks for reading,
bob prohaska
ve changed (or just
> being missing).
>
If timestamps guide decisions on what to make and when,
that might be significant. Not sure how I might've screwed
them up, but in my hands anything is possible 8-)
> Nothing about any of those is going to change how memory
> initialization is working in llvm-tblgen's operation
> for generating any *GenGlobalISel.inc files, other than
> if the timestamp forces some sort of rebuild from scratch
> of some build dependencies first.
>
Maybe this should be obvious, but which llvm-tblgen is in
action? the one from the system, (12.0.1) or something
else?
Thanks for writing!
bob prohaska
vant is unclear to me, but it
does suggest the Pi4, even with restricted memory, won't behave like a Pi3.
Is there any sort of sanity test for the poudriere system? If I delete and
re-create the existing jail can the existing package library be preserved
and re-used? If not, that's OK, I'd just like to know beforehand.
Thanks for reading, and all your help!
bob prohaska
n terms of what it's good for.
Thanks for reading,
bob prohaska
toss
the packages created so far), delete only the jail (not
sure if that'll delete existing packages library) or
something more selective that I don't know about?
The Pi3B is purely experimental, but I'd rather not throw
away usable progress given the extreme slowness of that
progress.
Thank you!
bob prohaska
/*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2,
/*RC*//*AArch64::FPR64RegClassID: @0*/,
^
4 errors generated.
[ 25% 1396/5364]
Not sure what to try next.
Thanks for reading!
bob prohaska
[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-23, at 15:28
On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote:
> 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
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
> >>
> &g
ce that time both world and kernel have been updated
along with ports. Is it necessary or advisable to alter /usr/local/poudriere,
either by update commands or complete replacement?
Thanks for reading, and all your help!
bob prohaska
romium, which has worked
in the (distant) past using make.
Thanks for reading,
bob prohaska
e messes are cleaned up a little I'll try to make log
and config files more visible.
Thanks for your help and patience!
bob prohaska
On Mon, Jun 14, 2021 at 09:52:22PM +0200, Michael Gmelin wrote:
>
>
> > On 14. Jun 2021, at 20:30, bob prohaska wrote:
> >
> > ???On Mon, Jun 14, 2021 at 06:46:52PM +0200, Michael Gmelin wrote:
> >> On Mon, 14 Jun 2021 09:28:39 -0700
> >> What do
og
Sorry for the omission, thanks for reading!
bob prohaska
atch?
Perhaps building the offending packages individually, or in separate
jails? I've been using the same jail for all attempts so far.
Thanks for reading, and everyone's help!
bob prohaska
On Sat, Jun 12, 2021 at 01:26:16PM -0700, Jose Quinteiro wrote:
> On 6/12/21 10:57 AM, bob prohaska wrote:
> >
> > Trying it now, hoping to see parallel core use.
>
> You won't. Setting PARALLEL_JOBS=1 means exactly one Poudriere worker
> will run, and that make wi
On Sat, Jun 12, 2021 at 10:45:13AM -0700, Jose Quinteiro wrote:
> On 6/12/21 10:29 AM, bob prohaska wrote:
> > In playing with poudriere on raspberry pi 3 and 4 it seems to
> > work well on the 8 GB Pi4 but is over-optimistic on the 1 GB Pi3.
> >
> (snip)
> You might
On Sat, Jun 12, 2021 at 07:36:48PM +0200, Michael Gmelin wrote:
>
>
> > On 12. Jun 2021, at 19:31, bob prohaska wrote:
> >
> > ???In playing with poudriere on raspberry pi 3 and 4 it seems to
> > work well on the 8 GB Pi4 but is over-optimistic on the 1 GB
On Sat, Jun 12, 2021 at 07:34:22PM +0200, Matthias Andree wrote:
> Am 12.06.21 um 19:29 schrieb bob prohaska:
> > In playing with poudriere on raspberry pi 3 and 4 it seems to
> > work well on the 8 GB Pi4 but is over-optimistic on the 1 GB Pi3.
> >
> > Can poudri
ikely to help much.
Thanks for reading!
bob prohaska
On Wed, Jun 09, 2021 at 07:47:29AM +1000, Dave Horsfall wrote:
> On Tue, 8 Jun 2021, bob prohaska wrote:
>
> > More generally, can a poudriere session be gracefully stopped, say for
> > maintenance work or to run a more urgent job, and then restarted without
> > l
work or to run a more urgent job, and then
restarted without loss of intermediate work?
Thanks to Mark Millard's help it does appear that poudriere is
usable and helpful on an 8 GB pi4. The learning curve is steep!
Thanks for reading,
bob prohaska
especially to Mark!
bob prohaska
83 matches
Mail list logo