Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4

[George Mitchell]

On 5/16/21 10:19 PM, bob prohaska wrote:

[...]
I'd like to see the ports system keep working as it has in the past, but that 
seemingly
requires a kind of machine intelligence that hasn't evolved yet. Poudriere 
seems like
a brute force approach. [...]


You'll find quite a few remaining fans of portmaster.  Occasionally it
puts you in dependency hell if you don't run "pkg check -ad" and "pkg
check -aB" often enough, but I've given up on poudriere more than once.
-- George




OpenPGP_signature
Description: OpenPGP digital signature

Re: Build of Python 3.8.10/3.9.5 fails on 12.2-RELEASE

[George Mitchell]

On 5/10/21 6:49 PM, Yasuhiro Kimura wrote:

[...] I investigated repository of Python and found following commits
(bpo-43799) are the source of the problem.

[3.8] bpo-43799: OpenSSL 3.0.0: declare OPENSSL_API_COMPAT 1.1.1 (GH-25329) 
(GH-25383)
https://github.com/python/cpython/commit/b71aaa0df0f3a9640b034b4774651cd8c54d2fb9
[3.9] bpo-43799: OpenSSL 3.0.0: declare OPENSSL_API_COMPAT 1.1.1 (GH-25329) 
(GH-25382)
https://github.com/python/cpython/commit/7d9d5bf863bb0af26b74b0732ab89b2053d2fbec

I created patches to revert these commits and added them to both
ports. Then they can be built fine with 12.2-RELEASE.

---
Yasuhiro Kimura
[...]


Thank you!  This patch works for me.  -- George



OpenPGP_signature
Description: OpenPGP digital signature

I was wrong; Re: Build of Python 3.8.10/3.9.5 fails on 12.2-RELEASE

[George Mitchell]

On 5/10/21 11:46 AM, George Mitchell wrote:

On 5/10/21 11:39 AM, George Mitchell wrote:

On 5/10/21 3:29 AM, Yasuhiro Kimura wrote:
 > Hello,
 >
 > I submitted patches to update lang/python3[89] to 3.8.10/3.9.5
 > respectively.
 >
 > Bug 255729 - lang/python38: Update to 3.8.10
 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255729
 > [...]

I tried your patch on python38 and did not run into your problem --
but it appears some minor updates to the pkg-plist are needed for
installation to complete.  I'm trying to figure out what needs to
be changed. -- George


I left out this crucial detail: I'm running 12.2-RELEASE-p6 r369558.
-- George


After a more careful review of what I am seeing, I realize that both
my earlier messages were wrong, and I have exactly the same failure
that you originally reported.  Seemingly, Python-3.8.10/Modules/_ssl.c
DOES include /usr/include/openssl/ssl.h; it does NOT have
OPENSSL_NO_SSL3_METHOD defined; and therefore SSLv3_method SHOULD be
defined, allowing _ssl.c to compile.  But it doesn't, and I don't
understand why not.

tl;dr: Ignore what I said earlier.   -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Build of Python 3.8.10/3.9.5 fails on 12.2-RELEASE

[George Mitchell]

On 5/10/21 11:39 AM, George Mitchell wrote:

On 5/10/21 3:29 AM, Yasuhiro Kimura wrote:
 > Hello,
 >
 > I submitted patches to update lang/python3[89] to 3.8.10/3.9.5
 > respectively.
 >
 > Bug 255729 - lang/python38: Update to 3.8.10
 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255729
 > [...]

I tried your patch on python38 and did not run into your problem --
but it appears some minor updates to the pkg-plist are needed for
installation to complete.  I'm trying to figure out what needs to
be changed. -- George


I left out this crucial detail: I'm running 12.2-RELEASE-p6 r369558.
-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Build of Python 3.8.10/3.9.5 fails on 12.2-RELEASE

[George Mitchell]

On 5/10/21 3:29 AM, Yasuhiro Kimura wrote:
> Hello,
>
> I submitted patches to update lang/python3[89] to 3.8.10/3.9.5
> respectively.
>
> Bug 255729 - lang/python38: Update to 3.8.10
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255729
> [...]

I tried your patch on python38 and did not run into your problem --
but it appears some minor updates to the pkg-plist are needed for
installation to complete.  I'm trying to figure out what needs to
be changed. -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: SVNWEB not updated for ports

[George Mitchell]

On 4/19/21 8:42 AM, Helge Oldach wrote:

Stefan Esser wrote on Mon, 19 Apr 2021 12:11:40 +0200 (CEST):

After the switch to GIT, the ports SVN repository is in a frozen state.

This causes accesses to https://svnweb.freebsd.org/ports/head/ to return
stale information.


I guess it might be more appropriate to encourage 
https://cgit.freebsd.org/ports/?h=main instead...

Kind regards
Helge


Thank you for the hint!  For me, https://cgit.freebsd.org/ports/tree/
is more helpful, though I still haven't figured out where to find the
*date* of any commit ...  -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Begone, accursed poudriere partitions!

[George Mitchell]

On 4/7/21 2:26 PM, driesm.michi...@gmail.com wrote:

[...]
The easiest fix is to delete the zfs datasets that poudriere created.
You can find the correct dataset with
# zfs list

  And then most probably
# zfs destroy -r zroot/poudriere
[...]


Thank you for your assistance!   -- George



OpenPGP_signature
Description: OpenPGP digital signature

Begone, accursed poudriere partitions!

[George Mitchell]

On one occasion, probably a couple of years ago, I tried poudriere out.
I decided it was too heavy for my use case and uninstalled it.  Ever
since, though, every time my build machine reboots, *something*
recreates a whole poudriere tree on my ZFS file system, with a total of
ten mountpoints littering my daily report (though apparently only 139K
of actual data).  Then I have to repeat a ritual of "chflags -R noschg",
"rm -r", "zfs umount $x" for each of the mount points.

How do I stop them from coming back from the dead?-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: No update for a day on ports?

[George Mitchell]

On 4/1/21 6:04 PM, Tatsuki Makino wrote:

Dewayne Geraghty wrote on 2021/04/01 17:47:

[...]
Would appreciate if anyone can provide insight as to the 4 git commands
that I need to function, in a manner similar to the way I use svnlite
use.  Git equivalents for:

svnlite update /usr/ports
svnlite update -r '{$-$MM-$DD}' /usr/ports/$category/$port
svnlite log -l $N /usr/ports/$category/$port
svnlite diff /usr/ports/$category/$port



We have to learn by looking at such files. orz
https://git.wiki.kernel.org/index.php/File:Git-svn-cheatsheet.pdf
[...]


Thank you very much for this link!  -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Proposed ports git transition schedule

[George Mitchell]

On 3/27/21 10:20 AM, Felix Palmen wrote:

[...]  I'm talking about net/gitup, which is a little C program with
*no* dependencies and definitely no python involved. If you don't have
it in your ports tree, upgrade your ports tree.


-- while you still can, with the existing tools ...-- George




OpenPGP_signature
Description: OpenPGP digital signature

Re: Python 2.7 removal outline

[George Mitchell]

On 3/25/21 6:06 PM, Miroslav Lachman wrote:

[...]  it is really not for
everybody to use overlays in current state (overlays are poor documented 
at least).

[...]


Until this thread I had never heard of them.  -- George



OpenPGP_signature
Description: OpenPGP digital signature

Cornucopia of chromium compile warnings

[George Mitchell]

Can I safely assume that the upstream chromium developers are most
likely unaware of the MULTIPLE THOUSANDS of clang compile warnings
generated during the chromium compile phase on FreeBSD?  (I imagine
that they don't care, either.)   -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Xfce, xfce4-terminal, and UTF-8

[George Mitchell]

On 1/1/21 3:12 PM, Guido Falsi via freebsd-ports wrote:

[...]
.cshrc does not look like the correct place for it anyway. That file is 
executed multiple times during a session. I'm not sure how it can work 
for everything else. Also the fact that XFCE has it's own configuration, 
if it's not configured from there could cause conflicts.


IMHO a better place would be .xsession if using a display manager or 
Xinit if using startx.


If using XFCE as your DE it's own settings tool would be the best place.



Regardless of where I put setxkbmap, xev shows this sequence of events
when I type the compose key (Left Win), ', and e to enter "é":

KeyPress event, serial 37, synthetic NO, window 0x2e1,
 root 0x50f, subw 0x2e2, time 89630, (34,51), root:(905,493),
 state 0x10, keycode 133 (keysym 0xff20, Multi_key), same_screen YES,
 XLookupString gives 0 bytes:
 XmbLookupString gives 0 bytes:
 XFilterEvent returns: True

KeyRelease event, serial 37, synthetic NO, window 0x2e1,
 root 0x50f, subw 0x2e2, time 89758, (34,51), root:(905,493),
 state 0x10, keycode 133 (keysym 0xff20, Multi_key), same_screen YES,
 XLookupString gives 0 bytes:
 XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2e1,
 root 0x50f, subw 0x2e2, time 92574, (34,51), root:(905,493),
 state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
 XLookupString gives 1 bytes: (27) "'"
 XmbLookupString gives 1 bytes: (27) "'"
 XFilterEvent returns: True

KeyRelease event, serial 37, synthetic NO, window 0x2e1,
 root 0x50f, subw 0x2e2, time 92750, (34,51), root:(905,493),
 state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
 XLookupString gives 1 bytes: (27) "'"
 XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x2e1,
 root 0x50f, subw 0x2e2, time 98926, (34,51), root:(905,493),
 state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
 XLookupString gives 1 bytes: (65) "e"
 XmbLookupString gives 1 bytes: (65) "e"
 XFilterEvent returns: True

KeyPress event, serial 37, synthetic NO, window 0x2e1,
 root 0x50f, subw 0x2e2, time 98926, (34,51), root:(905,493),
 state 0x10, keycode 0 (keysym 0xe9, eacute), same_screen YES,
 XLookupString gives 0 bytes:
 XmbLookupString gives 1 bytes: (e9) "�"
 XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2e1,
 root 0x50f, subw 0x2e2, time 99062, (34,51), root:(905,493),
 state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
 XLookupString gives 1 bytes: (65) "e"
 XFilterEvent returns: False

The same sequence in an xfce4-terminal window shows nothing, but
any following keypresses act normally.

I removed the setxkbmap command from my .cshrc and used the XFCE
keyboard settings to set the compose key to Left Win.  Then I logged
out and back in.  I verified that the keyboard settings dialog still
showed that Left Win was used for the compose key.  But it does not
work at all.  When I type Left Win, ', e in xfce4-terminal (or in
any other client in my session), it shows 'e.  Xev shows the three
keypresses and releases but no e with acute accent.  -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Xfce, xfce4-terminal, and UTF-8

[George Mitchell]

On 1/1/21 2:57 PM, Guido Falsi via freebsd-ports wrote:

On 01/01/21 20:12, George Mitchell wrote:

I applied the patch from https://reviews.freebsd.org/D27846 to my ports
tree and recompiled with no problems.  But it did not change the compose
key behavior (still fails in xfce4-terminal but works elsewhere).


I actually have no idea. I don't know exactly how the compose key is 
managed in Xorg.


My intuition is it's Xorg itself who is managing it, intercepting the 
key presses before the application and sending it the result if any. But 
I don't know for sure.


Also maybe the setting can be per application. Have you tried 
configuring the compose key in XFCE settings?


Or setting it via command line before launching startxfce4?



I've been setting it in .csrhc (setxkbmap -option compose:lwin), and
originally worked for everything including xfce4-terminal.  It still
works for everything else (including mousepad), but not for
xfce4-terminal.  The XFCE keyboard settings compose key setting does
not seem to work for anything.-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Xfce, xfce4-terminal, and UTF-8

[George Mitchell]

I applied the patch from https://reviews.freebsd.org/D27846 to my ports
tree and recompiled with no problems.  But it did not change the compose
key behavior (still fails in xfce4-terminal but works elsewhere).
-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Xfce, xfce4-terminal, and UTF-8

[George Mitchell]

On 12/31/20 7:27 PM, Guido Falsi via freebsd-ports wrote:

[...]
Unluckily the update is now held back due to issues with some packages 
not updating correctly sometimes.


But maybe the update would solve it for you. The update is being 
worked on at [1] and [2].


BTW if you're using xfce you can configure your compose key via the 
keyboard configuration in xfce4-settings.


Also more strictly on composition, have you checked the combinations 
you are using are actually present in the list of known key 
combinations (can't recall what file that is in, sorry)


Found it, it's in /usr/local/lib/X11/locale/en_US.UTF-8/Compose, and 
here does contain the copyright symbols, as  o c (and others), 
it is working for me also in xfce4-terminal, but I'm using XFCE 4.16 
with the patches linked in the previous message.




Thanks for the pointer!  I will try this in the next couple of days
and report back when I can. -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Xfce, xfce4-terminal, and UTF-8

[George Mitchell]

On 12/31/20 3:11 PM, George Mitchell wrote:

I set LOCALE to en_US.UTF-8 and LC_CTYPE to C.  Upon login, I run
setxkbmap -option compose:lwin.  Consequently, I can enter all the
UTF-8 characters I need, such as é, ç, and even ™, into most X-based
programs I run.  When I first set this up, over a year ago, it also
worked for xfce4-terminal, but that stopped working earlier this
year.  (At this point, I can't tell you when exactly, because I
just worked around the problem with mousepad as necessary.)  Does
anyone know the correct fix for this?

Happy New Year, and let's all have a great FreeBSD-based 2021!
-- George



I guess I should have been a little more specific about the exact
failure.  I press the Compose key and two more keys, provoking no
response at all from xfce4-terminal, but any following keys act
normally.  I'm pretty sure it all worked under FBSD 11.3, and it
started to fail some time after I upgraded to 11.4 (don't quote me
on that) and hasn't worked since I upgraded to 12.1.  (By the way,
the same failure afflicts plain xterm.)-- George




OpenPGP_signature
Description: OpenPGP digital signature

Xfce, xfce4-terminal, and UTF-8

[George Mitchell]

I set LOCALE to en_US.UTF-8 and LC_CTYPE to C.  Upon login, I run
setxkbmap -option compose:lwin.  Consequently, I can enter all the
UTF-8 characters I need, such as é, ç, and even ™, into most X-based
programs I run.  When I first set this up, over a year ago, it also
worked for xfce4-terminal, but that stopped working earlier this
year.  (At this point, I can't tell you when exactly, because I
just worked around the problem with mousepad as necessary.)  Does
anyone know the correct fix for this?

Happy New Year, and let's all have a great FreeBSD-based 2021!
-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: editors/openoffice-4 compile error

[George Mitchell]

My thanks to Don Lewis for helping fix the problem.  I needed to
recompile ftp/curl with its default options (specifically, with
ALTSVC and COOKKIES set).  It's all fine now!-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: editors/openoffice-4 compile error

[George Mitchell]

On 11/30/20 1:31 AM, Don Lewis wrote:
> [...]
> Hmn, that still looks a lot like a multi-threaded build.  If you still
> have the build tree around, try this:
>
>/usr/local/bin/bash
>cd /usr/ports/editors/openoffice-4/work/aoo-4.1.8/main
>source FreeBSDAMDEnv.Set.sh
>cd ucb
>build --from ucb
> [...]

Yes!  This isolates the problem:


Checking DLL ../../../unxfbsdx.pro/lib/check_libucpftp1.so ...: ERROR: 
/usr/local/lib/libcurl.so.4: Undefined symbol "Curl_get_line"

dmake:  Error code 1, while making '../../../unxfbsdx.pro/lib/libucpftp1.so'

1 module(s):
ucb
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making 
/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/ucb/source/ucp/ftp



My installation of curl seems to be current, 7.73.0.  So now what?
Thanks for getting me this far.-- George

(Resent to correct "From:" address.)



OpenPGP_signature
Description: OpenPGP digital signature

Re: editors/openoffice-4 compile error

[George Mitchell]

On 11/28/20 7:42 PM, Kevin Oberman wrote:
Try building with MAKE_JOBS_UNSAFE and the actual problem will be at the 
end. Of course, it will take a lot longer to get to the error as you 
will only compile on a single processor thread.

[...]


https://m5p.com/public/george/single-thread-openoffice-typescript.xz

Spoiler: the end of the script doesn't look substantially different from
any previous run.  The message "Building module ucb" appears about 24%
of the way through, preceded and followed by many more "Building module"
messages, with no sign of any error having occurred.  Am I running the
right version of java?

openjdk version "1.8.0_275-internal"
OpenJDK Runtime Environment (build 1.8.0_275-internal-b01)
OpenJDK 64-Bit Server VM (build 25.275-b01, mixed mode)

This seems to be in accord with the JAVA_DEFAULT?=8 in
bsd.default-versions.mk.  I'm asking because the few actual error
messages I see anywhere in the build log seem to be javadoc
incompatibilities such as:

Constructing Javadoc information...
/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/bridge/java/XMergeBridge.java:95: 
error: unknown tag: implements

 * @implements XTypeProvider
   ^
Standard Doclet version 1.8.0_275-internal

Further suggestions appreciated ...-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: editors/openoffice-4 compile error

[George Mitchell]

On 11/28/20 7:42 PM, Kevin Oberman wrote:
Try building with MAKE_JOBS_UNSAFE and the actual problem will be at the 
end. Of course, it will take a lot longer to get to the error as you 
will only compile on a single processor thread.

[...]Trying this now; expecting results tomorrow morning.  -- George

(Resending because of wrong From: address.)



OpenPGP_signature
Description: OpenPGP digital signature

Re: editors/openoffice-4 compile error

[George Mitchell]

On 11/28/20 7:19 PM, Don Lewis wrote:

[...]
Hmn ...

The "infinite recursion" warnings have been around for a while.  They
don't seem to break the build, but have been fixed upstream for 4.2.0
whenever that gets released.  I hadn't seen the "&& with constant operand"
warning before.  It looks like a real bug, but it is also just a warning
and doesn't break the build.  I also don't see anything obvious in the
logs.

Is this repeatable?
[...]


Three times so far.-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: editors/openoffice-4 compile error

[George Mitchell]

On 11/27/20 8:29 PM, Don Lewis wrote:

[...]
What FreeBSD version and architecture?  What ports tree revision?
Anything unusual in make.conf or non-default option settings?

The package builders are not seeing this, and I'm not seeing this on my
11.4-STABLE and fairly recent 13-CURRENT builds on amd64 or i386.

The actual error is much earlier. I think the "error 65280" comes from
the perl wrapper script that builds the individual modules.  As a first
cut, try searching the log for the string "error: ".
[...]


FreeBSD 12.1-RELEASE-p10, amd64, perl5.30.  Ports at 556447.  The build
log is at https://m5p.com/public/george/openoffice-typescript.xz
The build for aoo-4.1.8/main/ucb/source/ucp/ftp, starting at line 85945,
contains a whole slew of "infinite recursion" warnings and "&& with
constant operand" warnings, but I couldn't find an actual error to save
my life (though to my eye those warnings look like actual bugs).
-- George



OpenPGP_signature
Description: OpenPGP digital signature

editors/openoffice-4 compile error

[George Mitchell]

As of ports/head revision 556447, I get the following error trying to
compile apache-openoffice:

1 module(s):
ucb
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making 
/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/ucb/source/ucp/ftp


When you have fixed the errors in that module you can resume the build 
by running:


build --from ucb

*** Error code 1

Stop.

It's reproducible, and I have a (45 MB) script of the whole build.  (I
decided not to attach it to this message.)  Googling "error 65280" seems
to lead down a rabbit hole.  Anyone have any suggestions?-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: deprecation of drm-legacy-kmod

[George Mitchell]

On 2020-08-24 18:21, Niclas Zeising wrote:
> [ cross posted across several mailing lists, please respect reply-to ]
> 
> Hi!
> 
> It is time to deprecate drm-legacy-kmod [...] it is time for it to go.
> 
> The driver will remain for a transition period.  For FreeBSD 13-CURRENT,
> this will be fairly short, as there are changes to FreeBSD base that
> breaks the drivers.  For FreeBSD 12, the driver will remain a bit
> longer, to ease in transition.  On FreeBSD 12, there is also the option
> of using the graphics drivers in base, although those are supported on a
> best-effort basis only. [...]
My secret decoder ring is telling me the implicit message here
(along with a recent Qt5 "upgrade") is that the FreeBSD home page
explicit statement that the 11.3 and 11.4 releases of FreeBSD are
in production status is a bit of a lie.  I know I'm going to have
to upgrade to 12 sooner or later, but I just don't have a warm,
fuzzy feeling about that right now.

Forgive me for venting ...-- George



signature.asc
Description: OpenPGP digital signature

Re: Incorrect PYTHON_LIBDIR setting

[George Mitchell]

On 2020-07-31 16:04, George Mitchell wrote:
> Locally, I have changed my default version of python to 3.8.
> [... etc. ...]

Apparently kib@ fixed this when I wasn't looking, and all is well
now.  Thank you!  -- George




signature.asc
Description: OpenPGP digital signature

Incorrect PYTHON_LIBDIR setting

[George Mitchell]

Locally, I have changed my default version of python to 3.8.
Specifically, in my etc/make.conf, I have:

DEFAULT_VERSIONS+=python=3.8 python3=3.8

However, www/chromium/Makefile erroneously says:

${CP} ${PYTHONBASE}/lib/python3.7/site-packages/xcbgen/*.py \
${WRKDIR}/site-packages/xcbgen

and compiling www/chromium at revision 543833 fails, because of
course I don't have the py37 version of anything installed.
I figured I could fix this by substituting ${PYTHON_LIBDIR} for
${PYTHONBASE}/lib/python3.7, but that did not change anything.
I suspect the problem is in Mk/Uses/python.mk, but I confess I
don't understand that file very well.  I'm temporarily working
around the problem by substituting "python3.8" for "python3.7"
in the Makefile, but I could use a clue on the right way to fix
the problem.  Any suggestions?   -- George



signature.asc
Description: OpenPGP digital signature

Re: Can't compile firefox (was: Can't compile rust-cbindgen)

[George Mitchell]

On 2020-07-23 17:37, George Mitchell wrote:
> On 2020-07-20 11:09, George Mitchell wrote:
>> Running on 11.3-RELEASE-p11, amd64, ports tree at 542641 (head branch).
>> For some reason, firefox depends on devel/rust-cbindgen.  I don't know
>> what that is, but it fails thus:
>> [...]
> 
> That problem has gone away with a ports tree updated to 542958*.  But
> now I have a problem compiling firefox 79.0 (which was also present in
> 78.0.2).  The build log is at https://m5p.com/failed-firefox-build.txt
> and seems to me that it is using devel/libepoll-shim without including
> "-lepoll-shim" in the link command line.  Help!  -- George
> 
> * - Mk/Uses/qt.mk, devel/qt5, and */qt5-* are at revision 541317 to
> avoid the openssl base vs ports morass.  I'm noting this for accuracy
> even though I don't think that firefox uses any qt code at all.
> 
I "fixed" this by turning on the OPTIMIZED_CFLAGS option, which I turned
off somewhere in ancient history (meaning before last Thursday, the way
my memory works).  Sorry for the noise.  I filed bug 248232 so someone
can look at this at some point. -- george



signature.asc
Description: OpenPGP digital signature

Can't compile firefox (was: Can't compile rust-cbindgen)

[George Mitchell]

On 2020-07-20 11:09, George Mitchell wrote:
> Running on 11.3-RELEASE-p11, amd64, ports tree at 542641 (head branch).
> For some reason, firefox depends on devel/rust-cbindgen.  I don't know
> what that is, but it fails thus:
> [...]

That problem has gone away with a ports tree updated to 542958*.  But
now I have a problem compiling firefox 79.0 (which was also present in
78.0.2).  The build log is at https://m5p.com/failed-firefox-build.txt
and seems to me that it is using devel/libepoll-shim without including
"-lepoll-shim" in the link command line.  Help!  -- George

* - Mk/Uses/qt.mk, devel/qt5, and */qt5-* are at revision 541317 to
avoid the openssl base vs ports morass.  I'm noting this for accuracy
even though I don't think that firefox uses any qt code at all.



signature.asc
Description: OpenPGP digital signature

Can't compile rust-cbindgen

[George Mitchell]

Running on 11.3-RELEASE-p11, amd64, ports tree at 542641 (head branch).
For some reason, firefox depends on devel/rust-cbindgen.  I don't know
what that is, but it fails thus:

===>  Configuring for rust-cbindgen-0.14.3_1
thread 'main' panicked at 'couldn't initialize the libgit2 library: -1,
error: could not initialize openssl: error:1410D0B9:SSL
routines:SSL_CTX_set_cipher_list:no cipher match',
/usr/ports/lang/rust/work/rustc-1.45.0-src/vendor/libgit2-sys/lib.rs:3672:9
stack backtrace:
   0: ::fmt
   1: core::fmt::write
   2: 
   3: 
   4: 
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: std::panicking::begin_panic_fmt
   8: 
   9: std::sync::once::Once::call_inner
  10: libgit2_sys::init
  11: git2::config::Config::open_default
  12: 
  13: cargo::ops::registry::needs_custom_http_transport
  14: 
  15: 
  16: 
  17: std::rt::lang_start_internal
  18: 
  19: 
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
*** Error code 101

Stop.
make: stopped in /usr/ports/devel/rust-cbindgen

===>>> make build failed for devel/rust-cbindgen
===>>> Aborting update


I recently had to change my ssl default from base to openssl to be
able to compile Qt5, but the above failure occurs whether I specify
DEFAULT_VERSIONS+=ssl=openssl or not.  Any clues?  -- George



signature.asc
Description: OpenPGP digital signature

Re: Can anyone build www/node right now?

[George Mitchell]

On 2020-06-28 16:07, DutchDaemon - FreeBSD Forums Administrator wrote:
> [...]
> Traceback (most recent call last):
> 
>   File "tools/genv8constants.py", line 23, in 
> 
>     bufsize=-1, stdout=subprocess.PIPE, text=True).stdout
> 
> TypeError: __init__() got an unexpected keyword argument 'text'
> [...]

You appear not to have a recent enough version of Python installed.
The "text" keyword argument to the Popen constructor was added in
Python 3.7, and it isn't available at all in Python 2.  The patch
file patch-tools_genv8constants.py in /usr/ports/www/node/files
explicitly adds a "text" keyword argument to the call to Popen.
Can you check your default version of Python?

www/node/Makefile specifies it USES=python:build, which should
probably be changed to python3 given the patch.   -- George



signature.asc
Description: OpenPGP digital signature

Re: Jumbled dependencies

[George Mitchell]

On 2020-06-14 09:10, George Mitchell wrote:
> I do package builds on one machine on my (small) network, using
> portmaster, and then distributes the built packages to my other
> machines.  Last week, I decided to make python38, rather than
> python37, my default version on Python 3.  Specifically,
> 
> portmaster -o lang/python38 python37
> 
> I think I missed a step here to upgrade all my py37-* packages to
> py38-* packages.  However, I did recompile a whole list of packages
> (specific example: vim) so that on my build machine it lists
> python38-3.8.3 as a dependency.  I build a new repo on the build
> machine and then did a "pkg upgrade" on the other machines.  This
> did install the new version of vim on the client machines, but
> "pkg info -d vim" on a client still says it depends on
> python37-3.7.7.  (And there are a pile of other packages that are
> spuriously listed as still depending on python37.)
> 
> Any suggestions as to why "pkg upgrade" did not copy correct
> dependency information from the build machine to the clients?  And
> how do I bandage up the foot I shot myself in?-- George

So I elected to fix it with a sledge hammer.  On my client machines,
I did a "pkg delete python37" while making a note of the packages
that were to be deleted.  Then I reinstalled those (changing the
"py37-" to "py38-" where needed).  Everything is fine now, except
that I have a pile of "duplicate dependency listing" messages,
which seem to be harmless.-- George




signature.asc
Description: OpenPGP digital signature

Jumbled dependencies

[George Mitchell]

I do package builds on one machine on my (small) network, using
portmaster, and then distributes the built packages to my other
machines.  Last week, I decided to make python38, rather than
python37, my default version on Python 3.  Specifically,

portmaster -o lang/python38 python37

I think I missed a step here to upgrade all my py37-* packages to
py38-* packages.  However, I did recompile a whole list of packages
(specific example: vim) so that on my build machine it lists
python38-3.8.3 as a dependency.  I build a new repo on the build
machine and then did a "pkg upgrade" on the other machines.  This
did install the new version of vim on the client machines, but
"pkg info -d vim" on a client still says it depends on
python37-3.7.7.  (And there are a pile of other packages that are
spuriously listed as still depending on python37.)

Any suggestions as to why "pkg upgrade" did not copy correct
dependency information from the build machine to the clients?  And
how do I bandage up the foot I shot myself in?-- George



signature.asc
Description: OpenPGP digital signature

Re: mail/mailman v3?

[George Mitchell]

On 2020-04-30 21:31, Julian H. Stacey wrote:
> [...]
> PS I've not the foggiest what Tauthon is , so searched
>   https://en.wikipedia.org/wiki/Special:Search?search=Tauthon&go=Go&ns0=1
>   The page "Tauthon" does not exist.
>   cd /usr/ports ; cd */*tauthon* # */*tauthon*: No match.
>   https://forums.freebsd.org/tags/tauthon/-
> [...]

I hadn't heard about it until this instant, but at a wild guess,
tau-thon would be the successor to pi-thon?  (... groan ...)
-- George



signature.asc
Description: OpenPGP digital signature

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[George Mitchell]

On 2020-04-17 20:19, Robert Huff wrote:
> 
> Dimitry Andric writes:
> 
>>  But basically, expect all python 2.x using ports to go away, unless
>>  they get fixed to use python 3.x, or no python at all.
> 
>   Is there a method whereby - given a list of installed ports using
> python 2 - one might determine which can and which cannot be upgraded
> to pythin 3?
> [...]

There's a heuristic method: run the python program "2to3" on the
file you want to asses.  It will try to replace 2.x usages with
their 3.x equivalents.  Success is not guaranteed.  (2to3 is part
of python27.)-- George



signature.asc
Description: OpenPGP digital signature

Re: sound

[George Mitchell]

On 2020-02-08 15:12, Andy Farkas wrote:
> 
> Hi, seems to be a fairly quiet weekend so...
> 
> I am building a new desktop workstation to replace my aging 8-yo one
> that has been as reliable as the sun rising every morning.
> 
> I build things using portmaster and select options that are relevant.
> 
> I'm wondering about sound options.
> 
> Do I want ALSA, PULSEAUDIO, SNDIO, other, neither, all?
> 
> I don't need "sound server support" - all I want  is to play MP3 files
> (mplayer) and watch utUbe videos. And the occasional game of warzone2000.
> 
> Thanks for any input.
> 
> -andyf
> [...]

My simple solution would be to compile multimedia/vlc with its
default settings (or alternatively multimedia/mplayer) and that
will pull in what you need -- George



signature.asc
Description: OpenPGP digital signature

Re: Portmaster failing

[George Mitchell]

On 2020-01-01 16:23, Franco Fichtner wrote:
> Hi Adam,
> 
>> On 1. Jan 2020, at 10:18 PM, Adam Weinberger  wrote:
>> [...]
>> This is why we practically beg people to use poudriere.
> 
> Let me stop you right here and say: ports Framework itself is
> suffering from this wishful attitude

PLUS UMPTEEN*!!!

> and this has nothing to do
> with readily available poudriere "replacements" which are not
> as good as poudriere for sure.

Assuming you can get poudriere to work.  Even by today's standards,
a low-cost PC is not going to have the juice to support it.  And to
reiterate, the ports framework itself MUST work standalone.

> If the ports framework isn't seen as a stand alone infrastructure
> worth its own integrity the discussion is already dead and the
> quality will keep to decline for every casual FreeBSD user who
> doesn't really care for this or that tool, but wants to install
> software from the ports tree manually.
> [...]
-- George

* umpteen: an unspecified large number



signature.asc
Description: OpenPGP digital signature

Re: Can't update qt5-gui on 11.2-RELEASE-p13

[George Mitchell]

On 2019-10-09 10:25, Alexander Leidinger via freebsd-ports wrote:
> Quoting George Mitchell  (from Wed, 9 Oct 2019
> 10:12:39 -0400):
> 
>> Apparently the definitions of various structures found in
>> /usr/local/include/mtdev.h from libmtdev-1.1.5_2 conflict with
>> the definitions /usr/include/dev/evdev/input.h from base.
>> This is in the middle of a portmaster qt5 upgrade, trying to
>> reinstall qt5-gui-5.12.2_1.  I didn't see anything in UPDATING
>> that seemed relevant.  My ports tree is at 514153.    -- George
> 
> I've run into the same error just yesterday. As a workaround, deinstall
> the devel/evdev-proto port (it's not the libmtdev port which is the
> problem) and it will use the base-system evdev includes.
> 
> Bye,
> Alexander.
> 
Problem solved!  Thanks for your help.  -- George



signature.asc
Description: OpenPGP digital signature

Can't update qt5-gui on 11.2-RELEASE-p13

[George Mitchell]

Apparently the definitions of various structures found in
/usr/local/include/mtdev.h from libmtdev-1.1.5_2 conflict with
the definitions /usr/include/dev/evdev/input.h from base.
This is in the middle of a portmaster qt5 upgrade, trying to
reinstall qt5-gui-5.12.2_1.  I didn't see anything in UPDATING
that seemed relevant.  My ports tree is at 514153.-- George


In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:27:8: error: redefinition of 'input_event'
struct input_event {
   ^
/usr/include/dev/evdev/input.h:41:8: note: previous definition is here
struct input_event {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:53:8: error: redefinition of 'input_id'
struct input_id {
   ^
/usr/include/dev/evdev/input.h:50:8: note: previous definition is here
struct input_id {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:84:8: error: redefinition of
'input_absinfo'
struct input_absinfo {
   ^
/usr/include/dev/evdev/input.h:57:8: note: previous definition is here
struct input_absinfo {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:108:8: error: redefinition of
'input_keymap_entry'
struct input_keymap_entry {
   ^
/usr/include/dev/evdev/input.h:68:8: note: previous definition is here
struct input_keymap_entry {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:300:8: error: redefinition of 'ff_replay'
struct ff_replay {
   ^
/usr/include/dev/evdev/input.h:158:8: note: previous definition is here
struct ff_replay {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:310:8: error: redefinition of 'ff_trigger'
struct ff_trigger {
   ^
/usr/include/dev/evdev/input.h:164:8: note: previous definition is here
struct ff_trigger {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:327:8: error: redefinition of 'ff_envelope'
struct ff_envelope {
   ^
/usr/include/dev/evdev/input.h:170:8: note: previous definition is here
struct ff_envelope {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:339:8: error: redefinition of
'ff_constant_effect'
struct ff_constant_effect {
   ^
/usr/include/dev/evdev/input.h:177:8: note: previous definition is here
struct ff_constant_effect {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:350:8: error: redefinition of
'ff_ramp_effect'
struct ff_ramp_effect {
   ^
/usr/include/dev/evdev/input.h:182:8: note: previous definition is here
struct ff_ramp_effect {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:366:8: error: redefinition of
'ff_condition_effect'
struct ff_condition_effect {
   ^
/usr/include/dev/evdev/input.h:188:8: note: previous definition is here
struct ff_condition_effect {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:395:8: error: redefinition of
'ff_periodic_effect'
struct ff_periodic_effect {
   ^
/usr/include/dev/evdev/input.h:215:8: note: previous definition is here
struct ff_periodic_effect {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:416:8: error: redefinition of
'ff_rumble_effect'
struct ff_rumble_effect {
   ^
/usr/include/dev/evdev/input.h:226:8: note: previous definition is here
struct ff_rumble_effect {
   ^
In file included from evdevtouch/qevdevtouchhandler.cpp:62:
In file included from /usr/local/include/mtdev.h:36:
/usr/local/include/linux/input.h:444:8: error: redefinition of 'ff_effect'
struct ff_effect {
   ^
/usr/include/dev/evdev/input.h:247:8: note: previous definition is here
struct ff_effect {
   ^
13 errors generated.
*** [.obj/qevdevtouchhandler.o] Error code 1

make[3]: stopped in
/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport/input
1 error

make[3]: stopped in
/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.13.0/src/platformsupport/

Re: Debug version of firefox

[George Mitchell]

On 2019-05-06 04:33, Michael Zhilin wrote:
> Hi,
> 
> pstack shows firefox methods for example:
> [...]

Thanks for the suggestion, but in practice I get:


(core file "firefox.core"): /usr/local/bin/firefox
- thread -1 (running) -
 0x80208d47a  (11b76432, 8, , 0, 400, 0)
 0x811b76432  (123d1745, 8, 2363898, 8, 12b59ae5, 0)
 0x8123d1745  (1da9954, 8, 0, 7fff, 1, 0)
 0x801da9954  (1da8eb2, 8, 123d15f0, 8, 51, 0)
 0x801da8eb2  (e193, 7fff, 1da8d70, 8, 0, 0)
 0x7fffe193  (e8b2f6c, 8, df109810, 7fff, e91ac4e, 8)
 0x80e8b2f6c  (e91ac4e, 8, 21af9f40, 8, 1e9aab58, 8)
 0x80e91ac4e  (e94c63d, 8, 0, 0, 0, 1)
 0x80e94c63d  (e91e30e, 8, 1435ff20, 8, 1e9aab58, 8)
 0x80e91e30e  (e91e182, 8, df109910, 7fff, 2078374, 4)
 0x80e91e182  (e9230f5, 8, 1e9aab50, 8, 27efbb88, 8)
 0x80e9230f5  (e9229c9, 8, df1099e0, 7fff, 23e5a, 11)
 0x80e9229c9  (e94c9ae, 8, df109a30, 7fff, 21073f1, 18)
 0x80e94c9ae  (e925a7c, 8, 27efbb88, 8, df109aa0, 7fff)
 0x80e925a7c  (ea0a84b, 8, df109bf0, 7fff, e95b405, 0)
 0x80ea0a84b  (e8aee92, 8, 1, 0, 21b2aa00, 8)
 0x80e8aee92  (e8adddc, 8, df109c90, 7fff, 2533f738, 8)
 0x80e8adddc  (e8ae95e, 8, 27efbb40, 8, df109e40, 7fff)
 0x80e8ae95e  (e873d35, 8, 20a4f000, 8, df109e40, 7fff)
 0x80e873d35  (e87404b, 8, 0, 0, 0, 0)
 0x80e87404b  (e874881, 8, 236b200, 8, 21ad7f88, 8)
 0x80e874881  (e873748, 8, 21eb27b0, 8, 1, 0)
 0x80e873748  (e889cf5, 8, 0, 0, 0, 0)
 0x80e889cf5  (e879f2a, 8, df109ff0, 7fff, 1da3c06, 8)
 0x80e879f2a  (1da3c06, 8, 0, 0, 0, 0)
 0x801da3c06  (0, 0)

-- George



signature.asc
Description: OpenPGP digital signature

Re: Debug version of firefox

[George Mitchell]

On 2019-05-06 00:49, Robert Huff wrote:
> [...]
>   Has anyone asked the maintainer, which I believe is
> "ge...@freebsd.org"?
> [...]

I have done so now; thanks!-- George



signature.asc
Description: OpenPGP digital signature

Debug version of firefox

[George Mitchell]

I tried compiling a debugging version of firefox:

cd /usr/ports/www/firefox; make clean; make WITH_DEBUG=yes install

The resulting binary had no debug symbols.  What did I do wrong?
-- George



signature.asc
Description: OpenPGP digital signature

Re: make delete-old-libs is your friend

[George Mitchell]

On 4/14/19 9:07 PM, Adam Weinberger wrote:
> On Sun, Apr 14, 2019 at 6:26 PM George Mitchell  
> wrote:
>>
>> But I forgot that, and ended up with both /lib/libreadline.so.8
>> AND /usr/local/lib/libreadline.so.8 on my machine, leading to woe
>> when compiling the latest lang/python36.  Unfortunately, the base
>> version readline was quite a bit older than the one from ports.
>>
>> Nevertheless, the ports version is explicitly linked as
>> libreadline.so.8, the same as the old base version, so python36
>> tried linking to the base version and failed because it did not
>> contain the new(ish) function rl_callback_sigcleanup.
>>
>> There's no question I shot myself in the foot by not deleting
>> the old libraries (an omission I have now remedied after a fair
>> amount of thrashing around to see what was wrong), but it might
>> have made my life a little easier if the port devel/readline
>> linked itself as libreadline.so.9 instead of 8.  Is there a
>> recommended practice (or should there be one) to change the .so
>> version when simultaneously moving a base library to ports and a
>> new version?   -- George
> 
> libreadline.so is at version 8 because the current readline is 8.0.
> libreadline.so.9 won't come until readline-9.0 is released. We really
> can't deviate from that, because it'd still be v8 software; it'd be
> like AT&T's ridiculous claim that they invented 5G by discovering the
> number 5.
> 
> # Adam
> 
> 
You leave me no choice but to rail at whoever allowed "v4" readline
to be installed as /lib/libreadline.so.8 back when it was in base.
(I'd rather rail at that person than have to face my own omission.)
-- George



signature.asc
Description: OpenPGP digital signature

make delete-old-libs is your friend

[George Mitchell]

But I forgot that, and ended up with both /lib/libreadline.so.8
AND /usr/local/lib/libreadline.so.8 on my machine, leading to woe
when compiling the latest lang/python36.  Unfortunately, the base
version readline was quite a bit older than the one from ports.

Nevertheless, the ports version is explicitly linked as
libreadline.so.8, the same as the old base version, so python36
tried linking to the base version and failed because it did not
contain the new(ish) function rl_callback_sigcleanup.

There's no question I shot myself in the foot by not deleting
the old libraries (an omission I have now remedied after a fair
amount of thrashing around to see what was wrong), but it might
have made my life a little easier if the port devel/readline
linked itself as libreadline.so.9 instead of 8.  Is there a
recommended practice (or should there be one) to change the .so
version when simultaneously moving a base library to ports and a
new version?   -- George



signature.asc
Description: OpenPGP digital signature

Re: Clang crash compiling qt5

[George Mitchell]

On 2019-04-10 15:42, Dimitry Andric wrote:
> On 10 Apr 2019, at 21:29, George Mitchell  wrote:
>>
>> On 2019-04-10 15:11, Dimitry Andric wrote:
>>>[...]
>>> I don't see any crash report(s) in the typescript?  Did clang drop two
>>> files (a .sh and preprocessed .c or .cpp file) in /tmp, by any chance?
>>>
>>
>> Yes, it did -- quite a few of them.  The 13 .cpp files are all
>> identical.  The .sh files are very similar but not identical.  I
>> attached one.  Running it indeed causes another core dump.  It
>> sort of looks like it happened during a configuration step.
> 
> Okay, can you create a PR and attach one .sh and .cpp file which belong
> together (they should have the same random suffix of hex digits)?  It is
> likely that we can then reproduce it independently of your particular
> setup, and without having to build qt5 and all its dependencies. :)
> 
> -Dimitry
> 
Thanks for your help!
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237185
-- George



signature.asc
Description: OpenPGP digital signature

Re: Clang crash compiling qt5

[George Mitchell]

On 2019-04-10 15:11, Dimitry Andric wrote:
> On 10 Apr 2019, at 19:37, George Mitchell  wrote:
>>
>> Yesterday I went through a round of updating and compiling ports.  By
>> all outward appearances it was successful.  But this morning's daily
>> status report revealed that clang had crashed on a signal 11 once
>> while compiling each qt5 package.  (For once, it was useful to have
>> the "such-and-such installed" messages in the system log.)  So I just
>> tried recompiling qt5-qmake just now under "script".  Sure enough,
>> there was a clang crash about 15 seconds before the end of typescript,
>> though the typescript output looks completely innocuous as far as I
>> can see, and all the qt5 packages and their dependencies seem to be
>> functional at this point.  Any idea about what's going on?
>>
>> The typescript output is at https://m5p.com/~george/typescript if
>> you think it would be helpful.-- George
> 
> Hi George,
> 
> I don't see any crash report(s) in the typescript?  Did clang drop two
> files (a .sh and preprocessed .c or .cpp file) in /tmp, by any chance?
> 

Yes, it did -- quite a few of them.  The 13 .cpp files are all
identical.  The .sh files are very similar but not identical.  I
attached one.  Running it indeed causes another core dump.  It
sort of looks like it happened during a configuration step.
Explicitly running "make configure" yields this (plus another
core dump):

===>   qt5-qmake-5.12.2 depends on executable: gmake - found
===>   qt5-qmake-5.12.2 depends on package: pkgconf>=1.3.0_1 - found
===>   qt5-qmake-5.12.2 depends on file: /usr/local/bin/python3.6 - found
===>  Configuring for qt5-qmake-5.12.2
/bin/mkdir -p /usr/ports/devel/qt5-qmake/work/qtbase-everywhere-src-5.12.2
echo 'CMAKE_MODULE_TESTS = -' >
/usr/ports/devel/qt5-qmake/work/qtbase-everywhere-src-5.12.2/.qmake.cache
echo 'QMAKE_LIBDIR_FLAGS =
-L/usr/ports/devel/qt5-qmake/work/qtbase-everywhere-src-5.12.2/lib' >>
/usr/ports/devel/qt5-qmake/work/qtbase-everywhere-src-5.12.2/.qmake.cache
echo 'QMAKE_DEFAULT_LIBDIRS = /usr/local/lib' >>
/usr/ports/devel/qt5-qmake/work/qtbase-everywhere-src-5.12.2/.qmake.cache
echo 'QMAKE_DEFAULT_INCDIRS = /usr/local/include' >>
/usr/ports/devel/qt5-qmake/work/qtbase-everywhere-src-5.12.2/.qmake.cache
Creating qmake...

> If you are using a stable branch, clang will not have been built with
> assertions, and that can lead to crashes in some cases.  You could try
> commenting out the -DNDEBUG line in lib/clang/llvm.build.mk, and then
> rebuilding and reinstalling world.  Then try the port again.
> 
> -Dimitry
> 

Gosh, I cravenly confess to a lack of enthusiasm for doing this.
My self-serving excuse is that no packages outside qt5 exhibited
this problem, and even qt5 superficially appears to be okay ...
-- George


signature.asc
Description: OpenPGP digital signature

Clang crash compiling qt5

[George Mitchell]

Yesterday I went through a round of updating and compiling ports.  By
all outward appearances it was successful.  But this morning's daily
status report revealed that clang had crashed on a signal 11 once
while compiling each qt5 package.  (For once, it was useful to have
the "such-and-such installed" messages in the system log.)  So I just
tried recompiling qt5-qmake just now under "script".  Sure enough,
there was a clang crash about 15 seconds before the end of typescript,
though the typescript output looks completely innocuous as far as I
can see, and all the qt5 packages and their dependencies seem to be
functional at this point.  Any idea about what's going on?

The typescript output is at https://m5p.com/~george/typescript if
you think it would be helpful.-- George



signature.asc
Description: OpenPGP digital signature

Re: thunderbird build error

[George Mitchell]

On 12/16/18 5:24 PM, Stefan Esser wrote:
> [...]
> I have (my version of) portmaster mostly working in a clean chroot jail.
> It is still a pure shell script (works with the FreeBSD /bin/sh and bash),
> thus portable to all architectures supported by FreeBSD (e.g. ARM).
> 
> There are a few edge cases that need further work, but my version does
> already support 4 build modes:
> 
> 1) direct build ("classic portmaster mode")
> 
> 2) delayed installation (only BUILD_DEPENDS are immediately installed,
>all other ports are installed or upgraded from saved packages at the
>end of the portmaster run)
> 
> 3) jailed build (everything is built in a chroot jail and installed after
>all builds have finished, except for pure build dependencies, which are
>only kept as packages for use in the next portmaster run)
> 
> 4) repository mode (packages are saved and at the end the repository files
>are updated to allow local and remote upgrades with "pkg upgrade")
> [...]
> My goal is to have portmaster build everything, but with some restrictions
> compared to poudriere (only for the architecture and release of the base
> system) and with the option to use the direct mode for simple cases and
> jailed builds (which require extra disk space for the chroot jail) in case
> the builds need to be performed in a clean environment.
> 
> Regards, STefan
> [...]

Wow!  I've been using "classic" mode and I didn't even realize the
new modes were there.  THANK YOU for all your fine work!   -- George



signature.asc
Description: OpenPGP digital signature

Re: thunderbird build error

[George Mitchell]

On 12/15/18 1:10 PM, George Mitchell wrote:
> I recently updated my port build machine to 11.2-RELEASE.  I'm in the
> process of recompiling my (previously) 10.4-based ports to 11.2, and
> perhaps I shouldn't be trying to do this incrementally.  [...]

Sure enough, deleting all ports and starting on a fresh ports tree
fixed this problem.  But I'm still unable to get the Powder Keg set
up on my machine (and I'm still happy with portmaster anyway).
-- George



signature.asc
Description: OpenPGP digital signature

thunderbird build error

[George Mitchell]

I recently updated my port build machine to 11.2-RELEASE.  I'm in the
process of recompiling my (previously) 10.4-based ports to 11.2, and
perhaps I shouldn't be trying to do this incrementally.  But the build
for thunderbird fails at ports revision 487523 with MAKE_JOBS_UNSAFE in
/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust
thus:

gmake[1]: Entering directory
'/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust'
gmake[1]: Nothing to be done for 'pre-export'.
gmake[1]: Leaving directory
'/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust'
gmake[1]: Entering directory
'/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust'
gmake[1]: Nothing to be done for 'export'.
gmake[1]: Leaving directory
'/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust'
gmake[1]: Entering directory
'/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust'
force-cargo-library-build
env   RUSTC_BOOTSTRAP=1 RUSTFLAGS='-C opt-level=2 '
CARGO_TARGET_DIR=/usr/ports/mail/thunderbird/work/.build/toolkit/library
RUSTC=/usr/local/bin/rustc
MOZ_SRC=/usr/ports/mail/thunderbird/work/thunderbird-60.4.0
MOZ_DIST=/usr/ports/mail/thunderbird/work/.build/di
st LIBCLANG_PATH="/usr/local/llvm70/lib"
CLANG_PATH="/usr/local/llvm70/bin/clang" PKG_CONFIG_ALLOW_CROSS=1
RUST_BACKTRACE=full
MOZ_TOPOBJDIR=/usr/ports/mail/thunderbird/work/.build
MOZ_CARGO_WRAP_LDFLAGS="-pthread -Wl,--as-needed -B/usr/local/bin
-Wl,-z,noexecsta
ck -Wl,-z,text -Wl,-z,relro -Wl,--build-id
-Wl,-rpath-link,/usr/ports/mail/thunderbird/work/.build/dist/bin
-Wl,-rpath-link,/usr/local/lib" MOZ_CARGO_WRAP_LD="
/usr/local/bin/clang70 -std=gnu99"
CARGO_TARGET_X86_64_UNKNOWN_FREEBSD_LINKER=/usr/ports/mail/thunderbir
d/work/thunderbird-60.4.0/build/cargo-linker /usr/local/bin/cargo rustc
--release --frozen --manifest-path
/usr/ports/mail/thunderbird/work/thunderbird-60.4.0/toolkit/library/rust/Cargo.toml
--lib --target=x86_64-unknown-freebsd --features "servo bindgen quantum_
render simd-accel no-static-ideograph-encoder-tables" --  -C lto
   Compiling style v0.0.1
(/usr/ports/mail/thunderbird/work/thunderbird-60.4.0/servo/components/style)

d-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=build.rs
cargo:out_dir=/usr/ports/mail/thunderbird/work/.build/toolkit/library/x86_64-unknown-freebsd/release/build/style-0c712cf90ff81f55/out
cargo:rerun-if-changed=properties/properties.mako.rs
cargo:rerun-if-changed=properties/Mako-0.9.1.zip
cargo:rerun-if-changed=properties/computed_value_flags.rs
cargo:rerun-if-changed=properties/gecko.mako.rs
cargo:rerun-if-changed=properties/helpers/animated_properties.mako.rs
cargo:rerun-if-changed=properties/data.py
cargo:rerun-if-changed=properties/helpers.mako.rs
cargo:rerun-if-changed=properties/shorthand/border.mako.rs
cargo:rerun-if-changed=properties/shorthand/margin.mako.rs
cargo:rerun-if-changed=properties/shorthand/serialize.mako.rs
cargo:rerun-if-changed=properties/shorthand/mask.mako.rs
cargo:rerun-if-changed=properties/shorthand/background.mako.rs
cargo:rerun-if-changed=properties/shorthand/column.mako.rs
cargo:rerun-if-changed=properties/shorthand/font.mako.rs
cargo:rerun-if-changed=properties/shorthand/inherited_text.mako.rs
cargo:rerun-if-changed=properties/shorthand/text.mako.rs
cargo:rerun-if-changed=properties/shorthand/box.mako.rs
cargo:rerun-if-changed=properties/shorthand/inherited_svg.mako.rs
cargo:rerun-if-changed=properties/shorthand/padding.mako.rs
cargo:rerun-if-changed=properties/shorthand/outline.mako.rs
cargo:rerun-if-changed=properties/shorthand/list.mako.rs
cargo:rerun-if-changed=properties/shorthand/position.mako.rs
cargo:rerun-if-changed=properties/declaration_block.rs
cargo:rerun-if-changed=properties/properties.html.mako
cargo:rerun-if-changed=properties/longhand/border.mako.rs
cargo:rerun-if-changed=properties/longhand/margin.mako.rs
cargo:rerun-if-changed=properties/longhand/pointing.mako.rs
cargo:rerun-if-changed=properties/longhand/background.mako.rs
cargo:rerun-if-changed=properties/longhand/counters.mako.rs
cargo:rerun-if-changed=properties/longhand/column.mako.rs
cargo:rerun-if-changed=properties/longhand/font.mako.rs
cargo:rerun-if-changed=properties/longhand/inherited_text.mako.rs
cargo:rerun-if-changed=properties/longhand/inherited_box.mako.rs
cargo:rerun-if-changed=properties/longhand/text.mako.rs
cargo:rerun-if-changed=properties/longhand/box.mako.rs
cargo:rerun-if-changed=properties/longhand/svg.mako.rs
cargo:rerun-if-changed=properties/longhand/inherited_svg.mako.rs
cargo:rerun-if-changed=properties/longhand/padding.mako.rs
cargo:rerun-if-changed=properties/longhand/outline.mako.rs
cargo:rerun-if-changed=properties/longhand/color.mako.rs
cargo:rerun-if-changed=properties/longhand/list.mako.rs
cargo:rerun-if-changed=properties/longhand/table.mako.rs
cargo:rerun-if-changed=properties/longhand/position.mako.rs
cargo:rerun-if-changed=properties/longhand/inherited_table.mako.rs
cargo:rerun-if-changed=properties/longhand/ui.mako.rs
cargo:rerun-if-c

Re: A potential new porter seeking some clarifications

[George Mitchell]

On 12/13/18 10:06 AM, Matthew Seaman wrote:
> [...] So long as you have sufficient disk space
> and you aren't trying to rebuild the entire ports tree, it can work well
> on a very ordinary desktop machine. [...]

Still getting used to the idea that a machine with >16GB would today
be considered a "very ordinary desktop machine."  -- Decrepit old George



signature.asc
Description: OpenPGP digital signature

Re: setting port options for multiple ports

[George Mitchell]

On 07/30/18 07:02, blubee blubeeme wrote:
> I am working on a port that requires many other ports to be built with
> specific options selected.
> 
> Is there any way to have a port enables options in it's dependencies?
> 
> Best,
> Owen
> [...]

If the port you need offers the option as a flavor, then I think you
can specify that flavor of the port (though it would probably conflict
with a different flavor of that port if it is installed).-- George



signature.asc
Description: OpenPGP digital signature

Re: 'make clean' seemingly broken with FLAVORS

[George Mitchell]

On 01/29/18 07:31, Mathieu Arnold wrote:
> [...]
> Mmmm, maybe make clean with the default flavor could clean all flavors.
> 

Sorry to jump in when I probably don't know what I'm talking about,
but I hope we would distinguish here between "no flavor specified"
and "default flavor specified." -- George



signature.asc
Description: OpenPGP digital signature

Re: Thanks!

[George Mitchell]

On 01/01/18 13:33, Jos Chrispijn wrote:
> I would like to thank all programmers and port maintainers for their
> excellent work in 2017.
> Without you we would never enjoy BSD as we do until this very day.
> 
> I really hope that you will keep up the good work in 2018 also!
> 
> Thanks,
> Jos Chrispijn
> [...]

And an enthusiastic second from me!  Especially because portmaster
has been revived and I can still keep up with security updates.
-- George



signature.asc
Description: OpenPGP digital signature

Re: Procmail Vulnerabilities check

[George Mitchell]

On 12/09/17 00:42, Chris H wrote:
> [...] So I'd like to respectfully request that Sendmail stays.
> All those in favor, say aye!
> [...]

  A   Y   Y E !
 A A   Y Y  E !
A   Y   EEE   !
A   A   Y   E
A   A   Y   E !  -- George



signature.asc
Description: OpenPGP digital signature

Debugging a crash

[George Mitchell]

FreeBSD 10.3-RELEASE-p24
FreeBSD clang version 3.4.1 (from base)
GNU gdb 6.1.1 (from base)
I'm trying to debug a crash in the multimedia/tvheadend 4.2.3 server on
the above system when playing a recorded program on tvheadend's Android
client.  It reliably crashes when I try to fast forward.  But if I run
the server under gdb to catch the SIGSEGV, the stack is complete trash.
Even if I try to single-step through the top level of main(), gdb acts
unhappy (though before starting the program I can at least list the
source, having specified "directory /usr/ports/").  Should base gdb
be able to debug base clang binaries?  Do I need clang from ports? or
gdb from ports?  Does devel/lldb38 work better?  Thanks from this
prospective cord-cutter for any help.  -- George



signature.asc
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[George Mitchell]

On 12/05/17 02:35, Stefan Esser wrote:
> [...]
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?
> 
> Regards, STefan
> [...]
One vote here for dropping old package support.-- George



signature.asc
Description: OpenPGP digital signature

Re: Last flavorless revision?

[George Mitchell]

On 12/05/17 03:13, Mathieu Arnold wrote:
> Le 04/12/2017 à 18:33, Steve Kargl a écrit :
>> [...]
>> This does not document the change in ports/UPDATING.  FreeBSD
>> users have been told to check {src/ports}/UPDATING for 20+
>> years.  A change that fundamentally changes the way users 
>> interact with ports/ should document.
> 
> 
> This did not change anything for the users, so there was nothing in
> UPDATING.
I think there is some cognitive dissonance here on who the users are.
I would be astonished if any end user of a FreeBSD system had ever
read the contents of /usr/ports/UPDATING except for the system
administrator, and administrators are definitely affected (to say
the least).   -- George



signature.asc
Description: OpenPGP digital signature

Getting off topic (Re: portmaster, portupgrade, etc)

[George Mitchell]

On 10/06/17 04:20, Baptiste Daroussin wrote:
> On Fri, Oct 06, 2017 at 08:13:42AM +, Steve Kargl wrote:
>> On Fri, Oct 06, 2017 at 09:41:28AM +0200, Baptiste Daroussin wrote:
>>> On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
 On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
>
> Poudriere really needs its own small book. Yes, you can do simple
> poudriere installs, but once you start covering it properly the docs
> quickly expand. My notes alone are longer than my af3e chapter
> limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> 2018).

 Please include a discussion on how to use poudriere on
 a system with limited resouces (e.g., 10 GB of free
 diskspace and less than 1 GB free memory).  I know
 portmaster works well [1] within an environment with
 only 4 GB free diskspace and 1 GB memory.

 [1] portmaster worked well prior to portmgr's decision
 to displace simple small tools in favor of a sledge
 hammer.
>>>
>>> FUD.. portmgr never took any decision like this.
>>> The problem with portmaster (beside some design flows regarding
>>> the "not build in a clean room") is that it is not maintained anymore.
>>> (Note that it has never been maintained by portmgr at all).
>>
>> I'm well aware of Doug Barton's history with FreeBSD.  You
>> can paint it with whatever color you want.
>>
>> If you (and other poudriere) contributors stated that flavors/subpackages
>> would not be supported by poudriere, would flavors/subpackages been
>> wedged into the ports build infrastructure?
> 
> Yes because if you look at mailing lists etc, you ould have figured out that
> this is the number one feature requested in the ports tree for years.
> 
> Also yes we would have make sure that the tools used to build official 
> packages
> would have worked with it, prior poudriere it was tinderbox.
> 
> And again we are giving time (and warning in advance) for all the tools to 
> catch
> up!
> 
> Best regards,
> Bapt
> 
Speaking solely for myself, I am more than pleased by all the work
Baptiste and fellow developers have put into the ports infrastructure.
THANK YOU!  But also, portmaster is a life saver for me with my 4GB
build machine, so I hope I can participate in reviving it.  -- George



signature.asc
Description: OpenPGP digital signature

Re: portmaster, portupgrade, etc

[George Mitchell]

On 10/05/17 18:13, Adam Weinberger wrote:
>> [...]
>> Seem a reasonable request? If [found] so, I'll solicit for qualified
>> individuals to work with me on it in a new thread.
>>
>> Thanks for your time, and consideration
> 
> [...]
> Let me know what you need. I'll give you whatever support I can.
> 
> # Adam
> 
> 
I'll second that.-- George (old fart w/50 years software experience)




signature.asc
Description: OpenPGP digital signature

Re: portmaster, portupgrade, etc

[George Mitchell]

On 10/04/17 14:14, Steve Kargl wrote:
> On Wed, Oct 04, 2017 at 10:21:26AM -0700, Freddie Cash wrote:
>> On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
>> s...@troutmask.apl.washington.edu> wrote:
>>
>>> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:

 Poudriere really needs its own small book. Yes, you can do simple
 poudriere installs, but once you start covering it properly the docs
 quickly expand. My notes alone are longer than my af3e chapter
 limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
 2018).
>>>
>>> Please include a discussion on how to use poudriere on
>>> a system with limited resouces [...]
>> ​Pretty sure the standard response will be along the lines of:​ [...]
> Some users cannot afford a 16-core, 32 GB ram, 2TB diskspace box
> to simply build ports with custom options.  [...]
While I agree with you, allow me to insert a gentle reminder that the
OP was asking only about whether to include portmaster in his book.
I suggest that he should. -- George



signature.asc
Description: OpenPGP digital signature

Re: portmaster, portupgrade, etc

[George Mitchell]

On 10/04/17 12:16, Michael W. Lucas wrote:
> Hi,
> 
> I'm doing tech edits on the new edition of "Absolute FreeBSD," and
> stumbled into what's apparently a delicate topic.
> 
> Some of my reviewers are happy I included portmaster in the book.
> 
> Some reviewers beg me not to include it. [...]

It's hard to guess where things are going at the moment.  You can
count me among the happy users of portmaster; and I generally
incline toward the view that more information is better than less.
-- George



signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[George Mitchell]

On 09/26/17 10:37, George Mitchell wrote:
> On 09/26/17 10:05, Mathieu Arnold wrote:
>> [...]
>> This has been a long awaiting feature, most of the work has been done by
>> bapt, bdrewery and antoine, I am just the one actually doing the
>> announce and commit and all.
>> [...]
> What is the last SVN revision without the changes?  I just updated a
> few minutes ago and portmaster is already unable to build lang/perl5.24
> to fix a security vulnerability. -- George
> 

Empirically, 450588 seems to still work. -- George



signature.asc
Description: OpenPGP digital signature

Re: [HEADUP] FLAVORS landing.

[George Mitchell]

On 09/26/17 10:05, Mathieu Arnold wrote:
> [...]
> This has been a long awaiting feature, most of the work has been done by
> bapt, bdrewery and antoine, I am just the one actually doing the
> announce and commit and all.
> [...]
What is the last SVN revision without the changes?  I just updated a
few minutes ago and portmaster is already unable to build lang/perl5.24
to fix a security vulnerability. -- George



signature.asc
Description: OpenPGP digital signature

Re: VLC/cmake failing to build

[George Mitchell]

On 09/23/17 15:46, Kurt Buff wrote:
> All,
> 
> Upgraded from 10.3 to 11.0-RELEASE-p12
> 
> Deleted all installed ports, and am trying to reinstall them with
> portmaster, building from source, with the following command line:
>  portmaster -d --no-confirm --no-term-title --delete-packages `cat
> /root/ports.txt`
> 
> ports.txt has the following in it:
>  multimedia/vlc-qt4
>  net/wireshark
>  security/sudo
>  ports-mgmt/bsdadminscripts2
>  sysutils/coreutils
>  www/firefox
>  www/lynx
>  www/opera
>  x11-wm/xfce4
>  x11/xorg
> 
> 
> VLC is failing to build, with the following error:
>  ===>>> The dependency for devel/cmake
> seems to be handled by cmake-modules-3.8.2
> 
>  ===>>> The devel/cmake-modules port has been deleted: Deleted,
> merged into devel/cmake
>  ===>>> Aborting update
>  export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
> x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
> variable name
>  export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
> x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
> variable name
>  export: =$ devel_qt5_core multimedia_libva multimedia_libvdpau
> x11_toolkits_qt5_gui x11_toolkits_qt5_widgets x11_qt5_x11extras : bad
> variable name
> 
> 
> How do I fix this?
> 
> Kurt
> [...]
/usr/ports/UPDATING:

20170914:
  AFFECTS: users of CMake & CMake Modules
  AUTHOR: adr...@freebsd.org

  The devel/cmake-modules port has been merged into devel/cmake.

  The benefit of being able to update the modules without the binary
  is outweighed by the issues caused by having the binary out-of-sync
  with the modules.

  Users should delete the devel/cmake-modules package and then
  upgrade or reinstall devel/cmake.

  All ports have been updated to depend only on CMake.

I.e., "pkg delete cmake-modules; portmaster  devel/cmake"
-- George



signature.asc
Description: OpenPGP digital signature

Re: Spat between sqlite3 and firefox-esr

[George Mitchell]

On 08/09/17 17:49, Jan Beich wrote:
> George Mitchell  writes:
> [...]
>> ports/head -r447625
>>[...]
> See https://svnweb.freebsd.org/changeset/ports/447626
> [...]

Missed it by that much! -- George



signature.asc
Description: OpenPGP digital signature

Spat between sqlite3 and firefox-esr

[George Mitchell]

FreeBSD 10.3-RELEASE-p20
ports/head -r447625

www/firefox-esr insists that sqlite3 be compiled with SQLITE_ENABLE_FTS3

Attached patch allows compilation to complete and results in a working
firefox (though I don't it's completely correct).-- George
Index: databases/sqlite3/files/patch-Makefile.am
===
--- databases/sqlite3/files/patch-Makefile.am	(revision 447625)
+++ databases/sqlite3/files/patch-Makefile.am	(working copy)
@@ -3,7 +3,7 @@
 @@ -1,5 +1,5 @@
  
 -AM_CFLAGS = @THREADSAFE_FLAGS@ @DYNAMIC_EXTENSION_FLAGS@ @FTS5_FLAGS@ @JSON1_FLAGS@ @SESSION_FLAGS@ -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE
-+AM_CFLAGS = @THREADSAFE_FLAGS@ @DYNAMIC_EXTENSION_FLAGS@ @FTS5_FLAGS@ @JSON1_FLAGS@ @SESSION_FLAGS@
++AM_CFLAGS = @THREADSAFE_FLAGS@ @DYNAMIC_EXTENSION_FLAGS@ @FTS5_FLAGS@ @JSON1_FLAGS@ @SESSION_FLAGS@ -DSQLITE_ENABLE_FTS3
  
  lib_LTLIBRARIES = libsqlite3.la
  libsqlite3_la_SOURCES = sqlite3.c
Index: databases/sqlite3/files/patch-Makefile.in
===
--- databases/sqlite3/files/patch-Makefile.in	(revision 447625)
+++ databases/sqlite3/files/patch-Makefile.in	(working copy)
@@ -5,7 +5,7 @@
  top_builddir = @top_builddir@
  top_srcdir = @top_srcdir@
 -AM_CFLAGS = @THREADSAFE_FLAGS@ @DYNAMIC_EXTENSION_FLAGS@ @FTS5_FLAGS@ @JSON1_FLAGS@ @SESSION_FLAGS@ -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_RTREE
-+AM_CFLAGS = @THREADSAFE_FLAGS@ @DYNAMIC_EXTENSION_FLAGS@ @FTS5_FLAGS@ @JSON1_FLAGS@ @SESSION_FLAGS@
++AM_CFLAGS = @THREADSAFE_FLAGS@ @DYNAMIC_EXTENSION_FLAGS@ @FTS5_FLAGS@ @JSON1_FLAGS@ @SESSION_FLAGS@ -DSQLITE_ENABLE_FTS3
  lib_LTLIBRARIES = libsqlite3.la
  libsqlite3_la_SOURCES = sqlite3.c
  libsqlite3_la_LDFLAGS = -no-undefined -version-info 8:6:8


signature.asc
Description: OpenPGP digital signature

Re: www/libxul

[George Mitchell]

On 06/23/17 00:49, Jan Beich wrote:
> George Mitchell  writes:
> 
>> Consequently, the configure script dies at line 26248, complaining
>> that "Option, jemalloc, does not take an argument (4)".
> 
> Sorry for the bustage. It should be fixed now.
> 
> https://svnweb.freebsd.org/changeset/ports/444163
> [...]

(conks self on forehead, mutters:) "remember to check /usr/ports/Mk
for stuff that magically appears from nowhere."

Thanks for the quick fix!  It works now.   -- George



signature.asc
Description: OpenPGP digital signature

www/libxul

[George Mitchell]

At svn revision 443684.

After "make clean extract":
work/firefox-45.9.0esr/.mozconfig does not exist.
No file under www/libxul contains the string "--enable-jemalloc=4".
In particular, no patch file in the files directory refers to
.mozconfig or contains "--enable-jemalloc=4".

But after "make patch":
work/firefox-45.9.0esr/.mozconfig has been created and contains
"--enable-jemalloc=4".
Consequently, the configure script dies at line 26248, complaining
that "Option, jemalloc, does not take an argument (4)".

I'd love to propose a patch to fix this problem, but I cannot
discover for the life of me where the "--enable-jemalloc=4" came
from.  What am I missing?

If I make patch, then manually delete the line:
ac_add_options --enable-jemalloc=4
that mysteriously appeared in .mozconfig and then run configure,
all is well. -- George



signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster [and of ports-mgmt/synth]

[George Mitchell]

On 06/02/17 06:24, Jim Ohlstein wrote:
> [...]
> Sadly, it is/
> was the best option for users looking to migrate to a "modern" tool for
> whom poudriere was too much.
> 

Meaning no disrespect to anyone who makes positive contributions to
the FreeBSD project, let's not forget that synth's dependence on Ada
is not to be taken lightly either.-- George



signature.asc
Description: OpenPGP digital signature

Re: mesa libs issue

[George Mitchell]

On 05/17/17 08:00, tech lists wrote:
> [...]
> What I did was this, after seeing David's very helpful email to the
> list: 
> 
> pkg delete -f libEGL-17.0.3 libGL-17.0.3 libglesv2-17.0.3 gbm-17.0.3
> libglapi-17.0.3 dri-17.0.3.2
> [...]

More generally:

pkg delete -f libEGL libGL libglesv2 gbm libglapi dri

in case you are upgrading from a different current version.  -- George



signature.asc
Description: OpenPGP digital signature

Re: default named.conf in bind ports and slaving from f-root

[George Mitchell]

On 04/16/17 05:30, Thomas Steen Rasmussen wrote:
> On 04/16/2017 04:02 AM, George Mitchell wrote:
>> On 04/14/17 08:37, Thomas Steen Rasmussen wrote:
>>> Hello,
>>>
>>> Cloudflare deployed a bunch (74 apparently) of new f-root dns
>>> servers, which do not permit AXFR like the other f-root instances
>>> do.
>>> [...]
>>> A good alternative could be to change named.conf to use
>>> lax.xfr.dns.icann.org and iad.xfr.dns.icann.org as
>>> described in [2]. My named.conf now looks like this:
>>> [...]
>> Does this issue affect me if I use type "hint" for zone "." like this:
>>
>> zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
>>
>> -- George
>>
> Hello,
> 
> Someone else already responded, but for the record: No,
> it does not. Slaving the root zone is an alternative to using
> the hints file. The advantage is that the data is always
> uptodate. The disadvantage is stuff like this, obviously.
> [...]

Thank you, Kevin and Thomas, for confirming what I already
suspected was the case.  -- George




signature.asc
Description: OpenPGP digital signature

Re: default named.conf in bind ports and slaving from f-root

[George Mitchell]

On 04/14/17 08:37, Thomas Steen Rasmussen wrote:
> Hello,
> 
> Cloudflare deployed a bunch (74 apparently) of new f-root dns
> servers, which do not permit AXFR like the other f-root instances
> do.
> [...]
> A good alternative could be to change named.conf to use
> lax.xfr.dns.icann.org and iad.xfr.dns.icann.org as
> described in [2]. My named.conf now looks like this:
> [...]

Does this issue affect me if I use type "hint" for zone "." like this:

zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };

-- George



signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster

[George Mitchell]

On 02/17/17 02:37, abi wrote:
> 17.02.2017 00:22, Chris H пишет:
>> On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot
>>  wrote
>>
>>> [...]
>> Hello. You shouldn't have any difficulty accomplishing your goal
>> by simply setting up a jail, and using portmaster within that jail(8).
>> portmaster really doesn't care where it's run. So long as it has
>> everything it needs to accomplish it's job(s). :-)
>>
> From my point of view, jails are overkill. Chroot should be enough and
> it would be nice if portmaster starts building in clean environment.
> 
Some of us might even consider chroot overkill.  I'm fine with a
chroot option, but let's not turn portmaster into something that
unconditionally requires more resources than the underlying build
needs.  -- George




signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster

[George Mitchell]

On 02/16/17 15:33, Baho Utot wrote:
> 
> 
> On 02/16/17 14:01, Lowell Gilbert wrote:
>> Baho Utot  writes:
>>
>>> On 02/16/17 06:08, Luca Pizzamiglio wrote:
 I'm looking for constructive critics, feedbacks, anything that can
 help me to make portmaster an actively maintained and used tool.
>>>
>>> If you can have it build in a clean chroot or jail then you'll get my
>>> attention
>>
>> What kind of special support?
>>
>> I use it with a chroot that mounts /usr/ports (and src) read-only, and
>> aside from the initial base system install, it took about fifteen
>> minutes to set up.
>>
> 
> Using chroot or jails to build each individual package
> [...]

While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required.  The current non-use
of chroot/jails is, for me, a feature -- not a bug.-- George




signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster

[George Mitchell]

On 02/16/17 06:08, Luca Pizzamiglio wrote:
> Hi all,
> 
> portmaster, a tool used/loved/hated, is almost in abandoned state.
> I'm a portmaster user, because, in some cases, it fits my needs.
> In other cases, I use other tools, like poudriere or synth, that are
> really great.
> I don't want to open a discussion here about what it's better, but the
> truth is, that I use portmaster and it's not maintained.
> So I decided to spend some time to look at it and to work on it.
> 
> I forked it and I start some work.
> The plan is:
> - remove obsolete features, like the -PP option
> - remove pkg_* support (even if someone could be against it), forcing
> the usage of pkg
> - prepare the support of new features like FLAVORS and subpackages
> - adding a new ports, called portmaster-devel, for the new version
> 
> I did a branch on github working of the first two points
> (https://github.com/pizzamig/portmaster/tree/remove_oldpkg)
> 
> I'm looking for constructive critics, feedbacks, anything that can
> help me to make portmaster an actively maintained and used tool.
> 
> Thanks in advance
> 
> Best regards,
> pizzamig
> [...]
Thank you!  poudriere regularly runs out of resources on my ten
year old machine, and I've been disinclined to try synth so far
(though I guess it may come to that soon).  Up to now, portmaster
has worked fine for me (bearing in mind I have a machine dedicated
to ports building and the world doesn't end if I break it and have
to clean up and start over again on occasion).   -- George




signature.asc
Description: OpenPGP digital signature

Port management tools (was: Status of synth)

[George Mitchell]

On 02/16/17 03:44, Don Lewis wrote:
> On 16 Feb, Thomas Mueller wrote:
>>
>>> For every build -
>>> /usr/local/etc/poudriere.d/make.conf
>> 
>>> OPTIONS_SET= OPTIMIZED_CFLAGS SIMD PGSQL IPV6
>>> editors_vim_SET= CSCOPE X11 GTK3 PYTHON
> 
> Yeah, I really like this a lot more than going through all the config
> screens.  Back when I used portupgrade, I found that it was too easy to
> accidentally set some option for a port to a non-default value where it
> would persist forever. [...]

This is in a nutshell why one group of FreeBSD users love portmaster
so much.  I switched from portugrade to portmaster a long time ago
for this very reason.   -- George




signature.asc
Description: OpenPGP digital signature

Re: ports and dependency hell

[George Mitchell]

On 02/08/17 03:03, Julian Elischer wrote:
> [...]
> I'm discouraged to not hear back from any of the ports 'committee'.
> [...]
Possibly because this has been the topic of a number of rancorous
mail threads in the last few months already, and everybody is
fatigued.  What there *hasn't* been is a consensus on what to do
about it.  And with all respect perhaps that's inevitable in a
vibrant and active open-source project run entirely by volunteers.
I wish I could omnisciently propound the right thing to do(tm)
so persuasively that everybody would immediately set to work on
it.  But I can't, even in my own overactive imagination.   -- George




signature.asc
Description: OpenPGP digital signature

Re: The ports collection has some serious issues

[George Mitchell]

On 12/26/16 03:11, Thomas Mueller wrote:
> [...]
> What is the current status of portupgrade and portmaster?
> 
> Maintained, deprecated or something else?
> 
> Tom
> [...]

If "contentious" were an official state, that would be it.  Each has
its enthusiastic adherents; others are, shall we say, less enthusiastic.
-- George

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: HEADSUP: FLAVORS (initial version) and subpackages proposals

[George Mitchell]

On 12/18/16 19:31, Baptiste Daroussin wrote:
> Hi all,
> 
> I have been working for a while on 2 long standing feature request for the 
> ports
> tree: flavors and subpackages.
> [...]

Off topic, I know, but might this eventually lead to FLAVORS for base?
I would be so grateful to have a SCHED_4BSD flavor of base so I didn't
have to keep updating my machines from source every time there was a
security update.  Maybe someone can at least think about it.  -- George

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[George Mitchell]

On 12/15/16 09:40, Warren Block wrote:
> On Thu, 8 Dec 2016, Matt Smith wrote:
> 
>> On Dec 08 05:16, Daniil Berendeev wrote:
>>>
>>> Although portmaster is not releated to the FreeBSD project and is an
>>> outside tool, there aren't any alternatives from the project itself. So
>>> use it or die. Not a nice situation.
>>
>> People have been trying to get portmaster deprecated and removed from
>> the handbook but have met with resistance.
> 
> Well, yes.  Because it works, has no dependencies, and there is no
> equivalent replacement.  [...]

Warren, you have hit the nail on the head.  -- George

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Dovcot issues

[George Mitchell]

On 12/12/16 20:11, Larry Rosenman wrote:
> On 2016-12-12 18:57, The Doctor wrote:
>> On Mon, Dec 12, 2016 at 03:16:35PM -0600, Larry Rosenman wrote:
>>> On 2016-12-12 15:08, The Doctor wrote:
>>> > I am seeing issues with
>>> > Thunderbird
>>> >
>>> > IMAP and POP3
>>> >
>>> > and
>>> >
>>> > Entourage issues
>>> >
>>> > of non-deleting / repeating e-mail.
>>> >
>>> > Any one else gettting that?
>>> Not I.  Which Dovecot release?  Pigeonhole? Mailbox format?
>>
>> Dovcote 2.2.27 using mbox.
>>
> 
> Same Here, FreeBSD with no issues whatsoever.
> 

May I suggest "grep dovecot /var/log/maillog" on your server for
possibly informative messages?-- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: The ports collection has some serious issues

[George Mitchell]

On 12/08/16 09:14, Kevin P. Neal wrote:
> On Thu, Dec 08, 2016 at 01:28:02PM +0100, Baptiste Daroussin wrote:
>> On Thu, Dec 08, 2016 at 05:16:24AM +, Daniil Berendeev wrote:
>>> Hello guys!
>>> [...]
>> Have you considered using things like poudriere that would allow you to build
>> your own repository with your own set of packages and options.
> 
> Here's a +2 for poudriere.
>  [...]

I've never been able to complete a poudriere run on my build machine
without panicking because I have "only" four gigabytes of memory.  (It
is likely the machine will get more memory for Christmas, though.)  I
haven't yet had occasion to try synth.

I love portmaster.  My build machine is not a production machine, so
if the build process goes astray, I can at worst delete all ports and
rebuild them all.  And portmaster will request all options at the
beginning of the run and then quietly build away until it finishes (or
breaks).

The worst thing about ports for me is really an NP problem: FreeBSD
can't possibly test all the option combinations.  So I expect to have
to do some fine tuning on my own.   -- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: what is the purpose of the quarterly ports branches?

[George Mitchell]

On 12/06/16 21:59, Jason Unovitch wrote:
> On Mon, Dec 05, 2016 at 10:48:20PM +, Ben Woods wrote:
>> On Tue., 6 Dec. 2016 at 4:44 am, Julian Elischer  wrote:
>>
>>> they are effectively useless because the results are not archived, and
>>> the quarterly pkg branch actually changes day by day, so making two
>>> machines from the same quarterly branch can give you different
>>> machines (making it useless for paying work)
>>>
>>> not to mention that if you use the quarterly pkg branch you run he
>>> risk of it completely changing if you happen to be unlucky enough to
>>> be doing it across a quarterly boundary. then you end up with a
>>> completely messed up system. (from experience).
>>>
> 
> If you are handling the burden of support for a customer then perhaps
> Poudriere and building internally is the best option. Then if you want
> to stay on an older quarterly because none of what you deploy to
> customers is impacted by security issues you can roll them at your own
> pace.
> 
>>> But the big question still remains..
>>>
>>> What do you think you are solving and why are they changing? shouldn't
>>> a snapshot be stable?
> 
> 
> Think releng compared to stable in the src repo rather than
> release/stable.  They change in the same fashion to get SA (in the form
> of VuXML) and errata worthy fixes.
> [...]

If only!  At least the current base releng does not arbitrarily
disappear every three months. -- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FOCAL

[George Mitchell]

On 12/02/16 19:40, Dave Horsfall wrote:
> Be there an implementation of FOCAL?  I have a hankering to get back to my 
> early programming days :-)
> 
The Wikipedia page has a few links:
https://en.wikipedia.org/wiki/FOCAL_%28programming_language%29
-- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: dependency explosions

[George Mitchell]

On 10/04/16 23:18, Julian Elischer wrote:
> On 3/10/2016 5:14 AM, Mathieu Arnold wrote:
>> [...]
>> The bare minimum will never be the default.  The default is what will
>> fit most people, so that they can use our packages out of the box.
>>
> I didn't say it should be the default, I said it should be an easy to
> request option,
> (without using the config screen on each of 25000 ports)
> e.g. setting PORTS_CONFIG_MINIMUM before making everything.
> [...]

+1!   -- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ca_root_nss compile failure

[George Mitchell]

On 09/28/16 02:59, Matthias Andree wrote:
> Am 28.09.2016 um 01:51 schrieb George Mitchell:
>> Before I file a PR, does this failure look familiar to anyone?
>>
>>  portmaster -BDg security/ca_root_nss
> 
>> ===>  Building for ca_root_nss-3.26
>> ##  Untrusted certificates omitted from this bundle: 20
>> openssl x509 failed with exit code 139 at
>> /usr/ports/security/ca_root_nss/work/MAca-bundle.pl line 78.
>> *** Error code 255
> George,
> 
> thanks for asking, this is the first report I am made aware of. "exit
> code 139" is actually a signal, 128 + 11 = "core dump + SIGSEGV".
> openssl should NOT raise a SIGSEGV in ANY case, and beyond marking
> build-time conflicts perhaps, there's nothing that ca_root_nss could do
> anything about. It's a Perl script that uses the OpenSSL executable, and
> the latter crashed due to the SIGSEGV.
> 
> First, please show the output of these two commands before doing further
> upgrades:
> 
> pkg info '*ssl'
> 
> freebsd-version -u
> 
> 
> That should answer these underlying questions:
> 
> 1. Do you have openssl or libressl installed from ports?
> 
> 2. Is your base system fully patched? Note that there have been two
> OpenSSL upgrades in quick succession, and re-running "freebsd-update
> fetch" and "freebsd-update install" is advised in case you've missed the
> second one (alternatively, rebuild and reinstall OpenSSL from a
> supported releng SVN branch)
> 
> If you do not have openssl, libressl installed, and you have a supported
> fully-updated base system, then (3) start looking for hardware trouble,
> and only then we can usefully start looking into the crash, such as
> installing debug symbols for openssl and looking into backtraces.
> 
Thanks for your help.  I've just done the freebsd-update operation,
and since I have no port versions of openssl installed, I presume
that will fix the problem.  I appreciate your attention!   -- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ca_root_nss compile failure

[George Mitchell]

Thanks for the pointer!  -- George

On 09/27/16 21:39, Carlos J. Puga Medina wrote:
> I forgot to mention that this problem has been reported:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212921
> 
> El 28 de septiembre de 2016 3:20:04 CEST, George Mitchell 
>  escribió:
>> On 09/27/16 20:56, Carlos J. Puga Medina wrote:
>>> Hi George,
>>>
>>> Yes, I had the same problem like you. So you only need to define your
>>> default SSL version in /etc/make.conf
>>>
>>> See entry 20160616 in /usr/ports/UPDATING for further details.
>>>
>>> Regards,
>>>
>> Okay, /etc/make.conf now says:
>>
>> WITH_PKGNG=yes
>> DISABLE_VULNERABILITIES=yes
>> DEFAULT_VERSIONS+= linux=c6 ssl=base
>> OVERRIDE_LINUX_NONBASE_PORTS=c6
>>
>> Did I do that right?  I still get the same failure.  -- George
> 

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ca_root_nss compile failure

[George Mitchell]

On 09/27/16 20:56, Carlos J. Puga Medina wrote:
> Hi George,
> 
> Yes, I had the same problem like you. So you only need to define your
> default SSL version in /etc/make.conf
> 
> See entry 20160616 in /usr/ports/UPDATING for further details.
> 
> Regards,
> 
Okay, /etc/make.conf now says:

WITH_PKGNG=yes
DISABLE_VULNERABILITIES=yes
DEFAULT_VERSIONS+= linux=c6 ssl=base
OVERRIDE_LINUX_NONBASE_PORTS=c6

Did I do that right?  I still get the same failure.  -- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ca_root_nss compile failure

[George Mitchell]

Before I file a PR, does this failure look familiar to anyone?

 portmaster -BDg security/ca_root_nss

===>>> Port directory: /usr/ports/security/ca_root_nss

===>>> Launching 'make checksum' for security/ca_root_nss in background
===>>> Gathering dependency list for security/ca_root_nss from ports
===>>> Initial dependency check complete for security/ca_root_nss


===>>> Starting build for security/ca_root_nss <<<===

===>>> All dependencies are up to date


===>  Cleaning for ca_root_nss-3.26
===>  License MPL accepted by the user
===>  Found saved configuration for ca_root_nss-3.22.2
===>   ca_root_nss-3.26 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by ca_root_nss-3.26 for building
===>  Extracting for ca_root_nss-3.26
=> SHA256 Checksum OK for nss-3.26.tar.gz.
===>  Patching for ca_root_nss-3.26
===>   ca_root_nss-3.26 depends on package: perl5>=5.20<5.21 - found
===>  Configuring for ca_root_nss-3.26
===>  Building for ca_root_nss-3.26
##  Untrusted certificates omitted from this bundle: 20
openssl x509 failed with exit code 139 at
/usr/ports/security/ca_root_nss/work/MAca-bundle.pl line 78.
*** Error code 255

Stop.
make[1]: stopped in /usr/ports/security/ca_root_nss
*** Error code 1

Stop.
make: stopped in /usr/ports/security/ca_root_nss

===>>> make build failed for security/ca_root_nss
===>>> Aborting update


===>>> You can restart from the point of failure with this command line:
   portmaster  security/ca_root_nss


svnlite info
Path: .
Working Copy Root Path: /usr/ports
URL: svn://svnmirror/ports/head
Relative URL: ^/head
Repository Root: svn://svnmirror/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 422822
Node Kind: directory
Schedule: normal
Last Changed Author: araujo
Last Changed Rev: 422822
Last Changed Date: 2016-09-27 13:50:45 -0400 (Tue, 27 Sep 2016)

/etc/make.conf:
WITH_PKGNG=yes
DISABLE_VULNERABILITIES=yes
DEFAULT_VERSIONS+=linux=c6
OVERRIDE_LINUX_NONBASE_PORTS=c6

Thanks for your attention.-- George
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Failure compiling java/openjdk8

[George Mitchell]

On 04/28/16 07:01, Michael Jung wrote:
> [...]
> If you really want to try and build it on that system and have some free
> disk
> space you could always add a file instead of a partition as extra swap.
> 
> Instuctions here:
> 
> https://www.freebsd.org/doc/handbook/adding-swap-space.html
> 
> --mikej
> [...]

I must warn you that using "swapon " (at least on FreeBSD 8 and
earlier) was a guaranteed recipe for a panic for me.  I've been afraid
to try it any more recently.  -- George

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Removing documentation

[George Mitchell]

On 02/08/16 04:55, John Marino wrote:
> On 2/8/2016 10:30 AM, Mathias Picker wrote:
>> [...]
>> To comment on the original bug report: removing portmaster from
>> documentation seems to be a bit premature. It's working fine for me,
>> and it seems quite a lot simpler to me than synth, which makes it
>> preferable in my book.
> 
> Honestly you're the first one to say *that*.
> [...]

Then allow me to be the second.  But then, I find poudriere
unusable on my build system (I don't use ZFS and my memory is
apparently too limited).  Portmaster just does the right thing.

We get that you don't like portmaster.  So please don't use it.
But don't deprive the rest of us.  -- George

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: openoffice vulnerability?

[George Mitchell]

On 05/15/15 07:11, George Mitchell wrote:
> Nightly security report sez:
> 
> Checking for packages with security vulnerabilities:
> Database fetched: Thu May 14 03:10:05 EDT 2015
> apache-openoffice-4.1.1_9
> [...]
And now Don Lewis has removed this erroneous entry from the data base of
vulnerabilities.  Thank you, Don! -- George

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

openoffice vulnerability?

[George Mitchell]

Nightly security report sez:

Checking for packages with security vulnerabilities:
Database fetched: Thu May 14 03:10:05 EDT 2015
apache-openoffice-4.1.1_9

I first got this last week for version 4.1.1_7 and consequently updated
my ports tree and rebuilt, specifically including changeset 385792:

Add a patch to fix the HWP filter vulnerability documented in
CVE-2015-1774 and


Approved by:mat (mentor)
MFH:2015Q2
Security:   b13af778-f4fc-11e4-a95d-ac9e174be3af
Differential Revision:  https://reviews.freebsd.org/D2478


So is it still broken, or did another vulnerability already crop up?
-- George
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 3 doc?

[George Mitchell]

On 12/27/14 22:36, Shane Ambler wrote:

On 28/12/2014 11:15, George Mitchell wrote:

I have both python 2.7.8 and python 3.3.5 installed on my machine.  When
I build lang/python-doc-html, I end up with python-doc-html-2.7.8.  Is
it possible to also get python-doc-html-3.3.5 generated and installed
somehow?   -- George


There are two settings that determine the version of python being used -

DEFAULT_VERSIONS can be set in /etc/make.conf and will effect the
python version used for every port you build. This can also be used to
define other default versions, see /usr/ports/Mk/bsd.default-versions.mk

DEFAULT_VERSIONS= python=3.3

You can also set PYTHON_VERSION in your environment before building to
only effect the one port.

For csh/tcsh
setenv PYTHON_VERSION python3.3

for sh/bash
PYTHON_VERSION=python3.3;export PYTHON_VERSION



That works -- as long as I am willing to deinstall the python 2.7.8
documentation first.  I suppose I could create a package for the 2.7.8
documentation, "upgrade," and then circumvent the ports system to
reinstall the old files by hand, but I was hoping not to have to do
that.-- George
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Python 3 doc?

[George Mitchell]

I have both python 2.7.8 and python 3.3.5 installed on my machine.  When
I build lang/python-doc-html, I end up with python-doc-html-2.7.8.  Is
it possible to also get python-doc-html-3.3.5 generated and installed
somehow?   -- George
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Thanks for 2014Q4 r374273 ...

[George Mitchell]

... that got us some of our needed security updates, but firefox-esr
won't build with graphics/jpeg any more, as the configure script wants
the JCS_EXTENSIONS features from graphics/jpeg-turbo.  So I did a
"portmaster -o graphics/jpeg-turbo jpeg" and it claims to have updated
the dependencies of all installed packages.  But when I then tried to
reinstall firefox, the first thing it wanted to do was rebuild the old
version of graphics/jpeg.

How can I determine the chain of dependencies between www/firefox-esr
and graphics/jpeg, so I could patch the right package to get rid of
this dependency?-- George
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

2014Q4 security updates?

[George Mitchell]

Can we expect security updates at some point to any of these ports on
the 2014Q4 branch?

firefox-esr-31.2.0,1
flac-1.3.0_2
freetype2-2.5.3_2
libpurple-2.10.9_7
libxul-31.2.0
linux-c6-openssl-1.0.1e
nss-3.17.2
pidgin-2.10.9_4
thunderbird-31.2.0

Thanks for your attention.  -- George
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Python 2.7 and semaphores

[George Mitchell]

On 10/25/14 18:16, Henry Hu wrote:

On Sat, Oct 25, 2014 at 2:38 PM, George Mitchell 
wrote:


In the process of building and trying textproc/meld, I discovered that
the lang/python27 configure process concludes, erroneously, that FreeBSD
does not support working Posix semaphores.  [...]
Can anyone explain to me how those lines affect the configure process?
And does either line belong in the Makefile at this point?-- George



There is a config option called "SEM" which enables Posix sem support.
By default it is enabled.


Thanks for the explanation.  I must have turned the option off at some
point in the past, but I don't remember doing it.-- George

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"