I thought "pkg updating" would alert me about python...?

[David Wolfskill]

I just re-verified the behavior, so -- even though I have already
started taking evasive action (updating python), I figured it may be of
use to show what I'm seeing; maybe I'm confused:

Local ports tree is updated; previous ports update was a week ago.  I
happen to know that there's an UPDATING entry:

lgld-dhw(12.2-S)[4] tail +16 /usr/ports/UPDATING | head -5
20210425:
  AFFECTS: users of python
  AUTHOR: k...@freebsd.org

  The default version of python3 and python was switched to 3.8.


And that this machine should be affected:

lgld-dhw(12.2-S)[5] pkg info -o python\*
python27-2.7.18_1  lang/python27
python36-3.6.13lang/python36
python38-3.8.9 lang/python38


[As noted above, I had already started evasive action.]

But "pkg updating" is not actually showing the above entry:

lgld-dhw(12.2-S)[6] pkg updating -d 20210424
lgld-dhw(12.2-S)[7] echo $?
0


Am I alone in expecting "pkg updating" to have displayed the 20210425
entry?

(There was an issue a while back, where "pkg updating" was not showing
"glob" entries, but that has since been addressed.)

This is on a machine running stable/12:

lgld-dhw(12.2-S)[8] uname -a
FreeBSD lgld-dhw.corp.example.com 12.2-STABLE FreeBSD 12.2-STABLE #21 
stable/12-n233048-23a3c3d97d72: Sun May  2 04:43:57 PDT 2021 
r...@lgld-dhw.corp.example.com:/common/S2/obj/common/S2/src/amd64.amd64/sys/GENERIC
  amd64
lgld-dhw(12.2-S)[9] pkg -v
1.16.3

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"some of the terminology that was used, like 'hugs and kisses,' and 'very
fine people,' is like very different from what I experienced and what my
co-workers experienced on the 6th." - Michael Fanone, DC Metro Police Officer

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Some success; some problems with x11/nvidia-driver-460.39_1

[David Wolfskill]

With the update of x11/nvidia-driver from 460.39 to 460.39_1, it
now builds and works on a couple of laptops, running either stable/12
(stable/12-n232662-e8eded55f23) or stable/13 (stable/13-n244485-6136a10e355a).

On those same laptops, however, I get panices running head (either
main-n244659-689561d40322 or main-n244663-f6e8256a965d).  As I was
unable to get crash dumps, I took screenshots; they are available at
https://www.catwhisker.org/~david/FreeBSD/ports/nvidia-driver/head_panics/

They look like lock-ordering issues to me -- but that should be
considered a semi-educated guess (at best).


Quite unrelated to the above (as far as I can tell), except that it also
involves an issue with x11/nvidia-driver: a desktop mini-tower that had
been building/updating x11/nvidia-driver-440 every week running
stable/12 ... did not do so well attempting to build the port during its
kernel build (by virtue of

PORTS_MODULES=x11/nvidia-driver

in /etc/src.conf) this morning -- it nearly finished, then failed to
find a file where it was expected during the "Registering installation"
phase:

| ...
| > Compressing man pages (compress-man)
| ===>  Installing for nvidia-driver-460.39_1
| ===>   Registering installation for nvidia-driver-460.39_1
| pkg-static: Unable to access file 
/common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/icd.d/nvidia_icd.json:No
 such file or directory
| pkg-static: Unable to access file 
/common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/implicit_layer.d/nvidia_layers.json:No
 such file or directory
| *** Error code 1
| 
| Stop.
| make[1]: stopped in /common/ports/x11/nvidia-driver
| *** Error code 1
| 
| 

This machine has the specification (in /etc/make.conf):

PORTSDIR=/common/ports

I re-created the observed issue by trying to update/install
x11/nvidia-driver using portmaster (in its default "clean everything
before and after" mode).

I did this in a script(1) invocation, and have copied the resulting
typescript to
https://www.catwhisker.org/~david/FreeBSD/ports/nvidia-driver/stable_12_staging_error/nvidia_build.txt

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Donald Trump held the office of President of the US as he incited his Putsch.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Can't load nvidia.ko on stable/12 after r564088 (440.100_1 -> 460.36)

[David Wolfskill]

On Fri, Feb 05, 2021 at 04:51:02AM -0800, John Kennedy wrote:
> ...
> > So I suspect that "link_elf_obj: symbol nvidia_driver_name undefined"
> > whine is likely salient.
> 
>   I just opened up PR#253269 for the same symptom.

Ah; cool -- thanks!  Once I finish the morning's update cycle, I'll Cc:
myself on it.

> I suspect that it is due to me having WITH_BIND_NOW=YES set in
> my /etc/src.conf (my usual cause for undefined symbols that haven't
> bitten other people).  Have you set that as well?

I do not; what I have is:

KERNCONF=CANARY
PORTS_MODULES+=x11/nvidia-driver
.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
WITHOUT_DEBUG_FILES=1
IWN_DEBUG=1
IEEE80211_DEBUG=1
BATCH_DELETE_OLD_FILES=1
WITHOUT_REPRODUCIBLE_BUILD=yes
WITHOUT_LLVM_TARGET_ALL=yes

>   If not, then probably a much wider audience.

Probably, yeah.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Donald Trump held the office of President of the US as he incited his Putsch.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Can't load nvidia.ko on stable/12 after r564088 (440.100_1 -> 460.36)

[David Wolfskill]

This is on both my current laptop (Dell Precision M4800) and a new(er)
one (Dell Precision 7520); the current laptop's graphics card shows up
as:

vgapci0@pci0:1:0:0: class=0x03 card=0x05cc1028 chip=0x11fc10de rev=0xa1 
hdr=0x00
vendor = 'NVIDIA Corporation'
device = 'GK106GLM [Quadro K2100M]'
class  = display
subclass   = VGA

and the new(eR) one as:

vgapci0@pci0:1:0:0: class=0x03 card=0x17b01028 chip=0x13b610de rev=0xa2 
hdr=0x00
vendor = 'NVIDIA Corporation'
device = 'GM107GLM [Quadro M1200 Mobile]'
class  = display
subclass   = VGA


while running stable/12 at n232662-e8eded55f23:

g1-55(12.2-S)[5] uname -aUK
FreeBSD g1-55.catwhisker.org 12.2-STABLE FreeBSD 12.2-STABLE #949 
stable/12-n232662-e8eded55f23: Fri Feb  5 03:33:27 PST 2021 
r...@g1-55.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1202505 1202505

dmesg reports:

link_elf_obj: symbol nvidia_driver_name undefined
linker_load_file: /boot/modules/nvidia.ko - unsupported file type
KLD nvidia-modeset.ko: depends on nvidia - not available or version mismatch
linker_load_file: /boot/modules/nvidia-modeset.ko - unsupported file type

for each.

So I suspect that "link_elf_obj: symbol nvidia_driver_name undefined"
whine is likely salient.

As a circumvention:
cd /usr/ports/x11/nvidia-driver && \
sudo svn merge -c -r564088 . && \
sudo portmaster x11/nvidia-driver

worked for me (well, for the current laptop; I left the newer laptop
broken, as I only ssh into it, as its built-in mouse doesn't seem
to work with FreeBSD, nor does its wireless card (yet)).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Donald Trump held the office of President of the US as he incited his Putsch.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Pinentry

[David Wolfskill]

On Mon, Jan 25, 2021 at 11:00:46AM -0700, @lbutlr wrote:
> I ma trying to figure out why pin entry and pinetnry-tty are installed. If I 
> try to remove it, I get a list of post that are to be deleted.
> 
> Installed packages to be REMOVED:
> gnupg: 2.2.27
> gpgme: 1.15.1
> mimedefang: 2.83_3
> mutt: 2.0.4
> pinentry: 1.1.0_7
> pinentry-tty: 1.1.0
> spamass-milter: 0.4.0_4
> spamassassin: 3.4.4
> subversion: 1.14.0
> 
> I've looked through he config for all of these and not seen anything about 
> PIN entry, and am wondering why it would be required to run any of these 
> packages.

pinentry is (also) used to enter (e,g,) passphrases (as would be used by
gnupg).

> I cannot imagine any circumstances in which I would need to enter a PIN on a 
> TTY and no one else could possibly do so.
> 
> I suspect mutt since it is relatively newly installed, nut I see nothing in 
> the config that seems like it wold disable this. (Mutt is used as a 
> convenient way to send html formatted mail of some system events), it is not 
> used to access mail off the server and is only used by me to access mail on 
> the server.
> 

You may well need but a subset of the default options in that case.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Some "Republicans" seem bound and determined to turn the party known for
touting "law and order" into one that supports mob rule and insurrection.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: make index errors ports/head rev 556800

[David Wolfskill]

On Wed, Dec 02, 2020 at 02:41:17PM +, tech-lists wrote:
> Hi,
> 
> I'm getting these errors when make index runs on latest ports:
> [...]
> Warning: Duplicate INDEX entry: ocaml-nox11-4.05.0_1
> Warning: Duplicate INDEX entry: mc-nox11-4.8.24
> [...]
> 
> Should I raise this in bugzilla?
> 
> thanks,
> -- 
> J.

My local "make index" had no issues with a ports tree (head@r556814),
running on stable/12@r368270.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"We are trying to do another four years." (delusional) Donald Trump, 01 Dec 2020

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?

[David Wolfskill]

On Tue, Oct 06, 2020 at 08:31:05AM +0900, Tatsuki Makino wrote:
> Hello.
> 
> In my case,
> -x \*-kmod-\[0-9gv\] is added to portmaster because all packages that
> install kernel modules contain -kmod in their names. This excludes *-kmod.
> And when they are upgraded, I won't be installing them right away.
> 
> Then to install them I write PORTS_MODULES in src.conf.
> PORTS_MODULES=\
> graphics/drm-fbsd12.0-kmod\
> graphics/gpu-firmware-kmod
> 
> They are created at the same time as the kernel.
> 

But in order for them to be built, you need to have updated
ports-mgmt/pkg ahead of time, or this kind of thing happens:

| ...
| --- kernel.full ---
| linking kernel.full
| ctfmerge -L VERSION -g -o kernel.full ...
|   text  data   bssdec hex   filename
|   22900304   1840729   3667344   28408377   0x1b17a39   kernel.full
| Building /common/S1/obj/usr/src/amd64.amd64/sys/CANARY/kernel.debug
| Building /common/S1/obj/usr/src/amd64.amd64/sys/CANARY/kernel
| --- all ---
| ===> Ports module x11/nvidia-driver (all)
| cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env  -u CC  -u CXX  -u CPP  -u 
MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR  MAKEFLAGS="-j 16 -J 15,16 -j 16 -J 
15,16 -D NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64 
TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys  
PATH=/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/common/S1/obj/usr/src/amd64.amd64/tmp/legacy/bin:/common/S1/obj/usr/src/amd64.amd64/tmp/usr/sbin:/common/S1/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
  SRC_BASE=/usr/src  OSVERSION=1202502  
WRKDIRPREFIX=/common/S1/obj/usr/src/amd64.amd64/sys/CANARY make -B clean build
| ===>  Cleaning for nvidia-driver-440.100_1
| ===>  nvidia-driver-440.100_1 pkg(8) must be version 1.15.9 or greater, but
| you have 1.15.8. You must upgrade the ports-mgmt/pkg port first.
| *** Error code 1
| 
| Stop.


Hence my query: Is an UPDATING entry warranted when MINIMAL_PKG_VERSION is
bumped?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"the end of the pandemic is in sight" -- Donald Trump (while infected
with SARS-COV-2)

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Might an UPDATING entry be appropriate for a MINIMAL_PKG_VERSION bump?

[David Wolfskill]

When I rebuild FreeBSD (stable/12) on my laptop, I also rebuild a ports
module (x11/nvidia-driver), since the laptop has an Nvidia graphics
card.

However, a couple of times within the last few days, the kernel build
has failed because I normally wait to update ports until after I have
built and rebooted the newly-built base OS... and "?ports" includes
ports-mgmt/pkg.

In each case (so far), I have then updated ports-mgmt/pkg, then
re-started the base OS build/install.

I believe that it would be helpful to have an UPDATING entry reflect
that "evasive action" is required when MINIMAL_PKG_VERSION is bumped.

Or, perhaps, I'm going about this all wrong...?  If so, please let me
know a better way.

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Donald Trump is just in it for the publicity (well, and the money).

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

r548950: graphics/mesa-libs vs. x11/nvidia-driver??!?

[David Wolfskill]

r548950 | manu | 2020-09-19 02:34:36 -0700 (Sat, 19 Sep 2020) | 9 lines

mesa-libs: Add glesv1 lib

There is no real reason to disable glesv1 so add it to the build.
While here add a USE_GL for it.

Reviewed by:zeising
Approved by:x11 (zeising@)
Differential Revision:  https://reviews.freebsd.org/D26461



g1-48(12.2-S)[4] pkg which  /usr/local/lib/libGLESv1_CM.so
/usr/local/lib/libGLESv1_CM.so was installed by package nvidia-driver-440.100

So when graphics/mesa-libs is updated to r548950, it builds & stages
OK, but:

===>  Installing for mesa-libs-19.0.8_3
===>   Registering installation for mesa-libs-19.0.8_3 as automatic
Installing mesa-libs-19.0.8_3...
pkg-static: mesa-libs-19.0.8_3 conflicts with nvidia-driver-440.100 (installs 
files into the same place).  Problematic file: /usr/local/lib/libGLESv1_CM.so
*** Error code 70

How should this be resolved?

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"President Trump can say whatever he likes, but his actions speak for
themselves." -- Dan Berschinski, wounded US Army veteran

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: portsnap depreciation

[David Wolfskill]

On Fri, Sep 18, 2020 at 01:58:29PM -0400, Carmel NY wrote:
> ...
> >https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree
> > 
> >and the next sections.
> 
> According to the above page, "The most straightforward way is to have
> Poudriere create a default ports tree for itself, using either
> portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running
> FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE,
> I cannot use subversion?
> 

I don't see any reason why you cannot use subversion: I do, and have
done, since 05 July 2015, running stable/10  at the time; now running
stable/12.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"President Trump can say whatever he likes, but his actions speak for
themselves." -- Dan Berschinski, wounded US Army veteran

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: the state of amd64 ports on -CURRENT as of 20200827

[David Wolfskill]

On Thu, Aug 27, 2020 at 01:55:08PM +, Mark Linimon wrote:
> The latest build of amd64-CURRENT ports has just completed:
> 
>   
> http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p546132_s364744
> 
> The number of build failures is now 740.  This is an slight drop from
> the initial post-clang11 commit of 830.  This is due to diligent work
> by a more than a dozen ports committers.  I appreciate their efforts.
> 

As maintainer of a (likely rarely-used) port (x11-wm/piewm), I
received a note from pkg-fallout, requested & received advice on
how to adrdess it, filed a bug report & attached a maintainer-approved
patch; got some advice on a better fix, updated the bug report with
the better fix ... and have now received at least 3 more notices
of the same failure on the same port...

It's https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248859, in case you
wanted to see for yourself.

As I'm not a committer, it's not clear to me what (else) I can do to
help fix this.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Those countries that have lost control of the virus like the United
States are seeing economic forecasts constantly revised down and are
weaker economically." -- Dominick Stephens, Westpac NZ's chief economist

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: x11-wm/piewm: "ld: error: duplicate symbol: yylineno"

[David Wolfskill]

On Mon, Aug 24, 2020 at 10:11:45AM +0200, Dimitry Andric wrote:
> 
> > Advice/suggestions?
> 
> In this case, "svn rm x11-wm/piewm/files/patch-gram.y" will fix it
> correctly. I have no idea why that patch was added in the first place,
> it is clearly incorrect!
> 
> -Dimitry
> 

Thank you very much!  I will verify that and send in a correct fix once
I do.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Those countries that have lost control of the virus like the United
States are seeing economic forecasts constantly revised down and are
weaker economically." -- Dominick Stephens, Westpac NZ's chief economist

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

x11-wm/piewm: "ld: error: duplicate symbol: yylineno"

[David Wolfskill]

On Sun, Aug 23, 2020 at 06:39:10PM +, pkg-fall...@freebsd.org wrote:
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
> 
> Maintainer: da...@catwhisker.org
> Last committer: swi...@freebsd.org
> Ident:  $FreeBSD: head/x11-wm/piewm/Makefile 519608 2019-12-09 
> 13:47:16Z swills $
> Log URL:
> http://beefy18.nyi.freebsd.org/data/head-amd64-default/p545731_s364466/logs/piewm-1.04_4.log
> Build URL:  
> http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p545731_s364466
> ...
> --- piewm ---
> rm -f piewm
> cc -o piewm   -L/usr/local/lib   gram.o lex.o deftwmrc.o add_window.o 
> gc.o list.o twm.o   parse.o menus.o events.o resize.o util.o 
> version.o iconmgr.ocursor.o icons.o vdt.o move.o LocPixmap.o 
> -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXext -lXext -lX11 -lm 
> -ll -lXpm  -Wl,-rpath,/usr/local/lib
> ld: error: duplicate symbol: yylineno
> >>> defined at gram.c
> >>>gram.o:(yylineno)
> >>> defined at lex.c
> >>>lex.o:(.data+0x0)
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [piewm] Error code 1
> 
> make[1]: stopped in /wrkdirs/usr/ports/x11-wm/piewm/work/piewm-1.04
> 1 error
> 
> make[1]: stopped in /wrkdirs/usr/ports/x11-wm/piewm/work/piewm-1.04
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/x11-wm/piewm

So... I confess a lack of familiarity with lex, yacc, and their
work-alikes.  It also appears that x11-wm/tvtwm (for which MAINTAINER is
this list -- po...@freebsd.org) is likely similarly affected.

I understand that the immediate cause is a recent change; in
http://docs.FreeBSD.org/cgi/mid.cgi?B7F9F85B-60A4-4A87-9911-BDE1CBC7BC91,
dim@ mentioned:

| This is because clang 11 (and gcc 10) now default to -fno-common. The
| rationale is explained pretty well in...

and goes on to state:
| A quick fix is to add CFLAGS+=-fcommon to your make.conf, but that is
| rather a big hammer. It is better to add it to just the ports that show
| problems due to duplicated symbols. And ideally, those duplicated
| symbols should be patched out of the ports.

So:  apparently *a* way around this is to change the Makefile (to
include 'CFLAGS+=-fcommon') -- but I don't know if a "better" approach
is feasible: we are dealing with some rather old (or, perhaps,
"well-established") code, here.

Advice/suggestions?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Those countries that have lost control of the virus like the United
States are seeing economic forecasts constantly revised down and are
weaker economically." -- Dominick Stephens, Westpac NZ's chief economist

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: bugzilla messages about issues related to freebsd-ports, freebsd-multimedia, ...

[David Wolfskill]

On Sat, Jul 11, 2020 at 01:27:55PM +0200, Matthias Apitz wrote:
> ... 
> There is nothing written about "... and for Cc issues from bugzilla".
> 
> What I do not like and do not understand why this was introduced, that
> the issue tracker bugzilla copies comments etc. in the issues to the
> mailing-list and spams the lists with this (an example is below). This
> way I get every day some hundred mails.
> 
> Why is this intention? Can it be changed? To whom I should direct this
> complain?
> 
>   matthias
> 


That happens -- at least in the case of multimedia/ffmpeg -- because:

g1-55(13.0-C)[4] awk -F = '$1 == "MAINTAINER"' 
/usr/ports/multimedia/ffmpeg/Makefile
MAINTAINER= multime...@freebsd.org

So it's merely notification to the listed "maintainer" of the port.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If Trump continues to delay access to his tax records, a voter would be
prudent to presume that they contain incriminating information.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Can anyone build www/node right now?

[David Wolfskill]

On Sun, Jun 28, 2020 at 10:07:58PM +0200, DutchDaemon - FreeBSD Forums 
Administrator wrote:
> I have tried to build www/node for weeks now, and it always fails. This is on 
> a fresh Poudriere jail, amd64, 12.1-REL-p6.

Checking my logs, www/node is one of the packages built (via poudriere)
this morning by my build machine, which was running:

freebeast(12.1-S)[1] uname -aUK
FreeBSD freebeast.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #942 
r362716M/362719: Sun Jun 28 03:33:45 PDT 2020 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 1201518 1201518

at the time, using a (head) ports tree at r540699.

As a reality check, I am trying to build www/node on my laptop, running:

g1-55(12.1-S)[4] uname -aUK
FreeBSD g1-55.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #737 
r362716M/362719: Sun Jun 28 03:33:54 PDT 2020 
r...@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY  amd64 
1201518 1201518

with a (head) ports tree at r540699.

The build machine has no option overrides for www/node; the laptop shows:
g1-55(12.1-S)[2] make -C /usr/ports/www/node showconfig
===> The following configuration options are available for node-14.4.0:
 BUNDLED_SSL=on: Use node.js's bundled OpenSSL implementation
 DOCS=on: Build and/or install documentation
 DTRACE=on: Build with DTrace probes
 NLS=on: Native Language Support
===> Use 'make config' to modify these settings

> Opened a ticket for it, with full output...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Of course Black Lives Matter!  Now vote accordingly!

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: poudriere-devel failed to build lang/rust (rust-1.43.1)

[David Wolfskill]

On Sun, May 24, 2020 at 04:31:42PM +0200, Jan Beich wrote:
> ...
> According to the full log the reason is "(signal: 9, SIGKILL: kill)" and
> the signal was sent to multiple processes. The kernel usually sends
> SIGKILL on out-of-memory conditions.

Oh!  OK; thank you: I had failed to see that.

I'll look into appropriate evasive action (e.g., adding more memory
or replacing the machine with a more capable one.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"The Liar Tweets Tonight": https://www.youtube.com/watch?v=TkU1ob_lHCw

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: poudriere-devel failed to build lang/rust (rust-1.43.1)

[David Wolfskill]

On Sat, May 23, 2020 at 03:56:09PM -0700, David Wolfskill wrote:
> ...
> load: 8.59  cmd: sh 99503 [piperd] 35609.83r 1.23u 1.88s 0% 2156k
> [12amd64-ports-home] [2020-05-23_12h08m48s] [parallel_build:] Queued: 1003 
> Built: 999  Failed: 1Skipped: 2Ignored: 0Tobuild: 1 Time: 
> 09:53:48
> [05]: www/chromium  | chromium-81.0.4044.138_1  build 
>   (03:59:48 / 04:08:53)
> [09:53:49] Logs: 
> /tank/poudriere/poudriere/data/logs/bulk/12amd64-ports-home/2020-05-23_12h08m48s
> ... 
> I expect that once www/chromium finally finishes, I'll give poudriere
> another chance at the "stragglers" (and record the results in
> http://www.catwhisker.org/~david/FreeBSD/ports/rust/).
> 

Retry appears to have worked :

[00:00:16] Starting/Cloning builders
[00:00:17] Hit CTRL+t at any time to see build progress and stats
[00:00:17] [01] [00:00:00] Building lang/rust | rust-1.43.1
[01:00:51] [01] [01:00:34] Finished lang/rust | rust-1.43.1: Success
[01:00:53] [01] [00:00:00] Building devel/rust-cbindgen | rust-cbindgen-0.14.2
[01:02:27] [01] [00:01:34] Finished devel/rust-cbindgen | rust-cbindgen-0.14.2: 
Success
[01:02:27] [01] [00:00:00] Building www/firefox | firefox-76.0.1_3,1
[01:39:07] [01] [00:36:40] Finished www/firefox | firefox-76.0.1_3,1: Success
[01:39:08] Stopping 3 builders

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"The Liar Tweets Tonight": https://www.youtube.com/watch?v=TkU1ob_lHCw

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

poudriere-devel failed to build lang/rust (rust-1.43.1)

[David Wolfskill]

In my environment, I have a designated "build machine" (named
"freebeast"); in addition to building FreeBSD for itself and a couple of
other machines, it also builds packages (via devel/poudriere-devel) for
those other machines.  (Each machine is amd64, running stable/12.)

The other machines get weekly updates (every Sunday), so I set up
freebeast to build the bulk of the packages every Saturday, then
(usually) the Sunday set of packages to build is relatively small (so I
can get the weekly updates done faster than if I were to wait until
Sunday to build all the packages that warrant rebuilding).

Details are in http://www.catwhisker.org/~david/FreeBSD/upgrade.html.

Today, after building stable/12 & head, I set freebeast to building
packages; a while later, Spouse and I took the tandem bike out for a
ride (for about 2.5 hours).  A whlie later, I noticed that freebeast was
still chugging away; ^T revealed that it was building www/chromium
(which was expected); it also revealed that there had been a failure
(which was not):

load: 8.59  cmd: sh 99503 [piperd] 35609.83r 1.23u 1.88s 0% 2156k
[12amd64-ports-home] [2020-05-23_12h08m48s] [parallel_build:] Queued: 1003 
Built: 999  Failed: 1Skipped: 2Ignored: 0Tobuild: 1 Time: 
09:53:48
[05]: www/chromium  | chromium-81.0.4044.138_1  build   
(03:59:48 / 04:08:53)
[09:53:49] Logs: 
/tank/poudriere/poudriere/data/logs/bulk/12amd64-ports-home/2020-05-23_12h08m48s


A quick check revealed that lang/rust was the failing port; I've
dumped a copy of the poudriere log (there's a gzipped copy there, as
well) and an "info.txt" file that shows things like "uname -a" output
from freebeast, as well as information about ports-mgmt/poudriere-devel
and the current state of the SVN working copies for src & ports.

It appears (to my eye that is quite unfamiliar with rust) that the first
failure in the log is:

sysroot: 
"/wrkdirs/usr/ports/lang/rust/work/rustc-1.43.1-src/build/x86_64-unknown-freebsd/stage1"
libdir: 
"/wrkdirs/usr/ports/lang/rust/work/rustc-1.43.1-src/build/x86_64-unknown-freebsd/stage1/lib"
error: could not compile `rustc_lint`.

(which shows up quite near the end of the supplied log file).

Please note that the machine has been building www/firefox (and
thus, lang/rust) routinely for quite some time, so this is a little
surprising.

Even more surprising is that my laptop, where I also have www/firefox
installed, and which I update via ports-mgmt/portmaster, has rust-1.43.1
built and installed, apparently without issue (other than consuming time
and generating heat).

I expect that once www/chromium finally finishes, I'll give poudriere
another chance at the "stragglers" (and record the results in
http://www.catwhisker.org/~david/FreeBSD/ports/rust/).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"The Liar Tweets Tonight": https://www.youtube.com/watch?v=TkU1ob_lHCw

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Bind 9.16 port error still lingers

[David Wolfskill]

On Sat, May 02, 2020 at 05:20:27PM +0200, Per olof Ljungmark wrote:
> On 2020-05-02 17:16, The Doctor via freebsd-ports wrote:
> > On Sat, May 02, 2020 at 04:32:10PM +0200, Christoph Moench-Tegeder wrote:
> >> ## The Doctor via freebsd-ports (freebsd-ports@freebsd.org):
> >>
> >>> Subject: Bind 9.16 port error still lingers
> >>
> >> "Still"?
> >>
> >>> May  1 21:29:02 gallifrey named[90441]: Required root permissions to open 
> >>> '/var/run/named.pid'.
> >>> May  1 21:29:02 gallifrey named[90441]: Please check file and directory 
> >>> permissions or reconfigure the filename.
> >>
> >> Did you?
> >> BTW the default location for named's pidfile on FreeBSD is
> >> /var/run/named/pid.

I'm running bind916-9.16.2:
albert(12.1-S)[3] pkg info -o dns/bind\*
bind-tools-9.16.2  dns/bind-tools
bind916-9.16.2 dns/bind916

Here's what I have in /etc/rc.conf about it:
albert(12.1-S)[5] egrep 'bind|named' /etc/rc.conf
rpcbind_enable="YES"
named_enable="YES"
named_program="/usr/local/sbin/named"

and the pidfile is in /var/run/named/:

albert(12.1-S)[4] ls -lT /var/run/named/
total 8
-rw-r--r--  1 bind  bind6 May  1 05:03:40 2020 pid
-rw---  1 bind  bind  102 May  1 05:03:40 2020 session.key

No issues.

> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I believe the people of this country are smart. And I don't think that
they will put a man in who's incompetent."
-- Donald J. Trump, who apparently missed the irony, 29 Apr 2020.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: FreeBSD Port: firefox-73.0,1 error build

[David Wolfskill]

On Tue, Feb 04, 2020 at 03:49:39PM +0700, Alex V. Petrov wrote:
> ...
> In file included from
> /usr/ports/www/firefox/work/.build/dist/system_wrappers/exception:3:
> 
> 
> /usr/include/c++/v1/exception:180:5: error: no member named 'abort' in
> namespace 'std::__1'; did you mean simply 'abort'?
> _VSTD::abort();
> ^~~
> /usr/include/c++/v1/__config:759:15: note: expanded from macro '_VSTD'
> 
> #define _VSTD std::_LIBCPP_ABI_NAMESPACE
> 
>   ^
> /usr/include/stdlib.h:86:17: note: 'abort' declared here
> 
> _Noreturn void   abort(void);
>  ^
> 1 error generated.
> gmake[5]: ***
> [/usr/ports/www/firefox/work/firefox-73.0/config/rules.mk:738:
> rlbox_thread_locals.o] Error 1
> 

This is being tracked in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243863

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"The Senate has abdicated its constitutional duty during the impeachment
trial of President Donald Trump." -- Alan S. Frumin, parliamentarian
emeritus of the US Senate

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: xterm-353

[David Wolfskill]

On Sun, Feb 02, 2020 at 10:36:00AM -0500, ajtiM via freebsd-ports wrote:
> Update of xterm to version 253 has a problem:
> 
> ===>  License MIT accepted by the user
> ===>   xterm-353 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by xterm-353 for building
> => SHA256 Checksum mismatch for xterm-353.tgz.
> => SHA256 Checksum OK for bsd-xterm-icons-1.tgz.
> ===>  Giving up on fetching files:  xterm-353.tgz 
> Make sure the Makefile and distinfo file (/usr/ports/x11/xterm/distinfo)
> are up to date.  If you are absolutely sure you want to override this
> check, type "make NO_CHECKSUM=yes [other args]".
> *** Error code 1
> 

I don't see that:

g1-55(12.1-S)[1] pkg info -o xterm\*
xterm-353  x11/xterm
g1-55(12.1-S)[2] make -C /usr/ports/x11/xterm checksum
===>  License MIT accepted by the user
===>   xterm-353 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by xterm-353 for building
=> SHA256 Checksum OK for xterm-353.tgz.
=> SHA256 Checksum OK for bsd-xterm-icons-1.tgz.
g1-55(12.1-S)[3] uname -a
FreeBSD g1-55.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #594 
r357402M/357406: Sun Feb  2 03:44:20 PST 2020 
r...@g1-55.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY  amd64
g1-55(12.1-S)[4] svn info /usr/ports
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 524937
Node Kind: directory
Schedule: normal
Last Changed Author: sunpoet
Last Changed Rev: 524937
Last Changed Date: 2020-02-02 03:07:56 -0800 (Sun, 02 Feb 2020)

g1-55(12.1-S)[5] 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
McConnell's Senators are covering up their whitewash of Trump's malfeasance.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: firefox, thunderbird crash on start

[David Wolfskill]

On Mon, Jan 27, 2020 at 11:51:32AM -0700, Russell L. Carter wrote:
> Hi folks,
> On about a month old -stable amd64, recent, up-to-the minute
> firefox and thunderbird are crashing on startup since yesterday,
> like so:
> 
> rcarter@feyerabend> firefox
> 
> (firefox:5486): GLib-GIO-CRITICAL **: 11:45:26.964: g_dbus_proxy_new:
> assertion 'G_IS_DBUS_CONNECTION (connection)' failed
> 
> (firefox:5486): GLib-GIO-CRITICAL **: 11:45:26.965: g_dbus_proxy_new:
> assertion 'G_IS_DBUS_CONNECTION (connection)' failed
> 
> (firefox:5486): GLib-GIO-CRITICAL **: 11:45:26.965: g_dbus_proxy_new:
> assertion 'G_IS_DBUS_CONNECTION (connection)' failed
> Exiting due to channel error.
> Exiting due to channel error.
> zsh: segmentation fault  firefox
> rcarter@feyerabend>  thunderbird
> rcarter@feyerabend>
> 
> Sometimes I'll get a window, that goes away immediately, mostly not.
> I cleared the .mozilla .thunderbird profiles and it's not that.
> 
> I build ports via poudriere.
> 

See (e.g.) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243629 --
note that dropping databases/sqlite3 back to sqlite3-3.30.1 (from
sqlite3-3.31.0) appears to resolve the issue; it seem sthat firefox was
using a non-public interface, and that interface changed

Note that databases/sqlite3 has been reverted as of ports (head)
revision r524241.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Now, with me, there's no lying." -- Donald J. Trump   ["??!?" -- me]

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: sqlite3 update to 3.31.0 breaks firefox and thunderbird

[David Wolfskill]

On Sun, Jan 26, 2020 at 06:35:01PM -0500, Michael Butler wrote:
> Both produce core dumps related to sqlite :-( Rebuilding both doesn't
> fix either. Downgrading to 3.30.1 restores normal operation,
> 

Confirmed; thank you for the circumvention.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Now, with me, there's no lying." -- Donald J. Trump   ["??!?" -- me]

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: chromium-79.0.3945.130 fails to build.

[David Wolfskill]

On Thu, Jan 23, 2020 at 09:58:17AM +1300, Jonathan Chen wrote:
> Hi,
> 
> The latest update of chromium-79.0.3945.130 is currently failing to
> build on FreeBSD-12/amd64:
> 

Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243509
(which has a patch that allowed the build to succeed for some of us).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
What will Donald J. Trump choose as his regnal name once McConnell's
whitewash fails to convict him?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: How should follks migrate from linux_base-c6 to linux_base-c7?

[David Wolfskill]

On Tue, Dec 31, 2019 at 04:19:30PM +0100, Tijl Coosemans wrote:
> ...
> > | compat.linux.osrelease=2.6.18
> 
> This was needed when the default value was 2.4., but nowadays
> the default is already higher than 2.6.18 so you can just remove this.
> Besides that it's just a matter of removing c6 packages and installing c7
> packages.

Excellent: thank you!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
At least Trump can count on McConnell and Putin to "have his back."
And the rest of us can consider what that means about each of them.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

How should follks migrate from linux_base-c6 to linux_base-c7?

[David Wolfskill]

As noted in
,
the -c6 ports "expire tomorrow."

I don't see a documented process for migrating from linux_base-c6 to
linux_base-c7; perhaps I'm being thicker than usual.

For example, from prior migrations (e.g., the 20141209 entry in
ports/UPDATING), there's a mention of:

|  2. Persistently update the Linux kernel version in /etc/sysctl.conf:
|
| compat.linux.osrelease=2.6.18

and since there has (as far as I know) been no indication that that
should be changed, I still have it (in stable/11, stable/12, and
head).  But

does not mention a compat.linux.osrelease sysctl value at all.

I had asked about the migration process Fri Sep 30 20:30:24 UTC 2016;
at the time, the response was:

| We are still working on the other c7 ports:
| https://reviews.freebsd.org/D7886

but I have seen nothing further about the migration process itself.
ports/UPDATING entry 20190710 does discuss the "c6" Linux emulation (but
not "c7").

So: how should a system that has been configured to support
linux_base-c6 be migrated to support linux_base-c7?

Thanks.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
At least Trump can count on McConnell and Putin to "have his back."
And the rest of us can consider what that means about each of them.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: [Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1

[David Wolfskill]

On Mon, Sep 02, 2019 at 01:34:50PM +0200, Walter Schwarzenfeld wrote:
> Try recompile graphics/libspiro.
> 

Thanks.  As noted, I did (along with graphics/gegl), and that appears to
have circumvented the problem.

I wrote the note so that others might make use of my experience: the
issue is resolved for me.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I am the Chosen One!" -- Donald Trump [Cf. Mt 24:23-24; Mk 13:21-23; Jn 5:31]

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

[Circumvented] Problem updating gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1

[David Wolfskill]

I update base FreeBSD and the installed ports on my laptop daily;
usually, this works out quite well (which I think says something very
positive about FreeBSD).

This morning, the attempt to update graphics/gimp-app failed; I was able
to get it to work by manually re-building and -installing
graphics/libspiro and graphics/gegl.  (It's quite possible that only
doing one of those would have been sufficient; I don't know.)  Below are
details for those who may be interested.

Yesterday's update for base stable/11 was actually a no-op: I updated
from r351611 to r351640 on Saturday (31 August); there were no updates
to stable/11 (or stable/12, for that matter) as of the sync I ran on 01
September.

Yesterday's update for ports from from r510361 to r510686, and was
uneventful.

Today's update for base FreeBSD stable/11 was from r351640 to
r351694; ports was from r510686 to r510776.

I use portmaster to build/install the ports on my laptop; it reported
the following ports would be updated (this morning):

===>>> The following actions will be taken if you choose to proceed:
Upgrade libogg-1.3.3,4 to libogg-1.3.4,4
Upgrade gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1
Upgrade poppler-glib-0.79.0 to poppler-glib-0.80.0_1
Upgrade poppler-0.79.0 to poppler-0.80.0_1
Upgrade libarchive-3.3.3_1,1 to libarchive-3.4.0,1
Upgrade libgcrypt-1.8.4_1 to libgcrypt-1.8.5
Upgrade poppler-utils-0.79.0 to poppler-utils-0.80.0_1
Upgrade texlive-base-20150521_39 to texlive-base-20150521_40
Upgrade chromium-76.0.3809.100 to chromium-76.0.3809.132
Upgrade inkscape-0.92.4_6 to inkscape-0.92.4_7
Upgrade py27-gimp-2.10.12_2 to py27-gimp-2.10.12_3
Re-install py27-gobject-2.28.6_8
Re-install py27-gtk2-2.24.0_5


The failure looked like this:

...
mkdir -p 24 && \
../../tools/invert-svg ../../icons/Symbolic/24/gimp-wilber.svg 
24/gimp-wilber.svg
mkdir -p `dirname 64/gimp-error.png`; GEGL_USE_OPENCL=no GEGL_SWAP=ram 
/usr/local/bin/gegl ../../icons/Symbolic/64/gimp-error.png -o 64/gimp-error.png 
-- gegl:invert-gamma
mkdir -p `dirname 64/gimp-info.png`; GEGL_USE_OPENCL=no GEGL_SWAP=ram 
/usr/local/bin/gegl ../../icons/Symbolic/64/gimp-info.png -o 64/gimp-info.png 
-- gegl:invert-gamma
mkdir -p `dirname 64/gimp-question.png`; GEGL_USE_OPENCL=no GEGL_SWAP=ram 
/usr/local/bin/gegl ../../icons/Symbolic/64/gimp-question.png -o 
64/gimp-question.png -- gegl:invert-gamma
Shared object "libspiro.so.0" not found, required by "gegl"
Shared object "libspiro.so.0" not found, required by "gegl"
gmake[5]: *** [Makefile:2411: 64/gimp-error.png] Error 1
gmake[5]: *** Waiting for unfinished jobs
gmake[5]: *** [Makefile:2411: 64/gimp-info.png] Error 1
Shared object "libspiro.so.0" not found, required by "gegl"
gmake[5]: *** [Makefile:2411: 64/gimp-question.png] Error 1
gmake[5]: Leaving directory 
'/common/ports/graphics/gimp-app/work/gimp-2.10.12/icons/Symbolic-Inverted'
gmake[4]: *** [Makefile:717: all-recursive] Error 1
gmake[4]: Leaving directory 
'/common/ports/graphics/gimp-app/work/gimp-2.10.12/icons'
gmake[3]: *** [Makefile:852: all-recursive] Error 1
gmake[3]: Leaving directory '/common/ports/graphics/gimp-app/work/gimp-2.10.12'
gmake[2]: *** [Makefile:753: all] Error 2
gmake[2]: Leaving directory '/common/ports/graphics/gimp-app/work/gimp-2.10.12'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /common/ports/graphics/gimp-app
*** Error code 1

Stop.
make: stopped in /common/ports/graphics/gimp-app

===>>> make build failed for graphics/gimp-app
===>>> Aborting update

===>>> Update for graphics/gimp-app failed
===>>> Aborting update
.



I then ran:

portmaster --no-term-title -d graphics/libspiro graphics/gegl

(which was ... uneventful), after which 

portmaster --no-term-title -ad

reported:

===>>> The following actions will be taken if you choose to proceed:
Upgrade gimp-app-2.10.12_2,1 to gimp-app-2.10.12_3,1
Upgrade libarchive-3.3.3_1,1 to libarchive-3.4.0,1
Upgrade libgcrypt-1.8.4_1 to libgcrypt-1.8.5
Upgrade poppler-utils-0.79.0 to poppler-utils-0.80.0_1
Upgrade texlive-base-20150521_39 to texlive-base-20150521_40
Upgrade chromium-76.0.3809.100 to chromium-76.0.3809.132
Upgrade inkscape-0.92.4_6 to inkscape-0.92.4_7
Upgrade py27-gimp-2.10.12_2 to py27-gimp-2.10.12_3
Re-install py27-gobject-2.28.6_8
Re-install py27-gtk2-2.24.0_5

which I acknowledged -- and it's well past the problematic port now
(working on chromium, which will take  a while).

Given the nature of the failure and the circumvention, I suspect
that an undeclared dependency may exist that involves some combination
of graphics/gimp-app, graphics/libspiro, or graphics/gegl -- possibly
involving port options; here are the options I have for each:

g1-49(11.3-S)[15] foreac

Re: devel/llvm80 build blocked by "graphics/py-imagesize@py27 | py27-imagesize-1.1.0: Failed: fetch"

[David Wolfskill]

On Tue, Jul 23, 2019 at 01:28:46PM -0700, Mark Millard via freebsd-ports wrote:
> I'm unclear on why devel/llvm80 depends on graphics ports, but
> after 'svnlite update -r507241 /usr/ports' (not having updated
> in some time), my poudriere bulk run reported:
> 
> [00:23:50] [26] [00:10:36] Finished graphics/py-imagesize@py27 | 
> py27-imagesize-1.1.0: Failed: fetch
> [00:23:50] [26] [00:10:36] Skipping devel/llvm80 | llvm80-8.0.1: Dependent 
> port graphics/py-imagesize@py27 | py27-imagesize-1.1.0 failed
> [00:23:50] [26] [00:10:36] Skipping textproc/py-recommonmark@py27 | 
> py27-recommonmark-0.5.0_1: Dependent port graphics/py-imagesize@py27 | 
> py27-imagesize-1.1.0 failed
> [00:23:50] [26] [00:10:36] Skipping textproc/py-sphinx@py27 | 
> py27-sphinx-1.6.5_2,1: Dependent port graphics/py-imagesize@py27 | 
> py27-imagesize-1.1.0 failed
> [00:23:50] [26] [00:10:36] Skipping devel/xtoolchain-llvm80 | 
> xtoolchain-llvm80-0.1: Dependent port graphics/py-imagesize@py27 | 
> py27-imagesize-1.1.0 failed
> 

Well, for me, I see:

g1-49(11.3-S)[491] make -C /usr/ports/devel/llvm80 all-depends-list | grep -i 
imagesize
/common/ports/graphics/py-imagesize
g1-49(11.3-S)[492] 

... so, yeah, it seems to be required.

And the fetch (of the distfile(s) is what failed.  You could try
fetching the distfile(s) manually, perhaps.  If nothing else, that might
provide some hints as to the nature of the failure.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Examples of potentially unlawful conduct include ... comments like, 'Go
back to where you came from,' whether made by supervisors or ..." - EEOC

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Cleaning up pkg-message

[David Wolfskill]

On Sat, Jun 08, 2019 at 12:11:57PM -0600, Adam Weinberger wrote:
> Hello everyone,
> 
> I want to get some stakeholder input on our pkg-message files. I think
> we need to have a clear policy about what does and doesn't belong in
> them, and I'd like to get your input.
> 
> pkg-message is shown to every user on every install. UPDATING is only
> shown when users run `pkg updating` *and* /usr/ports/UPDATING exists.
> I suspect that only a small proportion of users do that.

Well, for folks who install pre-built packages, probably.

For those of us who -- for at least some systems -- build from ports
locally, I'm less confident: I check it for relevant entries that
have been added since last time I updated installed ports on my
laptop or local build machine (which is daily) or my work desktop
(which is weekly).

Mind, its utility falls a bit short of the mark: ref.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227193

> pkg-message needs to contain only highly relevant information. Many,
> many ports have messages with irrelevant information that users are
> likely to get message fatigue and ignore them entirely. I don't want
> to pick on Joe Barbish, because his work is absolutely fantastic, but
> dns/dns2blackhole/pkg-message is an example of a giant message that
> tells users to do the same thing they always do for any port:
> 
> 
>   dns2blackhole
> 
>Malware Prevention through Domain Blocking (Black Hole)
> 
>Issue "man dns2blackhole"  For configuration and usage information
> 
> 
> 
> We now have the ability to specify messages that appear on initial
> install, or on upgrades from/to specific version. So here is what I
> propose as policy:
> 
> >>>
> pkg-message must contain only information that is vital to setup and
> operation, and that is unique to the port in question. Setup
> information should only be shown on initial install, and upgrade
> instructions should be shown only when upgrading to the relevant
> version. All committers have blanket approval to constrain existing
> messages to install/upgrade ranges using the UCL format
> specifications. Message pruning falls under the blanket approval as
> well, but committers are encouraged to get maintainer input
> beforehand.
> <<<
> 
> What are your thoughts?
> 

No objections, and de-cluttering seems like a pretty good idea.  (At
least you didn't insert a requirement that any such messages must "spark
joy." :-) )

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"...including Mars (of which the Moon is a part)" -- Donald J. Trump

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Is there a way to build only the port from source, and install dependencies from packages with the make command?

[David Wolfskill]

On Tue, Apr 30, 2019 at 10:35:21AM -0700, Yuri wrote:
> Sometimes instructions to build some port from source are needed. "cd 
> /usr/ports/{caregory}/{port-name} && make" rebuilds everything from 
> source, including dependencies.
> 
> Is there an easy way to make it install missing dependencies with pkg, 
> without listing them? I couldn't find such feature.
> 

I won't claim it's especially "easy," but within the port directory --
prior to attempting to build the port -- one can run:

make missing

to find out what dependencies are needed.  Given that list, one could
conceivably install the requisite packages.

Caveat: I have not actually done this.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Mr. Trump: "'very fine people' do not attend neo-Nazi rallies." - Nicole Hemmer

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: FreeBSD ports you maintain which are out of date

[David Wolfskill]

[Recipient list trimmed -- dhw]

On Sun, Mar 17, 2019 at 11:10:02AM +, Dima Pasechnik wrote:
> Here is an email from portscout I got today - is it sent in error, as
> I have nothing to do with the port mentioned there (and I do not
> maintain any ports), and it's not directed to me, but to the whole
> mailing list?

portscout sends messages to port maintainers.

The "port maintainer" for ports that lack an explicit maintainer is the
mailing list, freebsd-ports@freebsd.org (which has an alias of
"po...@freebsd.org").

> ...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Saying 'I'm sorry I got caught' is not an inspiring plea for leniency."

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Resolving ports conflicts for ImageMagick6

[David Wolfskill]

On Sun, Nov 18, 2018 at 09:43:39AM -0800, bob prohaska wrote:
> In trying to bring inkscape up to date on r340487 the process
> is getting stuck with
> 
> ===>   Registering installation for ImageMagick6-6.9.10.14,1 as automatic
> Installing ImageMagick6-6.9.10.14,1...
> pkg-static: ImageMagick6-6.9.10.14,1 conflicts with ImageMagick-6.9.9.28_2,1 
> (installs files into the same place).  Problematic file: 
> /usr/local/bin/Magick++-config
> *** Error code 70
> 
> The problem seems to have its origin in the rename of the imagemagick
> port mentioned in /usr/ports/UPDATING for November 10th.
> 
> How does one work past a problem like this? 
> 
> Thanks for reading,
> 
> bob prohaska
> .

I did so via "pkg delete -f graphics/ImageMagick".

(After following that with "portmaster -ad", I ran "pkg_libchk" to see
what other prts might need attention, then used portmaster to re-install
them.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Possible defense against a "perjury trap" for Trump:  Tell the truth.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: FreeBSD Port: firefox-63.0.1,1 multiple errors build

[David Wolfskill]

[Recipient list trimmed -- dhw]

On Thu, Nov 01, 2018 at 08:54:16AM +0100, Stefan Esser wrote:
> ...
> > For reliable port builds, you need use port builders that use clean
> > environments; ie poudriere or synth
> 
> True, but we used to make ports build with a previous version installed,
> whenever possible.

Quite so.

> The problems are generally caused by the build process
> picking up include files or libraries from LOCALBASE instead of from the
> port's source directory.

Seems likely.

> I'd expect a port maintainer to check for easy fixes to such build problems.

:-}

> Maybe we should add a port variable that is true if a port conflicts with
> earlier versions of itself. That would indicate to port build tools like
> portmaster or portupgrade that the old version should be deleted before
> starting the build of the new version (and to re-install the old version
> if the build of the new one fails).

I would welcome such a thing: it's annoying to need to manually "pkg
delete lang/rust" every time rust needs an update.

> E.g.:
> 
> CONFLICTS_WITH_ITSELF=yes
> 
> I'd be willing to integrate support for such a functionality into portmaster,
> if it was accepted in the ports framework.

And I would be quite happy to use it.

> Regards, STefan
> 
> PS: And yes, there are good reasons to keep support for tools that are
> lighter-weight than poudriere and more portable than synth in the
> ports system.
> ...

:-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Support the US Constitution: restrain Donald Trump.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Silent failure of 'pkg upgrade'

[David Wolfskill]

Since July, 2015, I have been updating my "production" machines here at
home on a weekly basis; for the ports/packages phase of this, I have
been using poudriere (on a dedicated "build machine") to build packages
for the production machines.

Overall, this approach has been working quite well.

Thus, I was rather surprised to find after this morning's update that
the packages had actually not been updated at all.

Reviewing the typescript, I see that sailent parts of it read:

...
Checking integrity... done (0 conflicting)
The following 47 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
webkit-gtk2-2.4.11_17
webkit2-gtk3-2.20.5
gvfs-1.30.4
gnome-online-accounts-3.28.0
libgdata-0.17.9

Installed packages to be UPGRADED:
tmux: 2.7 -> 2.8
tesseract: 3.05.02_2 -> 3.05.02_3
sqlite3: 3.25.1 -> 3.25.1_1
spidermonkey52: 52.8.0_1 -> 52.8.0_2
qtchooser: 39 -> 66
qt5-core: 5.11.2 -> 5.11.2_1
python36: 3.6.6_1 -> 3.6.7
py27-openssl: 17.5.0_1 -> 18.0.0
py27-libxml2: 2.9.7 -> 2.9.7_1
py27-gimp: 2.8.22_1 -> 2.10.6_1
portmaster: 3.19_15 -> 3.19_18
pkgconf: 1.5.3,1 -> 1.5.4,1
pciids: 20180921 -> 20181027
nss: 3.39 -> 3.40
netpbm: 10.83.02 -> 10.84.02
net-snmp: 5.7.3_18 -> 5.7.3_19
neon: 0.30.2_3 -> 0.30.2_4
mesa-dri: 18.1.9 -> 18.1.9_1
llvm60: 6.0.1_2 -> 6.0.1_3
linux-c6: 6.9_1 -> 6.10_1
libdvdcss: 1.4.1 -> 1.4.2
icu: 62.1_2,1 -> 63.1,1
help2man: 1.47.7 -> 1.47.8
harfbuzz-icu: 2.0.0 -> 2.0.2_1
harfbuzz: 2.0.0 -> 2.0.2
gtk-doc: 1.28 -> 1.29
gpgme: 1.11.1 -> 1.12.0
glib: 2.56.1_1,1 -> 2.56.1_2,1
gimp-app: 2.8.22_1,1 -> 2.10.6_1,1
gimp: 2.8.22,2 -> 2.10.6,2
freeglut: 3.0.0_1 -> 3.0.0_2
firefox: 62.0.3,1 -> 63.0_3,1
ffmpeg: 4.0.2_5,1 -> 4.0.2_7,1
dovecot: 2.3.3 -> 2.3.3_2
ca_root_nss: 3.39 -> 3.40
boost-libs: 1.68.0_1 -> 1.68.0_2
bind911: 9.11.4P2 -> 9.11.5
apr: 1.6.3.1.6.1_1 -> 1.6.5.1.6.1
apache24: 2.4.35 -> 2.4.37

Installed packages to be REINSTALLED:
nut-2.7.4_8 (options changed)
linux-c6-qt47-webkit-4.7.2_4 (direct dependency changed: 
linux-c6-qt47-x11)
gimp-gutenprint-5.2.14 (needed shared library changed)

Number of packages to be removed: 5
Number of packages to be upgraded: 39
Number of packages to be reinstalled: 3

The operation will free 121 MiB.

Proceed with this action? [y/N]: y
...
[17/47] Upgrading gimp-app from 2.8.22_1,1 to 2.10.6_1,1...
[17/47] Extracting gimp-app-2.10.6_1,1:   0%^M[17/47] Extracting 
gimp-app-2.10.6_1,1:   0%^M[17/47] Extracting gimp-app-2.10.6_1,1:   
1%^M[17/47] Extracting gimp-app-2.10.6_1,1:   2%^M[17/47] Extracting 
gimp-app-2.10.6_1,1:   3%^M[17/47] Extracting gimp-app-2.10.6_1,1:   
4%^M[17/47] Extracting gimp-app-2.10.6_1,1:   5%^M[17/47] Extracting 
gimp-app-2.10.6_1,1:   6%
pkg: Fail to create temporary file: 
/usr/local/libexec/gimp/2.2/plug-ins/align-layers/.align-layers.pD2NdeK0jYaA:Not
 a directory
^M[17/47] Extracting gimp-app-2.10.6_1,1: 100%

Command exit status: 0
Script done on Sun Oct 28 05:34:25 2018


[For those who may be curious: I circumvented the problem -- once I
discovered its existence -- by deleting the graphics/gimp* packages,
re-issuing "pkg upgrade", then installing graphics/gimp.]

I'm a little(!) concerned, though, that pkg would encounter an issue
that caused it to completely fail to perform what it had been doing, and
then exit with a status of 0.

Am I missing something that others would find obvious, here?  (I thought
a reality check might be in order before filing a bug report.)

Thanks.  Replies directed to the list: I'm subscribed.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Women (and decent men): vote against supporters of Trump's misogyny!

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: x11/nvidia-driver no longer works under -current (r338323)

[David Wolfskill]

On Sun, Aug 26, 2018 at 09:12:05PM +1000, Kubilay Kocak wrote:
> ...
> > It fails here:
> 
> Hi John,
> 
> It fails earlier, can you find and paste the 'error: ' line(s) ?
> 

I expect the observed failure is related to the message Alan Cox sent
yesterday:

| Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD)
| From: Alan Cox 
| Message-ID: <4a20ff49-9dc7-736f-9339-2bbbfae1e...@rice.edu>
| Date: Sat, 25 Aug 2018 14:48:55 -0500
| 
| ...
| The last change in this series has been committed to HEAD.  With that
| change, you will want to remove the first argument, which should be an
| arena pointer,  from kmem_free() calls.
| 
| Alan

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: nvidia-driver build error (last ports, FreeBSD-HEAD)

[David Wolfskill]

On Tue, Aug 21, 2018 at 04:41:42PM +0700, Alex V. Petrov wrote:
> 

I also encountered this, but with x11/nvidia-driver-340.

Some additional information:

* I did not encounter the issue on stable/11 (as of r338124).
* In head, I did not have a problem as recently as @r338094.
* In head, where I did have a problem, it was @r338130.

It looks to me as if this may be collateral damage from r338107.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: After mutt-1.10.0_1 -> mutt-1.10.1 upgrade, gnupg fails

[David Wolfskill]

On Fri, Jul 20, 2018 at 05:52:51AM -0700, David Wolfskill wrote:
> 
> A symptom is that an attempt to send a signed, unencrypted message
> yields a failure, with the messages:
> 
> | gpg: skipped "0x6757003D": Unusable secret key
> | gpg: signing failed: Unusable secret key
> 

I found a way to get mutt-1.10.1 to work for me (as long as I disable
the use of gpgme):

unset pgp_check_gpg_decrypt_status_fd

in ~/.muttrc.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

After mutt-1.10.0_1 -> mutt-1.10.1 upgrade, gnupg fails

[David Wolfskill]

This is running:

FreeBSD g1-215.catwhisker.org 11.2-STABLE FreeBSD 11.2-STABLE #685  
r336523M/336541:1102501: Fri Jul 20 03:40:05 PDT 2018 
r...@g1-215.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

and after updating all installed ports to reflect the ports "head"
branch at r475002.

A symptom is that an attempt to send a signed, unencrypted message
yields a failure, with the messages:

| gpg: skipped "0x6757003D": Unusable secret key
| gpg: signing failed: Unusable secret key

This works on another machine (the one I'm using to send this
message), with the same gnupg/mutt setup, but running mutt-1.10.0_1.

I have not configured mutt to use gpgme, though I'm willing to try
it.  I recall that I needed to tweak ~/.muttrc a bit after the
gnupg-2.0 -> gnupg-2.1 update -- though that change was merely
commenting out the 'pgp_verify_command' line.

I note that a result of the mutt upgrade is that
/usr/local/share/examples/mutt/gpg.rc has changed, but that change
was merely to remove the pgp_decryption_okay setting (which I don't
have) and add 'set pgp_check_gpg_decrypt_status_fd'; I tried adding
that, to no avail.

Any hints or suggestions?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is providing aid and comfort to a regime that is hostile to US interests.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: unreliable pkg upgrade of pecl / pear packages after flavors

[David Wolfskill]

On Tue, Apr 03, 2018 at 01:59:50PM +0200, Mathieu Arnold wrote:
> On Mon, Apr 02, 2018 at 10:14:06PM +0200, Miroslav Lachman wrote:
> > UPDATING entry says it should be upgraded automatically but it was not.
> > 
> > "People using Poudriere 3.2+ and binary packages do not have to do
> > anything."
> 
> M, well, this sentence is partly right, and partly wrong.
> 
> If you install a PHP app, say wordpress, you do not have anything to do
> because pkg will install the new pecl package and remove the old ones.
> 
> On the other hand, if you install php/pear/pecl ports manually, you do
> have to rename them.
> 
> I will update the UPDATING entry.
> 

How would someone performing only binary package updates know to look at
ports/UPDATING, and how would that be done?  Such an installation may
well not have /usr/ports at all.

Mind, there is useful information in ports/UPDATING, some of which
applies at least as well to binary package updates -- e.g., the 20180401
entry re. mail/dovecot and mail/dovecot-pigeonhole, which mentions:

|   Modify your Dovecot conf.d/ files before spinning up 2.3.1. The
|   upgrading instructions are detailed here:
| 
| https://wiki2.dovecot.org/Upgrading/2.3


Perhaps I'm missing something obvious

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An investigator who doesn't make a perp nervous isn't doing his job.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Perl version change and ports/UPDATING

[David Wolfskill]

On Sat, Mar 31, 2018 at 04:23:54PM -0700, Kevin Oberman wrote:
> On Sat, Mar 31, 2018 at 7:25 AM, David Wolfskill 
> wrote:
> ... 
> > But "pkg updating -i" fails to display the 20180330 entry for me;
> > it does show entries for some(?) other ports I have installed:
> ...
> > Is the above a demostration of a problem with "pkg updating"?
> > Something else?
> ...
> I suspect thre issue is the handing of the wildcard (lang/perl5*). Either
> it's a bug or wildcards should not be allowed in UPDATING. There are LOTS
> of entries with asterisks, though, ome rather more complex such as:
> 20180308:
>   AFFECTS: */php* */pecl* */pear*
> BTW, that one should show up in "pkg updating -i" and does not, either.
> 

I finally(!) got around to unpacking the distribution files for
pkg-1.10.5; looking at src/updating.c, "pkg updating" uses either
strcasestr() or strstr() (depending on whether or not -i is specified)
for matching the origins of installed ports against the "AFFECTS" lines
in ports/UPDATING.

I see no code that would support anything other than literal string
matches -- no attempts to specify/use meta-characters; no globs;
no regular expressions.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An investigator who doesn't make a perp nervous isn't doing his job.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Perl version change and ports/UPDATING

[David Wolfskill]

While the actual change to the Perl version works fine for me, I
find that invoking "pkg updating" fails to display the 20180330
ports/UPDATING entry.  I got lucky, because I found out about the
change a different way.

I maintain /usr/ports as an SVN working copy, using a local private
mirror (updated nightly):

g1-215(11.1-S)[1] svn info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 466037
Node Kind: directory
Schedule: normal
Last Changed Author: mandree
Last Changed Rev: 466037
Last Changed Date: 2018-03-31 03:08:17 -0700 (Sat, 31 Mar 2018)

g1-215(11.1-S)[2] 


The 20180330 entry does exist in /usr/ports/UPDATIMG:

g1-215(11.1-S)[2] grep -i -B 2 -A 2 perl /usr/ports/UPDATING | head

20180330:
  AFFECTS: users of lang/perl5*
  AUTHOR: m...@freebsd.org

  The default Perl version has been switched to Perl 5.26.  If you are using
  binary packages to upgrade your system, you do not have anything to do, pkg
  upgrade will do the right thing.  For the other people, follow the
--

g1-215(11.1-S)[3] 


I have Perl installed:

g1-215(11.1-S)[3] pkg info -o perl5\*
perl5-5.26.1   lang/perl5.26
g1-215(11.1-S)[4] 


But "pkg updating -i" fails to display the 20180330 entry for me;
it does show entries for some(?) other ports I have installed:

g1-215(11.1-S)[4] pkg updating -i | head
20180319:
  AFFECTS: users of dns/dnsmasq
  AUTHOR: mand...@freebsd.org

  Note that with dnsmasq 2.79, some parts of the interface have changed in an
  incompatible way versus previous versions. This comprises changed recursion
  behaviour, signature support, a change for SIGINT (vs. SIGHUP) behaviour.

  Note especially that dnsmasq will no longer answer non-recursive queries
  unless it is marked authoritative!  Be sure to see the manual page for the
g1-215(11.1-S)[5] 


Is the above a demostration of a problem with "pkg updating"?
Something else?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
An investigator who doesn't make a perp nervous isn't doing his job.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: All those notes...

[David Wolfskill]

On Mon, Jan 08, 2018 at 09:39:56AM +1100, Greg 'groggy' Lehey wrote:
> 
> > This was accompanied by zillions of notes, warning me to "do this" and
> > "avoid doing that" etc.  Err, were those notes squirreled away somewhere,
> > or do I have to hope that I don't lose the window and its scrollback
> > buffer?
> 
> I pipe the output of pkg to a file.  It's worth the trouble.  I don't
> know any other way to keep track of what this particular instance did.
> The notes themselves are in the pkg-message file for the individual
> ports.
> .

My practice has been to run such commands within script(1).  (This iis
also helpful if I need to show someone else exactly what commands were
issued and what the responses were.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
A "Birther" calls himself a "a very stable genius" -- same level of truth? 

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

A note on updating security/gnupg20 -> gnupg

[David Wolfskill]

I had been using security/gnupg20 with mail/mutt, based on a
misunderstanding on my part (back when the security/gnupg20 port was
created).

Now that security/gnupg20 has been expired and removed, I had motivation
to look into the situation in more detail; I found that security/gnupg
(now at 2.2.4) works fine with mail/mutt -- if I made a change (in
~/.muttrc) to the way gpg is invoked.  E.g., I changed:

set pgp_decrypt_command="gpg2 --passphrase-fd 0 --no-verbose --batch --output - 
%f"

to

pgp_decrypt_command="gpg2 %?p?--passphrase-fd 0 --pinentry-mode=loopback? 
--no-verbose --batch --output - %f"

The salient differences appear to be the insertion of "%?p?" before
"--passphrase-fd 0" and the insertion of "--pinentry-mode=loopback?".


The changes to ~/.muttrc appear to have been sufficient (in my case) for
mutt to be able to use security/gnupg (vs. security/gnupg20) for
encryption and decryption of PGP-compatible email messages.


Finally, on the actual replacement: I did this on three systems; on two
of those, I update ports via portmaster; on the other, I update them
from a locally-built repository (via "pkg upgrade").

For the systems using portmaster, "portmaster -o security/gnupg
gnupg20-2.0.30_2" worked well.   (My thanks to Doug Barton and Stefan
Esser!)

When I ran "pkg upgrade" on the system I update that way, there was
no indication that the status of security/gnupg* had changed since
the previous update (one week ago -- shortly before the removal of
security/gnupg20).  I ended up performing "pkg delete security/gnupg20",
followed by "pkg install security/gnupg" -- which worked.  (I had
previously updated the list of packages to build on my build machine,
to replace security/gnupg20 by security/gnupg.)

My concern about that last point is that if I were only updating ports
via "pkg upgrade", I would not have known that security/gnupg20 no
longer existed (well, unless I read the svn-ports-head list, or polled
the svn log for ports/security/Makefile -- or some other
similarly-unlikely activity for someone updating via packages only).

Perhaps I'm overlooking something.


In any case: If you use mutt with security/gnupg20 and migrate to
security/gnupg, and find that you cannot decrypt encrypted messages any
more, you should check your ~/.muttrc: you probably need to change the
"gpg" (or "gpg2") invocations; in my experience, that is a necessary and
sufficient change to make encryption and decryption work again.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
A "Birther" calls himself a "a very stable genius" -- same level of truth? 

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: mail/mutt && security/gnupg (after gnupg20 -> gnupg) weirdness

[David Wolfskill]

I *think* the issue is that I needed to update ~/.muttrc for the change
in gnupg; in particular:

set pgp_decrypt_command="gpg --keyserver pgp.mit.edu --passphrase-fd 0 
--no-verbose --batch -o - %f"

was changed to

set pgp_decrypt_command="gpg2 %?p?--passphrase-fd 0 --pinentry-mode=loopback? 
--no-verbose --batch --output - %f"

(based on ).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If you want the best Fake News, go to the best source of it: Donald J. Trump.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

mail/mutt && security/gnupg (after gnupg20 -> gnupg) weirdness

[David Wolfskill]

I have been using mail/mutt & security/gnupg (latter switched to
security/gnupg20 back when gnupg20 port was created because of a
similar-looking issue to what's described in the first part of the
below narrative) for several years -- without enabling "gpgme" (in
case that turns out to be relevant).

As a result, I have a collection of messages that were sent to me that
contain information that was deemed suitable for encryption; I still
have occasion to refer to the contents of some of these messages, and
prefer to leave them stored in encrypted form when I am not actively
reading them.

This morning, during the daily update of installed ports on my
laptop, I saw:

===>>> The security/gnupg20 port moved to security/gnupg
===>>> Reason: Has expired: Will reach EOL upstream on 2017-12-31


OK.  I had vague memories that things didn't work very well last time
there was a "minor" upgrade to gnupg, so I deferred that part of the
upgrade until I could do a bit more research.

I soon found "Bug 196382 - security/gnupg breaks keyring on 2.1.1"
.  So I tried
the recipe listed in Comment 4, then verified that decryption still
worked (while gnupg20 was the version of gnupg that was installed).

That was successful, so I deleted security/gnupg20, then installed
security/gnupg; that done, I re-tried the decryption, which failed
("Could not decrypt PGP message"; "Could not copy message" -- these
messages from mutt).

I then re-did the recipe from Comment 4 (now that security/gnupg was
installed), then re-tried the decryption test; it (still) failed the
same way.

Trying the decryption again (under "ktrace -di") showed the following
messages being issued by gpg:

   "gpg: WARNING: no command supplied.  Trying to guess what you mean ..."

   "gpg: encrypted with 2048-bit RSA key, ID C8A5439CFA5A0A07, created 201\
5-11-29"

   "  "David H. Wolfskill "

   "gpg: public key decryption failed: Invalid IPC response"

   "gpg: decryption failed: No secret key"



Following a hint obtained by searching on the above (particularly
the "gpg: public key decryption failed: Invalid IPC response" message),
I logged in to a machine that still has security/gnupg20 and used

gpg -e /etc/rc.conf

to encrypt a copy of that file with me as a recipient.  Decrypting
worked (as expected).

I then copied the rc.conf.gpg from that machine to my laptop (which now
has security/gnupg installed) and attempted the decryption -- and it
worked.

Given that, I thought that perhaps the (re-)installation of mail/mutt
had been what got things working again; I was thus quite surprised when
(about 3.5 hrs. later) I got in to work and had need to decrypt a
message on my laptop, and it -- again -- failed as described above.

As a reality check, I then re-tried the decryption of rc.conf.gpg (from
above); that worked.

After a couple quick shakes of my head to help ensure that I wasn't
hallucinating, I tried reading an encrypted email message (on the
laptop) again... and this time, it worked.

In fact, going back to the first "mutt" invocation that failed at work,
merely requesting to read a message Just Worked -- my passphrase was not
requested (as I had entered it less than 2 hours earlier).

This leaves me wondering if all of the above means that before
attempting to decrypt an encrypted email message via mutt, one is
supposed to (first) use bare gpg to decrypt a file -- but that seems
ridiculous to thye point of hostility

Does anyone have insights, clues, or pointers to same to share?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If you want the best Fake News, go to the best source of it: Donald J. Trump.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Working on FLAVOR support in portmaster

[David Wolfskill]

On Tue, Dec 05, 2017 at 08:35:55AM +0100, Stefan Esser wrote:
> ...
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.

Thank you; that is encouraging.

> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.

That seems reasonable.

> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.

Also reasonable, IMO.

> 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?

I believe so: if for no other reason, one wishing to support such a
non-PKG_NG infrastructure can certainly use an older version of
portmaster.

> Regards, STefan
> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is an incompetent, lying bully who is unfit for any public office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Spam on -ports

[David Wolfskill]

On Fri, Oct 27, 2017 at 11:13:20AM +0200, Jan Bramkamp wrote:
> ...
> I would like to help fighting the spam problem on the FreeBSD.org 
> mailing lists. Can you put me in contact with the right people?
> 
> -- Jan Bramkamp

 would be the appropriate email address -- both
for offers of help and pointing out perceived issues (whether it's the
existence of spam, problems sending mail to a list, or just about
anything involving the email infrastructure at FreeBSD.org).

Peace,
david   (who has worn that hat, but is handing it off to others)
-- 
David H. Wolfskill  da...@catwhisker.org
Unsubstantiated claims of "Fake News" are evidence that the claimant lies again.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

graphics/netpbm update to netpbm-10.80.00

[David Wolfskill]

Empirical observation: environments that currently have an older
installation of graphics/netpbm already installed, and where the intent
is to update graphics/netpbm to netpbm-10.80.00 by building the port in
the environment with the older netpbm already installed (e.g., make,
portmaster, and portupgrade -- not within a jail or a chroot) may
benefit from deleting the old installed version before attempting the
in-place update.

Disclaimer: That's what worked for me, using portmaster.  In a couple of
days, I expect to be updating at least one system from custom-built
packages (built using poudriere); I expect that this will Just Work
(without the evasive maneuver of a preemptive "pkg delete -f
graphics/netpbm").  And there's another system I expect to update that
same day -- rather isolated from everything else -- where I expect to
use portmaster, and will need to perform said preemptive evasive
maneuver.

I mention it in the hope that the information will reduce the time spent
trying to figure this out: time is not one of the "more renewable
resources" we have.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
http://www.cbc.ca/news/opinion/donald-trump-playbook-1.4265374

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Status of portupgrade and portmaster?

[David Wolfskill]

On Mon, Oct 02, 2017 at 11:51:33AM -0700, Don Lewis wrote:
> On  2 Oct, Marco Beishuizen wrote:
> ...
> > I'm running 11.1-STABLE now, upgrading every few months or when there is 
> > an important security fix. Do I have to build a new system twice in that 
> > case (once my running system and once the poudriere jail)?
> 
> Yes, but at least the poudriere jail doesn't build the kernel bits.  The
> real pain point is that when you update the jail, the next bulk package
> build will toss all the previously built packages and force a full
> rebuild from scratch.  That makes sense if you believe that the contents
> of the jail affect the contents of the packages build using that jail.
> If you don't think that is true, then why bother to update the jail.
> 
> I stick to pretty much the same schedule as you for updating my -STABLE
> machines, though I'm doing it for 10.4-STABLE i386, 11.1-STABLE amd64
> and i386, and 12.0-CURRENT amd64.  I try to do weekly package update
> runs.
> 

With respect, that (building the world twice -- once for the host and
once for the poudriere jail) has not been my experience.

As described in 
and 
(particularly the "Postscript: Subsequent Maintenance" section at the
bottom of the latter page), the machine that runs poudriere gets its
stable/11 environment updated daily; it runs poudriere twice each week
(Saturday and Sunday), and the thus-refreshed local repository is used
weekly (on Sunday).

As a case in point, on Saturday last (2 days ago, as of this writing),
the host system was updated from:

FreeBSD 11.1-STABLE #469  r324085M/324100:1101505: Fri Sep 29 03:39:21 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC  amd64

to 

FreeBSD 11.1-STABLE #470  r324115M/324116:1101505: Sat Sep 30 03:41:57 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC  amd64

the ports working copy was updated from r450887 to r450972, and the
ensuing poudriere run recorded:

[11amd64-ports-home] [2017-09-30_10h55m37s] [committing:] Queued: 1091 Built: 
1091 Failed: 0Skipped: 0Ignored: 0Tobuild: 0 Time: 04:28:37


The following day, the host system was updated from:

FreeBSD 11.1-STABLE #470  r324115M/324116:1101505: Sat Sep 30 03:41:57 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC  amd64

to

FreeBSD 11.1-STABLE #471  r324138M/324155:1101505: Sun Oct  1 03:42:38 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC  amd64

the ports working copy was updated from r450972 to r451042, and the
ensuing poudriere run recorded:

[11amd64-ports-home] [2017-10-01_10h50m40s] [committing:] Queued: 183 Built: 
183 Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 0Time: 01:42:10


Disclaimer: I do not claim expertise in ports-system wrangling.
While I use poudriere to build packages for my systems that are
only updated weekly, I use portmaster for those that are updated
daily.  I make no claims of optimal ... anything, really.  What I
describe seems to generally work for me, but my approaches are
almost certainly not suitable for most folks.  Despite that, it may
be possible to learn things from what others have done, so I have
tried to document what I did; please feel free to use it -- possibly
as an example of what NOT to do. :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
http://www.cbc.ca/news/opinion/donald-trump-playbook-1.4265374

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: x11/nvidia-settings: poudriere fails; portmaster succeeds

[David Wolfskill]

On Sat, Aug 19, 2017 at 09:39:39AM -0700, Yuri wrote:
> On 08/19/17 06:01, David Wolfskill wrote:
> > In fairness, this may be an "apple vs. orange" comparison.  But it's
> > fairly unusual (in my experience) for poudriere to fail to build a port,
> > but when it's a port that I had just built successfully (using
> > portmaster) on my laptop... well, I thought it was worth mentioning.
> 
> What version is fails on?

The OS for the poudriere run was:

FreeBSD 11.1-STABLE #431  r322692M/322692:1101501: Sat Aug 19 03:43:54 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC  amd64

For the portmaster run, it was:

FreeBSD 11.1-STABLE #365  r322647M/322650:1101501: Fri Aug 18 03:52:30 PDT 2017 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64


The port was attempting to build nvidia-settings-384.59_1.

The Makefile shows r448102:

g1-252(11.1-S)[15] dirs
/usr/ports/x11/nvidia-settings 
g1-252(11.1-S)[16] grep BUILD Makefile
g1-252(11.1-S)[17] head -3 Makefile
# Created by: Alexander Nedotsukov 
# $FreeBSD: head/x11/nvidia-settings/Makefile 448102 2017-08-17 14:08:26Z 
swills $

g1-252(11.1-S)[18] svn info ../../
Path: /common/ports
Working Copy Root Path: /common/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 448295
Node Kind: directory
Schedule: normal
Last Changed Author: bsam
Last Changed Rev: 448295
Last Changed Date: 2017-08-19 03:28:29 -0700 (Sat, 19 Aug 2017)

g1-252(11.1-S)[19] 


> > gtk+-2.x/ctkgridlicense.c:42:10: fatal error: 'dbus/dbus.h' file not found
> > #include 
> >   ^
> > 1 error generated.
> 
> 
> It builds in poudriere 11.1 amd64 for me.

The apparent difference in behavior is curious.

> This means that it requires DBus at compile time, and it isn't in 
> BUILD_DEPENDS:
> 
> BUILD_DEPENDS=${LOCALBASE}/dbus/dbus.h:devel/dbus
> 
> 
> Yuri
> 

Thankk you for pointing that out.  As above, the Makefile as of r448102
appears to lack a BUILD_DEPENDS specification.  This may be confirmed at
https://svnweb.freebsd.org/ports/head/x11/nvidia-settings/Makefile?revision=448102&view=markup
 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If we wish to eliminate sources of Fake News, start at the top: D. Trump.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

x11/nvidia-settings: poudriere fails; portmaster succeeds

[David Wolfskill]

In fairness, this may be an "apple vs. orange" comparison.  But it's
fairly unusual (in my experience) for poudriere to fail to build a port,
but when it's a port that I had just built successfully (using
portmaster) on my laptop... well, I thought it was worth mentioning.

The whine in the poudriere log is:

...
cc -O2 -pipe  -fstack-protector -fno-strict-aliasing -fno-strict-aliasing 
-fno-omit-frame-pointer -Wformat=2 -Wno-unused-parameter 
-Wno-format-zero-length -DNV_BSD  -I/usr/local/include  -I . -I image_data -I 
libXNVCtrl -I XF86Config-parser/.. -I libXNVCtrlAttributes -I xpm_data -I 
common-utils -I common-unix/virtual-resolutions -I _out/FreeBSD_amd64 
-I/usr/local/include -D_THREAD_SAFE -pthread  -I /usr/include/dbus-1.0/ 
-DPROGRAM_NAME=\"nvidia-settings\" -fPIC -c XF86Config-parser/Generate.c -o 
_out/FreeBSD_amd64/Generate.o && cc -MM -O2 -pipe  -fstack-protector 
-fno-strict-aliasing -fno-strict-aliasing -fno-omit-frame-pointer -Wformat=2 
-Wno-unused-parameter -Wno-format-zero-length -DNV_BSD  -I/usr/local/include  
-I . -I image_data -I libXNVCtrl -I XF86Config-parser/.. -I 
libXNVCtrlAttributes -I xpm_data -I common-utils -I 
common-unix/virtual-resolutions -I _out/FreeBSD_amd64 -I/usr/local/include 
-D_THREAD_SAFE -pthread  -I /usr/include/dbus-1.0/ 
-DPROGRAM_NAME=\"nvidia-settings\" -fPIC XF86Config-parser/Generate.c | sed -e 
"s,: ,: $\(wildcard ," -e "s,\([^\\]\)$,\1)," -e "s;^Generate.o: ; 
_out/FreeBSD_amd64/Generate.o: ;" > _out/FreeBSD_amd64/Generate.d
gtk+-2.x/ctkgridlicense.c:42:10: fatal error: 'dbus/dbus.h' file not found
#include 
 ^
1 error generated.


which looks to me as if somehow nvidia-settings has a dependency on dbus
of which poudriere was unaware; more on that below (after I sketch the
environment).

I have two machines that have nightly-updated private mirrors of the
FreeBSD SVN src, ports, and doc repositories: my laptop and a "build
machine" ("freebeast").

As described in ,
I perform a source-based update of stable/11 on each of the machines
each morning; upon reboot and after "make delete-old-libs", I use
portmaster on each of these machines to update the installed ports to
match the state of the just-updated /usr/ports working copy.

The laptop only builds the world & its own custom kernel; freebeast runs
a GENERIC kernel and builds that, as well as kernels for the two
"production" machines.  On a regular basis (normally, each Sunday
morning), I update the production machines by installing the just-built
snapshot of stable/11 onto them, reboot, perform a "pkg updgrade", and
reboot again.

The production machines are configured to get their packages (for the
"pkg upgrade") from freebeast.

freebeast uses poudriere to build the packages.

Since I (normally) only update the production machines on Sunday, I
don't see much value in running poudriere every day.  On the other hand,
if I wait until Sunday (to get a week's worth of updates), that can take
a while, even with a reasonably fast machine.

So, as a compromise, I do the "weekly" package-building in two stages:
the first is on Saturday (as in, today), doing a "catch up" run for the
last 6 days of updates, then on Sunday -- usually! -- there's only a
small amount of work to get caught up.

Thus, the successful build of x11/nvidia-settings was on my laptop,
yesterday:

...
===>>> The following actions were performed:
Upgrade of nvidia-xconfig-378.13 to nvidia-xconfig-384.59
Upgrade of libuv-1.13.1 to libuv-1.14.0
Upgrade of cups-filters-1.13.5 to cups-filters-1.16.0
Upgrade of harfbuzz-1.4.7 to harfbuzz-1.4.8
Upgrade of harfbuzz-icu-1.4.7 to harfbuzz-icu-1.4.8
Upgrade of opusfile-0.8 to opusfile-0.9
Upgrade of nvidia-settings-378.13_1 to nvidia-settings-384.59_1

Command exit status: 0

freebeast runs (essentially) headless; it has no X11-related ports
installed at all.  So my next attempt to build x11/nvidia-settings
was on freebeast, but using poudriere -- which failed as described
above.

Checking (on my laptop) for ports on which nvidia-settings depends, I
see:

g1-252(11.1-S)[1] pkg info -d x11/nvidia-settings
nvidia-settings-384.59_1:
libXxf86vm-1.1.4_1
libXv-1.0.11,1
libXext-1.3.3_1,1
libX11-1.6.5,1
pango-1.40.6
gtk2-2.24.31
fontconfig-2.12.1,1
freetype2-2.8
libvdpau-1.1.1
mesa-libs-17.1.5
gdk-pixbuf2-2.36.6
cairo-1.14.8_1,2
jansson-2.10
glib-2.50.2_4,1
gettext-runtime-0.19.8.1_1
atk-2.24.0
g1-252(11.1-S)[2] 

And that list does not seem to mention any dbus-related ports.

So I *suspect* that the portmaster build was "successful" only by
accident (because portmaster builds in teh local enviornment, which
happened to already have dbus installed, so dbus/dbus.h was already
present -- even though not called out as a dependency), while poudriere
w

Re: lang/rust: failure to build stage0 tool rust-installer (amd64)

[David Wolfskill]

On Tue, Aug 08, 2017 at 02:30:44PM +0200, Jan Beich wrote:
> David Wolfskill  writes:
>> [whine about lang/rust failing to build...] 
> 
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221088
> 

Thanks; given the hints there, I was able to circumvent the problem (and
update the report to show what worked for me).

TL;DR: "sudo su -" seems to do the trick (as it removes the SUDO_*
environment variables).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Of the Trump White House activity, how much is "chaff?" (ref. RADAR)

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

lang/rust: failure to build stage0 tool rust-installer (amd64)

[David Wolfskill]

This is on my laptop, running:

FreeBSD g1-252.catwhisker.org 11.1-STABLE FreeBSD 11.1-STABLE #356  
r322216M/322217:1101501: Tue Aug  8 03:44:01 PDT 2017 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

using a ports working copy updated from r447489 to r447536:
g1-252(12.0-C)[4] svn info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 447536
Node Kind: directory
Schedule: normal
Last Changed Author: cpm
Last Changed Rev: 447536
Last Changed Date: 2017-08-08 02:12:27 -0700 (Tue, 08 Aug 2017)

(I point out the previous rr447489, as the installed ports had been
updated to that point successfully (yesterday).)

After updating base FreeBSD (ref. above "uname -a" outpout) & rebooting,
I ran "portmaster -ad" (within script), and was informed:

portmaster: All >> (4)
===>>> The following actions will be taken if you choose to proceed:
Upgrade p5-Error-0.17024 to p5-Error-0.17025
Upgrade firefox-54.0.1_1,1 to firefox-55.0,1
Install devel/cargo
Install lang/rust

===>>> Proceed? y/n [y] 

(Immediately following the previous -- successful -- update of
www/firefox, I had performed a "pkg delete lang/rust", as I had
been made quite aware that lang/rust does not build successully if
(an earlier version of) it is already installed.  That also deleted
devel/cargo; since they are only build dependencies for www/firefox
(in my environment), that seemed OK.)

I have placed the complete typescript in
; there is also
 available.

In any case, the distribution files seem OK:

...
===>  License APACHE20  MIT accepted by the user
===>   rust-1.19.0 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by rust-1.19.0 for building
===>  Extracting for rust-1.19.0
=> SHA256 Checksum OK for rust/rustc-1.19.0-src.tar.gz.
=> SHA256 Checksum OK for 
rust/2017-06-08/rustc-1.18.0-x86_64-unknown-freebsd.tar.gz.
=> SHA256 Checksum OK for 
rust/2017-06-08/rust-std-1.18.0-x86_64-unknown-freebsd.tar.gz.
=> SHA256 Checksum OK for 
rust/2017-06-08/cargo-0.19.0-x86_64-unknown-freebsd.tar.gz.
=> SHA256 Checksum OK for rust/rust-registry-1.19.0.tar.xz.
/bin/ln -sf 
/common/ports/distfiles//rust/2017-06-08/rustc-1.18.0-x86_64-unknown-freebsd.tar.gz
  /common/ports/lang/rust/work/rustc-1.19.0-src/build/cache/2017-06-08
...

Patching seemed OK:
...
===>  Patching for rust-1.19.0
===>  Applying FreeBSD patches for rust-1.19.0
===>   rust-1.19.0 depends on executable: cmake - found
===>   rust-1.19.0 depends on file: /usr/local/bin/FileCheck40 - found
===>   rust-1.19.0 depends on executable: gmake - found
===>   rust-1.19.0 depends on file: /usr/local/bin/python2.7 - found
===>   rust-1.19.0 depends on shared library: libedit.so.0 - found 
(/usr/local/lib/libedit.so.0)
===>  Configuring for rust-1.19.0
...

Configuring was apparently OK:
...
===>  Configuring for rust-1.19.0
===>   FreeBSD 10 autotools fix applied to 
/common/ports/lang/rust/work/rustc-1.19.0-src/src/vendor/lzma-sys/xz-5.2.3/build-aux/config.rpath
===>   FreeBSD 10 autotools fix applied to 
/common/ports/lang/rust/work/rustc-1.19.0-src/src/vendor/libssh2-sys/libssh2/config.rpath
===>   FreeBSD 10 autotools fix applied to 
/common/ports/lang/rust/work/.cargo/registry/src/github.com-1ecc6299db9ec823/libssh2-sys-0.2.6/libssh2/config.rpath
===>   FreeBSD 10 autotools fix applied to 
/common/ports/lang/rust/work/.cargo/registry/src/github.com-1ecc6299db9ec823/lzma-sys-0.1.4/xz-5.2.3/build-aux/config.rpath
/usr/bin/sed -E  -e 's,%PREFIX%,/usr/local,'  -e 
's,%SYSCONFDIR%,/usr/local/etc,'  -e 's,%MANDIR%,/usr/local/man,'  -e 
's,%PYTHON_CMD%,/usr/local/bin/python2.7,'  -e 's,%CHANNEL%,stable,'  -e 
's,%TARGET%,x86_64-unknown-freebsd,'  < 
/common/ports/lang/rust/files/config.toml  > 
/common/ports/lang/rust/work/rustc-1.19.0-src/config.toml
/usr/bin/sed -i.bak -e 's,%DOCS%,true,' 
/common/ports/lang/rust/work/rustc-1.19.0-src/config.toml
/usr/bin/sed -i.bak -e 's,%LLVM_CONFIG%,/usr/local/bin/llvm-config40,' 
/common/ports/lang/rust/work/rustc-1.19.0-src/config.toml
===>  Building for rust-1.19.0
...

Building... hmmm... I just noticed the "info" text; that seems... odd:
===>  Building for rust-1.19.0
cd /common/ports/lang/rust/work/rustc-1.19.0-src &&  /usr/bin/env 
HOME=/common/ports/lang/rust/work  /usr/local/bin/python2.7 
/common/ports/lang/rust/work/rustc-1.19.0-src/x.py build  --verbose  --config 
./config.toml  --jobs 8
info: looks like you are running this command under `sudo`
  and so in order to preserve your $HOME this will now
  use vendored sources by default. Note that if this
  does not work you should run a normal build first
  before running a command like `sudo make install`
extracting 
/common/ports/lang/rust/w

Re: devel/apr1: "make install" can't find apr_dbd_sqlite3-1.so

[David Wolfskill]

On Thu, Jul 13, 2017 at 05:35:05AM -0700, David Wolfskill wrote:
> Ref. PR <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220699>
> 

Ports r445645 seems to have addressed the issue(s) successfully.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If the meeting was innocuous, why was its purpose mischaracterized?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

devel/apr1: "make install" can't find apr_dbd_sqlite3-1.so

[David Wolfskill]

Ref. PR 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If the meeting was innocuous, why was its purpose mischaracterized?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: math/R: Build failure after PORTREVISION for shlib change

[David Wolfskill]

On Thu, Jun 29, 2017 at 12:39:50PM -0300, Joseph Mingrone wrote:
> ...
> With those options, the build succeeds in an 11.0-RELEASE-p1 jail.
> http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2017-06-28_16h53m48s/logs/R-3.4.0_2.log
> ... 
> Everything matches.  The successful build in poudriere even has the same
> line that generates the error for you.
> 
> /usr/local/bin/gcc-ar5 -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o 
> tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o 
> tre-mem.o tre-parse.o tre-stack.o xmalloc.o
> 
> Could you have something in your environment or in make.conf that's
> causing a problem?
> 

As expected, further attempts to build math/R on my laptop have
continued to fail as before -- and as mentioned, I ran a poudriere run,
where building the package for math/R worked.

That said, the line in the poudriere log that corresponds to the failing
invocation is a bit different in my case.  (I found a couple of small
options differences, such as paper size; I don't believe those have
anything to do with the observed differences, but I've corrected them
for tomorrow's poudriere run.)

The line in the failing case (with the immediately preceding line
for context):

...
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H   -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c xmalloc.c -o xmalloc.o
/usr/local/bin/gcc-ar5 -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o 
tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o 
tre-mem.o tre-parse.o tre-stack.o xmalloc.o
ar: unrecognized option `--plugin'


and in the successful poudriere run:

...
cc -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H-fpic  -O2 
-pipe  -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include 
-fno-strict-aliasing  -fvisibility=hidden -c xmalloc.c -o xmalloc.o
/usr/local/bin/ar -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o 
tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o 
tre-mem.o tre-parse.o tre-stack.o xmalloc.o


Looking (on the laptop) at plausible "ar" executables in /usr/local/bin,
I see:

g1-227(12.0-C)[3] (cd /usr/local/bin && ls -lTi gcc-ar* ar)
1850562 -r-xr-xr-x  2 root  wheel  6368928 Mar 23 05:10:40 2017 ar
1850780 -r-xr-xr-x  2 root  wheel25728 May  1 05:47:28 2017 gcc-ar49
1846261 -r-xr-xr-x  2 root  wheel26192 Jun 30 04:57:30 2017 gcc-ar5
g1-227(12.0-C)[4] 

Apparently "ar" was installed by binutils-2.28,1, while the gcc-ar*
were installed by gcc49-4.9.4_3 and gcc5-5.4.0_2, respectively.

Weird.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Congratulations on the sesquicentennial, Canada! :-)

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: math/R: Build failure after PORTREVISION for shlib change

[David Wolfskill]

On Thu, Jun 29, 2017 at 12:39:50PM -0300, Joseph Mingrone wrote:
> ...
> Everything matches.  The successful build in poudriere even has the same
> line that generates the error for you.

I may try ktracing the build

> /usr/local/bin/gcc-ar5 -cr libtre.a regcomp.o regerror.o regexec.o tre-ast.o 
> tre-compile.o tre-match-approx.o tre-match-backtrack.o tre-match-parallel.o 
> tre-mem.o tre-parse.o tre-stack.o xmalloc.o
> 
> Could you have something in your environment or in make.conf that's
> causing a problem?

g1-227(11.1)[1] grep -v '^#' /etc/make.conf
NET_SNMP_SYS_CONTACT="da...@catwhisker.org"
NET_SNMP_SYS_LOCATION="variable"
NET_SNMP_LOGFILE=/var/log/snmpd.log
NET_SNMP_PERSISTENTDIR=/var/net-snmp
SENDMAIL_MC=/etc/mail/laptop.mc
WITH_BSD_JDK=TRUE
WITHOUT_RUNTIME_CPUDETECTION=   YES
WITHOUT_CJK=YES
NO_SUID_XSERVER=YES
DEFAULT_VERSIONS+=linux=c6
INSTALL_AS_NCFTP=yes
OPTIONS_SET=OPTIMIZED_CFLAGS
DEFAULT_VERSIONS+=  perl5=5.24
FORCE_PKG_REGISTER= YES
PKG_NOCOMPRESS=1
g1-227(11.1)[2] 

> Joseph

I'll be trying a poudriere run Saturday morning, and will report
anything "interesting."

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do Congress's recent actions on health care qualify as "terrorist acts?"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: math/R: Build failure after PORTREVISION for shlib change

[David Wolfskill]

On Wed, Jun 28, 2017 at 04:36:18PM -0300, Joseph Mingrone wrote:
> Hi David,
> 
> So far I haven't been able to reproduce any problems in an
> 11.0-RELEASE-p1 jail.  Could you send your list of port options?  If I
> can't reproduce any issues with the same options turned on, I will ask
> you for a full build log.
> 
> Joseph

Thanks for taking a look.

g1-227(11.1)[2] make -C /usr/ports/math/R showconfig
===> The following configuration options are available for R-3.4.0_1:
 ICU=on: Unicode support via ICU
 INFO=on: GNU info manuals
 LDOUBLE=on: Long double data type
 LETTER=on: US letter paper
 LIBR=on: Shared R library
 MEMPROF=off: Memory profiling via Rprofmem() and tracemem()
 NLS=on: Native Language Support
 RPROF=on: R profiling via Rprof()
 X11=on: X11 graphics device
> Require GCC
 LTO=on: Use Link Time Optimization
 OPENMP=on: Parallel processing support via OpenMP
> Require X11
 GHOSTSCRIPT=on: Graphics device for bitmap files via Ghostscript
 JPEG=on: JPEG graphics device
 CAIROPANGO=on: Cairo graphics device and Pango multi-language text
 PNG=on: PNG graphics device
 TCLTK=on: Tcl/Tk GUI toolkit support
 TEXDOCS=on: Build/Install TeX-dependent documentation files
 TIFF=on: TIFF image format support
> Options available for the single BLAS: you have to select exactly one of 
them
 ATLAS=off: ATLAS BLAS implementation
 OPENBLAS=off: OpenBLAS BLAS implementation
 NETLIB=off: Netlib BLAS implementation
 RBLAS=on: Use R-bundled BLAS implementation
===> Use 'make config' to modify these settings
g1-227(11.1)[3] 

I also placed both "normal" and gzipped copies of the typescript
from the (multiple) portmaster runs in
; see R.log (or
R.log.gz).

(I had run portmaster; it built a few things, tried math/R & died.
I re-started portmaster, eliding math/R, but portmaster found it
anyway... though it didn't show up in the list until several other
ports were built successfully.  I then tried again, skipping both
math/R and databases/R-cran-DBI; all of the specified ports built
OK.  Then I tried just math/R & databases/R-cran-DBI; those failed
(as before).  I then specified 'MAKE_JOBS_UNSAFE=yes' in /etc/make.conf
& tried the laast run again; still failed.  Each time, I appended
to the typescript.)

Just in case it's relevant, as /usr/local/bin/gcc-ar5 is from gcc5-5.4.0_2:

g1-227(11.1)[5] make -C /usr/ports/lang/gcc5 showconfig
===> The following configuration options are available for gcc5-5.4.0_2:
 BOOTSTRAP=on: Build using a full bootstrap
 GRAPHITE=off: Support for Graphite loop optimizations
 JAVA=on: Java platform support
===> Use 'make config' to modify these settings

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Do Congress's recent actions on health care qualify as "terrorist acts?"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

math/R: Build failure after PORTREVISION for shlib change

[David Wolfskill]

Running:

FreeBSD g1-227.catwhisker.org 11.1-BETA3 FreeBSD 11.1-BETA3 #383  
r320438M/320450:1100514: Wed Jun 28 03:56:53 PDT 2017 
r...@g1-227.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

with /usr/ports working copy:
g1-227(11.1)[4] svn info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 444562
Node Kind: directory
Schedule: normal
Last Changed Author: jbeich
Last Changed Rev: 444562
Last Changed Date: 2017-06-28 02:58:37 -0700 (Wed, 28 Jun 2017)

(Repo is a local mirror, updated overnight.)

After updating all other installed ports and setting
'MAKE_JOBS_UNSAFE=yes', I tried (again) for math/R and
databases/R-cran-DBI; math/R fails:

...
making xmalloc.d from xmalloc.c
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c regcomp.c -o regcomp.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c regerror.c -o regerror.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c regexec.c -o regexec.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-ast.c -o tre-ast.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-compile.c -o tre-compile.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-match-approx.c -o tre-match-approx.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-match-backtrack.c -o tre-match-backtrack.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-match-parallel.c -o tre-match-parallel.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-mem.c -o tre-mem.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-parse.c -o tre-parse.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c tre-stack.c -o tre-stack.o
gcc5 -I. -I. -I../../../src/include -I../../../src/include -DLIBICONV_PLUG 
-I/usr/local/include -isystem /usr/local/include -DHAVE_CONFIG_H  -fopenmp 
-fpic  -O2 -pipe  -DLIBICONV_PLUG -fstack-protector 
-Wl,-rpath=/usr/local/lib/gcc5 -isystem /usr/local/include -fno-strict-aliasing 
-flto -fvisibility=hidden -c xmallo

Re: Should a package restart on upgrade itself

[David Wolfskill]

On Tue, Jun 27, 2017 at 06:29:24PM +0200, Matthias Fechner wrote:
> Dear all,
> 
> it is always a pain if pkg upgrade a lot of packages to restart all
> services to make sure update/security fixes are applied to all running
> services.
> 
> Is there an option in pkg that it restart services automatically or is
> it OK if I would add a post-install script to the packages (I maintain)
> that will include a "service foo restart"?
> 
> What is best practice here?
> 

I do not claim that this is "best practice."  But what I do, during my
weekly updates of my "production" systems (at home) is:

* "Clone" the active slice to the other slice.
* Build the world & suitable kernels on the build machine.
* Mount /usr/src and /usr/obj from the build machine.
* Set DESTDIR to a suitable directory on the other slice.
* make installkernel ${DESTDIR} && \
  mergemaster -U -u 0022 -p && \
  make installworld ${DESTDIR} && \
  mergemaster -F -U -u 0022 -i && \ 
  make delete-old ${DESTDIR}
* reboot from the other slice.

* Mount /usr/src and /usr/obj from the build machine.
* Stop all services that depend on 3rd-party software (ports/packages).
* pkg upgrade
* make delete-old-libs
* reboot

(I elided a few minor embellishments; the above are the essential steps.)

It seems to work for me.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
I look forward to voting against Trump again at the earliest opportunity.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[David Wolfskill]

On Fri, Jun 02, 2017 at 04:29:40PM +0200, Thierry Thomas wrote:
> ...
> But I have a naive question: if pkg supports flavours, and binary
> packages are built for your sets of options, is portmaster still
> relevant?
> 

Well, that depends... e.g., on one's set of requirements (and how they
are weighted).

In my own case, I believe portmaster is still relevant.  That said, I
doubt that many would have my particular set of requirements -- and that
of the few who might, very few would weight them at all similarly.

To provide a bit of context: On the systems where I use portmaster, I
also maintain private mirrors of the FreeBSD SVN repositories, which are
updated (only) overnight.  On a daily basis (on these machines -- one of
which is a designated "build machine"; the other is my laptop) I:
* Update the /usr/ports working copy.
* Update the stable/11 /usr/src working copy.
* Perform a src-based update to stable/11 (& reboot).
* While that is running, fetch the distfiles I'll be needing later
  (e.g. "portmaster -aF").
* Update all installed ports (e.g., "portmaster -ad").
* Update the "head" slice's /usr/src working copy.
* Reboot to the "head" slice.
* Perform a src-based update to head (& reboot).
* For the build machine, set the default boot slice to stable/11 & poweroff;
  for the laptop, reboot to stable/11, then use it for the rest of the day.

Please note that I am NOT recommending any of this to anyone else.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Looking forward to telling Mr. Trump: "You're fired!"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: pango not building under portmaster, holds back emacs (portmaster)

[David Wolfskill]

On Sun, May 21, 2017 at 04:55:57PM -0400, Lowell Gilbert wrote:
> I suspect this is a portmaster problem, but pango isn't building with X
> support because of:
> ../pango/pangoxft-render.h:31:10: fatal error: 'X11/Xft/Xft.h' file not found
> 
> This is only the current issue. I've been struggling for several days to
> get my graphics programs rebuilt, and I haven't seen any e-mail about
> it. Anyone have an idea what's going on?
> 

Not much of an idea; while I use portmaster to update the ports on
systems where I update base in-place via src update, I don't recall
encountering that -- and on one of those systems (my laptop), I update
the installed ports daily.

I find that /usr/local/include/X11/Xft/Xft.h was installed by
x11-fonts/libXft, so re-installing it may help.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: graphics/mesa-libs ... issues

[David Wolfskill]

On Sat, May 13, 2017 at 10:20:41AM -0700, David Wolfskill wrote:
> In my Saturday poudriere run, I encountered a failure in
> graphics/mesa-libs that I'm not understanding how to fix (or evade)
> after updating the ports working copy to r440771:
> 
> ...
> [00:00:00] >> Creating the reference jail... done
> [00:00:06] >> Mounting system devices for 11amd64-ports-home
> [00:00:06] >> Mounting ports/packages/distfiles
> [00:00:06] >> Stashing existing package repository
> [00:00:06] >> Mounting packages from: 
> /usr/local/poudriere/data/packages/11amd64-ports-home
> [00:00:06] >> Copying /var/db/ports from: 
> /tank/poudriere/etc/poudriere.d/home-options
> [00:00:07] >> Appending to make.conf: 
> /tank/poudriere/etc/poudriere.d/make.conf
> /etc/resolv.conf -> 
> /usr/local/poudriere/data/.m/11amd64-ports-home/ref/etc/resolv.conf
> [00:00:07] >> Starting jail 11amd64-ports-home
> [00:00:07] >> Logs: 
> /usr/local/poudriere/data/logs/bulk/11amd64-ports-home/2017-05-13_11h12m22s
> [00:00:07] >> Loading MOVED
> [00:00:07] >> Gathering ports metadata
> [00:00:07] >> MOVED: graphics/dri renamed to graphics/mesa-dri
> [00:00:07] >> MOVED: graphics/libGL renamed to graphics/mesa-libs
> [00:00:07] >> MOVED: graphics/libglapi renamed to graphics/mesa-libs
> [00:00:08] >> Warning: (graphics/mesa-libs): mkdir: 
> dqueue/graphics!mesa-libs: File exists
> [00:00:08] >> Warning: (graphics/mesa-libs): [00:00:08] >> Error: 
> gather_port_vars_port: Failed to add graphics/mesa-libs to depqueue
> [00:00:11] >> Calculating ports order and dependencies
> mkdir: deps/mesa-libs-17.0.4: File exists
> [00:00:11] >> Error: compute_deps_pkg: Error creating pool dir for 
> mesa-libs-17.0.4: There may be a duplicate origin in a category Makefile
> [00:00:11] >> Error: Fatal errors encountered calculating dependencies
> [00:00:11] >> Cleaning up
> [00:00:11] >> Unmounting file systems
> 
> 
> 
> Err...?  What sort of "evasive maneuver" is needed at this point?
> 
> Thanks!
> 

I finally(!) discovered that the issue was that my pkglist contained
explicit entries for a handful of the ports that were now rolled up into
graphics/mesa-libs.  The "evasive maneuver," therefore, was to remove
them, then re-start the "poudriere bulk" run, which appears to be
building stuff as I type:

load: 14.51  cmd: c++ 49175 [running] 0.69r 0.56u 0.02s 6% 44556k
[11amd64-ports-home] [2017-05-20_11h18m27s] [parallel_build:] Queued: 1061 
Built: 85   Failed: 0Skipped: 0Ignored: 0Tobuild: 976   Time: 
00:04:44
[01]: lang/python27configure   (00:00:48)
[02]: misc/help2manstarting(00:00:01)
[03]: devel/qt4-mocfetch   (00:00:31)
[04]: graphics/lcms2   configure   (00:00:35)
[05]: databases/gdbm   configure   (00:00:36)
[06]: security/ca_root_nss fetch   (00:00:05)
[07]: devel/libunistring   build   (00:01:42)
[08]: devel/icubuild   (00:01:01)
[00:04:47] >> Logs: 
/usr/local/poudriere/data/logs/bulk/11amd64-ports-home/2017-05-20_11h18m27s

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"[T]he president’s improper efforts to influence an ongoing investigation"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: mesa libs issue

[David Wolfskill]

On Sun, May 14, 2017 at 10:14:33PM +, Tatsuki Makino wrote:
> Hello.
> Does anyone reading this know how to upgrade more easily from below?
> 

What I would do:

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
portmaster -d graphics/mesa-libs graphics/mesa-dri
portmaster -ad

(Second step inserted because I found that if that's not done,
portmaster may try to update (e.g.) x11-toolkits/gtk30 before the mesa
stuff, not find the libraries that were deleted by the first step, then
whine & die.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Let's hope that the successor to this so-called POTUS will be an improvement.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: mesa libs issue

[David Wolfskill]

On Sat, May 13, 2017 at 05:54:10PM -0600, The Doctor wrote:
> 
> ===>  Installing for mesa-libs-17.0.4
> ===>  Checking if mesa-libs already installed
> ===>   Registering installation for mesa-libs-17.0.4 as automatic
> Installing mesa-libs-17.0.4...
> pkg-static: mesa-libs-17.0.4 conflicts with libEGL-17.0.3 (installs files 
> into the same place).  Problematic file: /usr/local/include/EGL/egl.h
> *** Error code 70
> 
> Stop.
> make[1]: stopped in /usr/ports/graphics/mesa-libs
> *** Error code 1
>  
> 
> And crash goes the msea-libs complie.

Well, no.  The compile was fine; it's the installation that choked.

> Can someone explain this?
> 

I managed -- eventually! -- to get through this by iterating through:

* pkg which /usr/local/include/EGL/egl.h
  This informed me that the file had been installed by libEGL-17.0.3.

* pkg delete -f libEGL-17.0.3

* (re-do the attempt to build/install graphics/mesa-libs; find that it
now whines about something else... re-do "pkg which"; "pkg delete -f"
that package; lather, rinse, repeat)

The short of it comes down to the equivalent of:

* pkg delete -f libEGL-17.0.3 libGL-17.0.3 libglesv2-17.0.3 gbm-17.0.3 
libglapi-17.0.3

(after which point mesa-libs-17.0.4 installed OK).

* pkg delete -f dri-17.0.3,2 

(after which point mesa-dri-17.0.4 installed OK).


Caveat: This was using portmaster.  My attempt to use poudriere to build
graphics/mesa-libs failed rather completely, as I noted earlier.  (Ref.
.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Let's hope that the successor to this so-called POTUS will be an improvement.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

graphics/mesa-libs ... issues

[David Wolfskill]

In my Saturday poudriere run, I encountered a failure in
graphics/mesa-libs that I'm not understanding how to fix (or evade)
after updating the ports working copy to r440771:

...
[00:00:00] >> Creating the reference jail... done
[00:00:06] >> Mounting system devices for 11amd64-ports-home
[00:00:06] >> Mounting ports/packages/distfiles
[00:00:06] >> Stashing existing package repository
[00:00:06] >> Mounting packages from: 
/usr/local/poudriere/data/packages/11amd64-ports-home
[00:00:06] >> Copying /var/db/ports from: 
/tank/poudriere/etc/poudriere.d/home-options
[00:00:07] >> Appending to make.conf: 
/tank/poudriere/etc/poudriere.d/make.conf
/etc/resolv.conf -> 
/usr/local/poudriere/data/.m/11amd64-ports-home/ref/etc/resolv.conf
[00:00:07] >> Starting jail 11amd64-ports-home
[00:00:07] >> Logs: 
/usr/local/poudriere/data/logs/bulk/11amd64-ports-home/2017-05-13_11h12m22s
[00:00:07] >> Loading MOVED
[00:00:07] >> Gathering ports metadata
[00:00:07] >> MOVED: graphics/dri renamed to graphics/mesa-dri
[00:00:07] >> MOVED: graphics/libGL renamed to graphics/mesa-libs
[00:00:07] >> MOVED: graphics/libglapi renamed to graphics/mesa-libs
[00:00:08] >> Warning: (graphics/mesa-libs): mkdir: 
dqueue/graphics!mesa-libs: File exists
[00:00:08] >> Warning: (graphics/mesa-libs): [00:00:08] >> Error: 
gather_port_vars_port: Failed to add graphics/mesa-libs to depqueue
[00:00:11] >> Calculating ports order and dependencies
mkdir: deps/mesa-libs-17.0.4: File exists
[00:00:11] >> Error: compute_deps_pkg: Error creating pool dir for 
mesa-libs-17.0.4: There may be a duplicate origin in a category Makefile
[00:00:11] >> Error: Fatal errors encountered calculating dependencies
[00:00:11] >> Cleaning up
[00:00:11] >> Unmounting file systems



Err...?  What sort of "evasive maneuver" is needed at this point?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Let's hope that the successor to this so-called POTUS will be an improvement.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: svn error: node conflict in /usr/ports/x11/xcb-proto/files

[David Wolfskill]

On Sun, Apr 23, 2017 at 09:32:08AM +, Thomas Mueller wrote:
> ...
> > > FreeBSD amelia2 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r286653M: Wed
> > Aug 12 15:25:51 UTC 2015
> > > root@amelia2:/usr/obj/usr/src/sys/SANDY11NC-NDIS amd64
> 
> > You should really update world/kernel first and then update all your ports.
> > At least some ports will probably fail on this old system.
> 
> > Herbert
> 
> I know or strongly believe I need to update world/kernel before updating 
> ports; that applies to NetBSD as well as FreeBSD.
> 
> I remember reading on this emailing list (ports) that ports might not build 
> if the underlying base system is not supported.
> 
> In any case, I would have to rebuild ports again after updating world/kernel.
> 
> I was stung on that matter at least once when I updated world/kernel, believe 
> I ran "make delete-old-libs", rendered many ports nonoperational, and had a 
> lot of rebuilding to do.
> 

The sequence in which I update the various components on systems:
* buildworld
* buildkernel (including kernel mods from ports)
* installkernel (including kernel mods from ports)
* mergemaster -p
* installworld
* mergemaster
* delete-old
* reboot
* delete any unwanted ports that are installed
* update all installed ports
* delete-old-libs
* add any ports not installed, but wanted
* reboot

I do this daily on a couple of machines; only weekly on others.  I
rarely have problems caused by the process.  (Note caveat, there. :-})

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

www/firefox, UPDATING, and "This platform lacks a functioning sem_open implementation..."

[David Wolfskill]

In case it helps someone else, I had encountered the symptoms cited in
UPDATING entry 20170411, but the UPDATING entry didn't exist at the
time.

So I poked around, and discovered that -- in my case -- the thing that
was apparently causing the problem was that lang/python27 had been built
with "SEM=off".

So I re-built lang/python27 after enabling its SEM option; that
done, www/firefox built without further incident.

(Checking the svn log for lang/python27/Makefile, it seems that SEM
had been changed to "default on" in r361735, 2014-07-14 00:20:40
-0700.  I had no known reason to change the setting at that time)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: pousdriere: "Failed ports: textproc/py-sphinx:build-depends"

[David Wolfskill]

On Sat, Apr 01, 2017 at 02:31:54PM +0200, Kurt Jaeger wrote:
> ...
> > This morning, however, textproc/py-sphinx apparently had "an issue";
> > that snowballed into 211 (out of 402) ports being skipped.
> 
> I've seen similar issues, here's what I did:
> 
> There's some thing happening with the py-setuptools port, which
> caused two versions to co-exists (py27-setuptools and some
> similarlooking py27-setuptools27 or alike).
> 
> I deleted all the setuptools pacakages from my pkg repo and restarted
> poudriere, and that worked fine.
> 

On Sat, Apr 01, 2017 at 03:35:08PM +0300, Andriy Gapon wrote:
> ...
> I experienced something like that a little while earlier.
> I think that it is related to the renaming of setuptools port (see UPDATING
> entry 20170316).  Apparently poudriere doesn't handle it well.  At least it
> didn't in my case.  I did something like the following to resolve the issue:
> # poudriere bulk -C devel/py-setuptools27
> # poudriere bulk -C devel/py-setuptools
> # poudriere bulk 
> 

Thank you both for responding with good informatiuon so quickly.

I saw the first response, and had already implemented it, before seeing
the second... and the approach worked.  (I suspect the second would have
done, as well.)

For completeness, here what I did:

freebeast(11.0-S)[1] cd 
/tank/poudriere/poudriere/data/packages/11amd64-ports-home
freebeast(11.0-S)[2] find . -name \*setup\*
./.real_1491046376/All/py27-setuptools27-32.1.0.txz
./.real_1491046376/All/py27-setuptools-32.1.0_1.txz
./.real_1489843480/All/py27-setuptools-32.1.0_1.txz
./.real_1489843480/All/py27-setuptools27-32.1.0.txz
./.real_1489924355/All/py27-setuptools27-32.1.0.txz
./.real_1489924355/All/py27-setuptools-32.1.0_1.txz
./.real_1490526523/All/py27-setuptools27-32.1.0.txz
./.real_1490526523/All/py27-setuptools-32.1.0_1.txz
./.real_1490445749/All/py27-setuptools-32.1.0_1.txz
./.real_1490445749/All/py27-setuptools27-32.1.0.txz
freebeast(11.0-S)[3] find . -name \*setup\* -print0 | xargs -0 rm
freebeast(11.0-S)[4] 

I then re-ran "poudriere bulk -j 11amd64 -p ports -z home -f 
/usr/local/etc/poudriere.d/11amd64-home-pkglist"; the result was:

[00:00:01] >> Creating the reference jail... done
[00:00:07] >> Mounting system devices for 11amd64-ports-home
[00:00:07] >> Mounting ports/packages/distfiles
...
[11amd64-ports-home] [2017-04-01_12h41m11s] [committing:] Queued: 240 Built: 
240 Failed: 0   Skipped: 0   Ignored: 0   Tobuild: 0Time: 03:15:59
[03:16:07] >> Logs: 
/usr/local/poudriere/data/logs/bulk/11amd64-ports-home/2017-04-01_12h41m11s
[03:16:07] >> Cleaning up
[03:16:07] >> Unmounting file systems
freebeast(11.0-S)[6] exit


Thank you, again!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

pousdriere: "Failed ports: textproc/py-sphinx:build-depends"

[David Wolfskill]

Usually, my poudriere runs are ... uneventful (which is a Good Thing).

This morning, however, textproc/py-sphinx apparently had "an issue";
that snowballed into 211 (out of 402) ports being skipped.

Checking the log directory, I see no hints about textproc/py-sphinx;
here's what I do see, starting with an excerpt of the typescript from
the poudriere run:

...
[00:01:01] >> [01][00:00:39] Finished ports-mgmt/pkg: Success
[00:01:01] >> [01][00:00:00] Building devel/libpthread-stubs
[00:01:01] >> [02][00:00:00] Building textproc/py-sphinx
[00:01:01] >> [03][00:00:00] Building misc/pciids
[00:01:01] >> [04][00:00:00] Building textproc/minixmlto
[00:01:01] >> [05][00:00:00] Building devel/glib20
[00:01:01] >> [06][00:00:00] Building devel/nspr
[00:01:01] >> [07][00:00:00] Building security/p5-Net-SSLeay
[00:01:01] >> [08][00:00:00] Building java/java-zoneinfo
[00:01:03] >> [08][00:00:02] Finished java/java-zoneinfo: Success
[00:01:03] >> [08][00:00:00] Building java/bootstrap-openjdk
[00:01:04] >> [04][00:00:03] Finished textproc/minixmlto: Success
[00:01:04] >> [04][00:00:00] Building lang/gcc
[00:01:05] >> [03][00:00:04] Finished misc/pciids: Success
[00:01:05] >> [03][00:00:00] Building devel/libpciaccess
[00:01:07] >> [02][00:00:06] Finished textproc/py-sphinx: Failed: 
build-depends
[00:01:07] >> [01][00:00:06] Finished devel/libpthread-stubs: Success
[00:01:07] >> [01][00:00:00] Building x11/libxcb
[00:01:07] >> [02][00:00:06] Skipping graphics/GraphicsMagick: Dependent 
port textproc/py-sphinx failed
[00:01:07] >> [02][00:00:06] Skipping graphics/ImageMagick: Dependent port 
textproc/py-sphinx failed
[00:01:07] >> [02][00:00:06] Skipping math/R: Dependent port 
textproc/py-sphinx failed

[00:17:52] >> Failed ports: textproc/py-sphinx:build-depends
[00:17:52] >> Skipped ports: accessibility/at-spi2-atk 
accessibility/at-spi2-core accessibility/atk accessibility/atkmm archivers/gcab 
archivers/snappy-java audio/alsa-plugins audio/libcanberra 
audio/libcanberra-gtk3 audio/sdl_mixer converters/R-cran-rjson 
databases/R-cran-DBI databases/R-cran-RMySQL databases/libgda5 
databases/libgda5-ui databases/rrdtool deskutils/gucharmap 
deskutils/notification-daemon devel/R-cran-Rcpp devel/R-cran-iterators 
devel/R-cran-itertools devel/R-cran-magrittr devel/R-cran-plyr 
devel/R-cran-proto devel/R-cran-reshape2 devel/R-cran-tibble 
devel/appstream-glib devel/automoc4 devel/cargo devel/cmake devel/doxygen 
devel/gconf2 devel/gobject-introspection devel/goffice devel/goffice010 
devel/gsettings-desktop-schemas devel/json-glib devel/libclc devel/libglade2 
devel/libgsf devel/libnotify devel/libsoup devel/llvm39 devel/llvm40 
devel/maven3 devel/py-gobject devel/py-gobject3 devel/qt4-assistant 
devel/qt4-designer devel/qt4-help devel/qt4-linguist devel/qt4-qt3support 
devel/sdl12 devel/sdl20 devel/tex-web2c editors/abiword editors/ted 
graphics/GraphicsMagick graphics/ImageMagick graphics/R-cran-RColorBrewer 
graphics/R-cran-colorspace graphics/R-cran-dichromat graphics/R-cran-ggplot2 
graphics/R-cran-munsell graphics/R-cran-scales graphics/cairo graphics/cairomm 
graphics/colord graphics/dri graphics/freeglut graphics/gbm graphics/gd 
graphics/gdk-pixbuf2 graphics/gegl graphics/gimp graphics/gimp-app 
graphics/graphviz graphics/gtk-update-icon-cache graphics/inkscape 
graphics/jasper graphics/libEGL graphics/libGL graphics/libGLU 
graphics/libepoxy graphics/libglapi graphics/libglesv2 graphics/libgphoto2 
graphics/libopenraw graphics/librsvg2 graphics/netpbm graphics/openjpeg 
graphics/openjpeg15 graphics/poppler graphics/poppler-glib graphics/py-cairo 
graphics/py-gimp graphics/qt4-opengl graphics/qt4-svg graphics/sdl_gfx 
graphics/sdl_image graphics/webp graphics/xfig graphics/xpaint graphics/xv 
java/icedtea-web java/openjdk7 java/openjdk8 lang/rust math/R 
math/R-cran-assertthat math/R-cran-gtable math/R-cran-labeling 
math/R-cran-lazyeval math/R-cran-zoo math/gnumeric multimedia/dvdauthor 
multimedia/ffmpeg multimedia/gstreamer multimedia/gstreamer-ffmpeg 
multimedia/gstreamer-plugins multimedia/gstreamer-plugins-good 
multimedia/gstreamer1 multimedia/gstreamer1-libav multimedia/gstreamer1-plugins 
multimedia/gstreamer1-plugins-good multimedia/libass multimedia/libdv 
multimedia/libquicktime multimedia/libva multimedia/mjpegtools 
multimedia/mplayer multimedia/phonon multimedia/pwcview multimedia/smpeg 
multimedia/transcode net-mgmt/unifi5 net-mgmt/wifimgr net/avahi-app net/geoclue 
net/glib-networking net/mtr net/wireshark print/cups 
print/ghostscript9-agpl-base print/ghostscript9-agpl-x11 print/gimp-gutenprint 
print/gutenprint print/gutenprint-base print/gutenprint-ijs print/gv 
print/harfbuzz print/tex-basic-engines print/tex-dvipsk print/tex-formats 
print/texlive-base print/texlive-texmf print/transfig security/R-cran-digest 
security/libsecret sysutils/consolekit sysutils/hal sysutils/policykit-gnome 
sysutils/p

Re: Upgrade of libpthread-stubs-0.3_6 to libpthread-stubs-0.4 -- ??!?

[David Wolfskill]

On Wed, Mar 29, 2017 at 03:51:35PM +0200, Walter Schwarzenfeld wrote:
> There is a PR
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218208
> 

OK; thanks.  Now that I have a working X11 environment, I'll update
that.

What I did to fix the problem (as I use portmaster to update ports on
the systems where I update the base system daily via sources):

portmaster `pkg shlib -R libpthread-stubs.so.0 | tail +2`

In my case, that affected:

===>>> The following actions were performed:
Re-installation of libxcb-1.12
Re-installation of gbm-13.0.5
Re-installation of libEGL-13.0.5

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Upgrade of libpthread-stubs-0.3_6 to libpthread-stubs-0.4 -- ??!?

[David Wolfskill]

On Wed, Mar 29, 2017 at 03:13:11PM +0200, Walter Schwarzenfeld wrote:
> /usr/ports/devel/libpthread-stubs/work/libpthread-stubs-0.4/README
> 
> Project description
> ---
> 
> Currently the project provides only a pkg-config [.pc] file, 
> pthread-stubs.pc.The latter contains the Cflags/Libs flags applicable to 
> programs/libraries
> that use only lightweight pthread API. See the next sections for the 
> reasoning
> and implementation details.
> 

Thank you for the quick response!

Wow.  That comes as rather a surprise.  (And since the "work" hierarchy
is transient, it would be a bit hard to find unless one knew to look
for it.)  Might an UPDATING entry be appropriate for this?

Unfortunately (for me, anyway), after looking at the file in question,
I remain clueless as to what I can do about ports that attempt to link
to libpthread-stubs.so.0 (such as xdm).

I suppose I could try rebuilding xdm; if that works, the circumvention
is sufficiently straightforward

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Upgrade of libpthread-stubs-0.3_6 to libpthread-stubs-0.4 -- ??!?

[David Wolfskill]

After performing the above upgrade (apparently "successfully"), I have
no libpthread-stubs.so.0:

From "pkg info --list-files devel/libpthread-stubs" on a system I have
yet to update:
libpthread-stubs-0.3_6:
/usr/local/lib/libpthread-stubs.a
/usr/local/lib/libpthread-stubs.so
/usr/local/lib/libpthread-stubs.so.0
/usr/local/lib/libpthread-stubs.so.0.0.0
/usr/local/libdata/pkgconfig/pthread-stubs.pc

From "pkg info --list-files devel/libpthread-stubs" on my laptop (after
the update):
libpthread-stubs-0.4:
/usr/local/libdata/pkgconfig/pthread-stubs.pc

This tends to make (e.g.) xdm rather unhappy.

Above was from a ports working copy at r437189, built on:
FreeBSD 11.0-STABLE #295  r316129M/316133:1100510: Wed Mar 29 05:05:10 PDT 2017 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

Any hints for recovery?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Procedural showstopper

[David Wolfskill]

On Sat, Feb 25, 2017 at 05:57:46AM -0700, The Doctor wrote:
> portmaster -a
> ...
> ===>>> The devel/libc++ port has been deleted: Obsolete, all supported 
> FreeBSD versions have libc++ in the base system
> ===>>> Aborting update
> 
> Checked the UPDATING file , not method of procedure noted.
> 
> What needs to be done so that portmaster -a can procede?
> 

pkg delete devel/libc++

If you have devel/libcxxrt installed, delete it as well.

In general, if you have a port installed that the ports system no longer
supports, that is not required by any other software you have installed,
and that you don't need for your own reasons, you should be able to
merely delete it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: The future of portmaster

[David Wolfskill]

On Thu, Feb 16, 2017 at 12:08:52PM +0100, Luca Pizzamiglio wrote:
> Hi all,
> 
> portmaster, a tool used/loved/hated, is almost in abandoned state.
> ...
> So I decided to spend some time to look at it and to work on it.
> 

Thank you!

(I'll take a look at your work later; I'm in the middle of buildworld &
friends now.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Question on upgrading ports after 9.3->10.3

[David Wolfskill]

On Sun, Feb 12, 2017 at 02:05:26PM +1100, Dave Horsfall wrote:
> Me again :-)  I finally got around to following the notes that David 
> Wolfskill kindly provided (thanks!) and apart from some oddity about 
> "httpd" requiring a missing "libdb-4.2.so.2" (which will get rebuilt 
> anyway), I'm a bit wary of this:
> 
> 7. Back up any files in /usr/local that you wish to save [...]
> 8. Manually check /usr/local [...] to make sure that they are really 
>empty.
> 
> Errm, why?  Is it going to clean out /usr/local from under my feet?  If 
> so, then that's a bit rude...  Because of disk space limitations, I've got 
> /usr/ports -> /usr/local/ports (/usr/local is a separate file system).  
> And then there's all my private stuff...  I think it means "save any local 
> configuration files etc"; if so, it could be better phrased.
> 

My interpretation is that the concerning directives (copied form the
tail end of the portmaster(8) man page) are referring to subdirectories
of /usr/local that installation of ports may modify -- e.g, bin, etc,
lib, libexec, sbin; probably a few others.  I have no reason to belive
that /usr/local/ports will be harmed... at least, unless something goes
wrong. :-/

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Daily update issue

[David Wolfskill]

On Wed, Feb 01, 2017 at 08:27:30AM -0700, The Doctor wrote:
> ...
> > * sudo pkg delete linux-c6-qt47-4.7.2_3 
> > x11-themes/linux-c6-hicolor-icon-theme
> >   which removed the problem.
> >
> 
> No dice here.
> 
> I just get blanks.
> 

If you have it installed, but nothing depends on it, you should be able
to just delete it if you don't want it installed any more.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Daily update issue

[David Wolfskill]

On Wed, Feb 01, 2017 at 07:54:43AM -0700, The Doctor wrote:
> 1)
> 
> 
> ===>>> Returning to update check of installed ports
> 
> 
> ===>>> The x11-themes/linux-c7-hicolor-icon-theme port has been deleted: 
> Merged into linux_base port
> ===>>> Aborting update
> 
> How to fix

What I did:

* pkg info -r x11-themes/linux-c7-hicolor-icon-theme
  which told me that linux-c6-qt47-4.7.2_3 was the only port that
  required x11-themes/linux-c7-hicolor-icon-theme.

* pkg info -r linux-c6-qt47-4.7.2_3
  which told me that no installed ports depended on
  linux-c6-qt47-4.7.2_3.

* sudo pkg delete linux-c6-qt47-4.7.2_3 x11-themes/linux-c6-hicolor-icon-theme
  which removed the problem.

>... 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Failure to build x11/nvidia-driver-340 kmod in head @r312812

[David Wolfskill]

On Thu, Jan 26, 2017 at 04:52:34AM -0800, David Wolfskill wrote:
> ...
> cc  -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"340.101\" 
> -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 
> -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -UDEBUG -U_DEBUG -DNDEBUG  
> -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I. -I. -I/usr/src/sys -fno-common  
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -MD  
> -MF.depend.nvidia_acpi.o -MTnvidia_acpi.o -mcmodel=kernel -mno-red-zone 
> -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables 
> -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls 
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
> -Winline -Wcast-qual -Wundef -Wno-pointer-sign 
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
> -fdiagnostics-show-option -Wno-unknown-pragmas 
> -Wno-error-tautological-compare -Wno-error-empty-body 
> -Wno-error-parentheses-equality -Wno-error-unused-function 
> -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
> -std=iso9899:1999 -c nvidia_acpi.c -o nvidia_acpi.o
> In file included from nvidia_acpi.c:14:
> In file included from ./nv-freebsd.h:109:
> /usr/src/sys/sys/capability.h:41:2: error: this file includes 
>  which is deprecated [-Werror,-W#warnings]
> #warning this file includes  which is deprecated
>  ^
> 1 error generated.
> *** Error code 1
> 

danfe@ has fixed this via r432548 -- thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Failure to build x11/nvidia-driver-340 kmod in head @r312812

[David Wolfskill]

This is running:
FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #236  
r312749M/312749:1200020: Wed Jan 25 04:42:36 PST 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

after updating source to r312812, with ports (head) @432483.

The issue arose during a normally-routine rebuild of the
x11/nvidia-driver-340 kernel module (by virtue of:

PORTS_MODULES=x11/nvidia-driver-340

in /etc/src.conf, and appears to be because inclusion of sys/capability.h
is (now?) deprecated, and generates a warning:

...
===>  Configuring for nvidia-driver-340-340.101
===>  Building for nvidia-driver-340-340.101
===> src (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/acpica/acpi_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
:> opt_acpi.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q
awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h
:> opt_global.h
cc  -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"340.101\" -D__KERNEL__ 
-DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing 
-mno-red-zone -mcmodel=kernel -UDEBUG -U_DEBUG -DNDEBUG  -Werror -D_KERNEL 
-DKLD_MODULE -nostdinc  -I. -I. -I/usr/src/sys -fno-common  
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -MD  
-MF.depend.nvidia_acpi.o -MTnvidia_acpi.o -mcmodel=kernel -mno-red-zone 
-mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
-fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -c nvidia_acpi.c -o nvidia_acpi.o
In file included from nvidia_acpi.c:14:
In file included from ./nv-freebsd.h:109:
/usr/src/sys/sys/capability.h:41:2: error: this file includes 
 which is deprecated [-Werror,-W#warnings]
#warning this file includes  which is deprecated
 ^
1 error generated.
*** Error code 1

Stop.
make[6]: stopped in 
/common/S4/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.101/src
*** Error code 1

Stop.
make[5]: stopped in 
/common/S4/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.101
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
.


In the short term, perhaps warning-generation might be persuaded
to be non-fatal for building x11/nvidia-driver-340 -- at least,
until that port is modified to not generate the warning?  How might
I do that?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: devel/cargo build failure

[David Wolfskill]

On Tue, Jan 24, 2017 at 06:33:29PM +0100, Mathieu Arnold wrote:
> Le 24/01/2017 à 16:52, Bob Willcox a écrit :
> > When trying to build devel/cargo I get this error:
> >
> > /xports/Mk/Scripts/checksum.sh: cannot open 
> > 2016-11-02/cargo-nightly-x86_64-unknown-freebsd.tar.gz: No such file or 
> > directory
> > *** Error code 2
> >
> > Stop.
> > make: stopped in /xports/devel/cargo
> >
> > Anyone have any ideas why and what I can do to overcome it?
> 
> Ok, so, the port changed the directory this file is fetched in, to fix
> the problem, you'll need to remove the
> cargo-nightly-x86_64-unknown-freebsd.tar.gz from /usr/ports/distfiles
> (or whereever your distfiles are)
> 

Thanks -- that worked for me.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: devel/cargo build failure

[David Wolfskill]

On Tue, Jan 24, 2017 at 09:52:41AM -0600, Bob Willcox wrote:
> When trying to build devel/cargo I get this error:
> 
> /xports/Mk/Scripts/checksum.sh: cannot open 
> 2016-11-02/cargo-nightly-x86_64-unknown-freebsd.tar.gz: No such file or 
> directory
> *** Error code 2
> 
> Stop.
> make: stopped in /xports/devel/cargo
> 
> Anyone have any ideas why and what I can do to overcome it?
> 
> Thanks,
> Bob
> 

No actual suggestion, but I'll confirm that I experienced the same
failure (with a ports working copy @r432320).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Correct order when upgrading to 11.0 Release with Poudriere

[David Wolfskill]

You could also (take backups at suitable points along the way and):
* Install the misc/compat10x port.
* Upgrade the base FreeBSD system (i.e., not ports) from 10.x to 11.
  Your ports SHOULD all still work at this point, because of the compat
  10x libraries the compoat10x port installed.
* As time permits, use your favorite package-building tool to build
  custom packages.
* Once all the packages are built, replace all of the installed ports
  with the newly-built packages.
* Once you're happy with the way things are working, remove the
  misc/compat10x port (as long as nothing needs it -- which SHOULD
  be the case by this point).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

"Failed: fetch" for emulators/wine-staging

[David Wolfskill]

My Sunday poudriere run reported a (rare) failure:

[00:01:21] >> [05][00:00:55] Finished build of emulators/wine-staging: 
Failed: fetch

So I tried a manual fetch:

freebeast(11.0-S)[3] cd /usr/ports/emulators/wine-staging
freebeast(11.0-S)[4] sudo make fetch
Password:
===>  License LGPL21 LGPL3 accepted by the user
===>   wine-staging-2.0.r4_1,1 depends on file: /usr/local/sbin/pkg - found
=> wine-2.0-rc4.tar.bz2 doesn't seem to exist in 
/net/grundoon/mnt/tank/ports/distfiles/.
=> Attempting to fetch 
http://downloads.sourceforge.net/project/wine/Source/wine-2.0-rc4.tar.bz2
wine-2.0-rc4.tar.bz2  100% of   22 MB  617 kBps 00m37s
=> v2.0-rc4.tar.gz is not in 
/net/grundoon/mnt/tank/ports/emulators/wine-staging/../wine-devel/distinfo.
=> Either 
/net/grundoon/mnt/tank/ports/emulators/wine-staging/../wine-devel/distinfo is 
out of date, or
=> v2.0-rc4.tar.gz is spelled incorrectly.
*** Error code 1

Stop.
make: stopped in /net/grundoon/mnt/tank/ports/emulators/wine-staging
freebeast(11.0-S)[5] cat 
/net/grundoon/mnt/tank/ports/emulators/wine-staging/../wine-devel/distinfo
TIMESTAMP = 1483802538
SHA256 (wine-2.0-rc4.tar.bz2) = 
e067b870a8c55fdf0574ec3a19f385ef06ed69cc382aad5a17690ab5ad90dab2
SIZE (wine-2.0-rc4.tar.bz2) = 23606278
freebeast(11.0-S)[6]

This is with a ports tree:
freebeast(11.0-S)[6] svn info /usr/ports
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: file:///svn/freebsd/ports/head
Relative URL: ^/head
Repository Root: file:///svn/freebsd/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 430862
Node Kind: directory
Schedule: normal
Last Changed Author: wen
Last Changed Rev: 430862
Last Changed Date: 2017-01-08 03:22:15 -0800 (Sun, 08 Jan 2017)

freebeast(11.0-S)[7]

(Though now that I look, I'm not sure why I have poudriere trying to
build emulators/wine-staging; I don't seem to have it installed
anywhere  I probably was trying to use it at one point)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Epistemology for post-truthers: How do we select parts of reality to ignore?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

"make install" appears to silently fail to install some files if $LOCALBASE is a symlink

[David Wolfskill]

On Fri, Nov 18, 2016 at 01:32:47PM -0800, David Wolfskill wrote:
> ...
> A correspondent pointed out
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214381 to me -- looks
> as if this mode of failure may be "expected" when /usr/local is a
> symlink to a file system other than the one where /usr resides.
> (Perhaps I'll try setting up a system where /usr/local/ is a mount point
> for a separate file system, as well.)
> ...

I managed to "stub my toe" on additional ports that exhibited this
behavior this morning -- among them, lang/gcc and devel/git.

I have updated the above-cited bug report with a little shell script I
cobbled up that (despite its unfortunate name) will check specified
installed ports/packages and report if any are determined to lack one or
more files that are supposed to have been installed.

Folks who have a symlink for /usr/local (or whatever $LOCALBASE
expands to) and who rely on "make install" to install ports might
want to take a look: I was a bit surprised at the number of affected
ports.  (Note that portmaster uses "make install"; I would expect that
portupgrade does, as well.)

A circumvention (as mentioned in the bug report) is to:
"make clean package deinstall && pkg add work/pkg/* && make clean"
within the port directory.

Checking through a typescript from work, I *think* this showed up
between 25 September - 02 October.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Ref. 08 Nov 2016, let's see if the "winners" actually deliver on their slogans.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: devel/llvm38 install seems to be missing files (e.g., FileCheck)

[David Wolfskill]

On Sat, Nov 05, 2016 at 09:55:50AM -0700, David Wolfskill wrote:
> ...
> > >> llvm38/bin/FileCheck is not actually installed?
> > > 
> > > not sure, if I missed something in your postings.
> > > 
> > > On my boxes, all recent FreeBSD 12.0-CURRENT amd64, the port
> > > devel/llvm38 installed FileCheck as expected, in the two places
> > > /usr/local/llvm38/bin/ and /usr/local/bin/.
> > 
> > It's installed into /usr/local/bin with a version number suffix, e.g.:
> > 
> > $ pkg info -l llvm38|grep FileCheck
> > /usr/local/bin/FileCheck38
> > /usr/local/llvm38/bin/FileCheck
> > /usr/local/man/man1/FileCheck38.1.gz
> > /usr/local/share/doc/llvm38/llvm/html/CommandGuide/FileCheck.html
> > 
> > /usr/local/share/doc/llvm38/llvm/html/_sources/CommandGuide/FileCheck.txt
> > 
> > Maybe that's the reason rust can't find it in OP's case?  (It works just 
> > fine for me, btw.)
> > 
> 
> I just re-ran "portmaster devel/llvm38" under script(1) (along with a
> bit of additional trivia, such as results from "ls -lT
> /usr/local/llvm38/bin" before and after the portmaster run (showing the
> distinct lack of "FileCheck" in either case)
> 
> I have placed the typescript at
> <http://www.catwhisker.org/~david/FreeBSD/ports/llvm38_test.txt>;
> there's a gzipped copy (llvm38_test.txt.gz) available, as well.
> 
> In particular, I believe this result is salient:
> ... 
> 
> [In this environment, the machine has 4 individually-bootable slices,
> each of which has its own /usr file system when the slice in question
> is the boot slice.  For each of the 4, /usr/ports is a symlink to
> /common/ports -- the file system at /common being mounted "the same"
> regardless of boot slice.)
> 

A correspondent pointed out
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214381 to me -- looks
as if this mode of failure may be "expected" when /usr/local is a
symlink to a file system other than the one where /usr resides.
(Perhaps I'll try setting up a system where /usr/local/ is a mount point
for a separate file system, as well.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Ref. 08 Nov 2016, let's see if the "winners" actually deliver on their slogans.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: best time to sync

[David Wolfskill]

On Fri, Nov 18, 2016 at 09:36:36AM -0700, Gary Aitken wrote:
> ...
> ...
> >> Can someone tell me what the best time to synchronize ports is,
> >> in terms of having a consistent ports tree?
> ...
> I'm interested in a consistent ports tree for build purposes.  I want
> updates, but I want the tree to be consistent enough to build.  In
> the past I have sync'd at less than ideal times and things did not
> build as a result.  I understand this is always a possibility, but
> was wondering if there was a time when it was most likely consistent.
> For example, is a weekly build done on the ports tree starting at a 
> particular day and time?  Daily?
> 

Of the possibly-relevant things I do, the one that comes to mind is that
I maintain a local private mirror of the FreeBSD SVN ports repository.
(I also maintain one each for src and doc, but that's veering
off-topic.)

I synchronize my mirror overnight (in 2 passes -- though that's a legacy
from when I used CVSup, and was because of the huge amount of time spent
when a new tag was laid down; with svn, that's really not an issue).  In
my case, the sync runs at about 03:30 hrs. US/Pacific.

That done, I can make my ports working copy follow head or a quarterly
branch as I see fit -- though in practice, I choose follow head.  (I
also update the base system frequently (daily), and follow that by
updating all installed ports on the laptop I use for day-to-day use.
That's probably something folks ought to think long and hard about
before actually doing it: it works for me, but it's not for everyone.)

And the repository is thus stable while I'm awake, which I find useful.
On the other hand, if someone commits a change I need just after I
synchronized for the day, well... that's awkward.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Ref. 08 Nov 2016, let's see if the "winners" actually deliver on their slogans.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: devel/llvm38 install seems to be missing files (e.g., FileCheck)

[David Wolfskill]

On Sat, Nov 05, 2016 at 05:08:46PM +0100, Dimitry Andric wrote:
> On 05 Nov 2016, at 16:58, Rainer Hurling  wrote:
> ... 
> >> Am I incorrect in thinking that devel/llvm38 has a problem, though, in
> >> that "%%LIT%%llvm38/bin/FileCheck" is in that port's pkg-plist, and
> >> llvm38/bin/FileCheck is found in the staging directory, but
> >> llvm38/bin/FileCheck is not actually installed?
> > 
> > not sure, if I missed something in your postings.
> > 
> > On my boxes, all recent FreeBSD 12.0-CURRENT amd64, the port
> > devel/llvm38 installed FileCheck as expected, in the two places
> > /usr/local/llvm38/bin/ and /usr/local/bin/.
> 
> It's installed into /usr/local/bin with a version number suffix, e.g.:
> 
> $ pkg info -l llvm38|grep FileCheck
>   /usr/local/bin/FileCheck38
>   /usr/local/llvm38/bin/FileCheck
>   /usr/local/man/man1/FileCheck38.1.gz
>   /usr/local/share/doc/llvm38/llvm/html/CommandGuide/FileCheck.html
>   
> /usr/local/share/doc/llvm38/llvm/html/_sources/CommandGuide/FileCheck.txt
> 
> Maybe that's the reason rust can't find it in OP's case?  (It works just fine 
> for me, btw.)
> 

I just re-ran "portmaster devel/llvm38" under script(1) (along with a
bit of additional trivia, such as results from "ls -lT
/usr/local/llvm38/bin" before and after the portmaster run (showing the
distinct lack of "FileCheck" in either case)

I have placed the typescript at
;
there's a gzipped copy (llvm38_test.txt.gz) available, as well.

In particular, I believe this result is salient:

albert(11.0-S)[18] grep -n '[Ii]nstall.*FileCheck' llvm38_test.txt
77: LIT=on: Install lit and FileCheck test tools
7359:-- Installing:
/common/ports/devel/llvm38/work/stage/usr/local/llvm38/share/doc/llvm/html/_sources/CommandGuide/FileCheck.txt
7482:-- Installing:
/common/ports/devel/llvm38/work/stage/usr/local/llvm38/share/doc/llvm/html/CommandGuide/FileCheck.html
7658:-- Installing:
/common/ports/devel/llvm38/work/stage/usr/local/llvm38/share/man/man1/FileCheck.1
7807:install  -s -m 555
/common/ports/devel/llvm38/work/.build/bin/FileCheck
/common/ports/devel/llvm38/work/stage/usr/local/llvm38/bin/
albert(11.0-S)[19] 


[In this environment, the machine has 4 individually-bootable slices,
each of which has its own /usr file system when the slice in question
is the boot slice.  For each of the 4, /usr/ports is a symlink to
/common/ports -- the file system at /common being mounted "the same"
regardless of boot slice.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: devel/llvm38 install seems to be missing files (e.g., FileCheck)

[David Wolfskill]

On Sat, Nov 05, 2016 at 05:26:33AM -0700, David Wolfskill wrote:
> ...
> I circumvented the problem: ...
> 
> g1-252(11.0-S)[20] sudo cp -p !$ /usr/local/llvm38/bin/
> sudo cp -p work/stage/usr/local/llvm38/bin/FileCheck /usr/local/llvm38/bin/
> g1-252(11.0-S)[21]
> 
> That done, lang/rust built.
> 
> My build machine is doing the first of its weekend poudriere runs
> as I type; if that shows anything relevant with respect to lang/rust
> and devel/llvm38, I'll follow up.
> 

Turns out that "PORT_LLVM" is, by default, off; I had turned it on since
I had other reasons to need llvm38 anyway.

And since I only use lang/rust as a build dependency (e.g., for
www/fierfox), I had not specified any non-default options for the
poudriere build.  Thus, poudriere had built rust using the "bundled"
llvm38, which apparently has FileCheck in the place where the rust
config looks for it.  So poudriere didn't have an issue building
www/firefox (which required lang/rust).

Am I incorrect in thinking that devel/llvm38 has a problem, though, in
that "%%LIT%%llvm38/bin/FileCheck" is in that port's pkg-plist, and
llvm38/bin/FileCheck is found in the staging directory, but
llvm38/bin/FileCheck is not actually installed?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: devel/llvm38 install seems to be missing files (e.g., FileCheck)

[David Wolfskill]

On Thu, Nov 03, 2016 at 05:50:07AM -0700, David Wolfskill wrote:
> After seeing that lang/rust failed to build again today (it had also
> failed yesterday), I decided to actually check the typescript file (from
> the portmaster run) to see if I could figure out what was wrong.
> 

I circumvented the problem: I noticed that devel/llvm38 still had its
"work" directory, so I looked ini there:

g1-252(11.0-S)[14] find work -name FileCheck
work/llvm-3.8.1.src/test/FileCheck
work/llvm-3.8.1.src/utils/FileCheck
work/.build/utils/FileCheck
work/.build/bin/FileCheck
work/stage/usr/local/llvm38/bin/FileCheck
g1-252(11.0-S)[15] 

So FileCheck is getting staged, just not actually installed.

After poking around a bit more:

g1-252(11.0-S)[19] file work/stage/usr/local/llvm38/bin/FileCheck
work/stage/usr/local/llvm38/bin/FileCheck: ELF 64-bit LSB executable, x86-64, 
version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for 
FreeBSD 11.0 (1100506), FreeBSD-style, stripped
g1-252(11.0-S)[20] sudo cp -p !$ /usr/local/llvm38/bin/
sudo cp -p work/stage/usr/local/llvm38/bin/FileCheck /usr/local/llvm38/bin/
g1-252(11.0-S)[21]

That done, lang/rust built.

My build machine is doing the first of its weekend poudriere runs
as I type; if that shows anything relevant with respect to lang/rust
and devel/llvm38, I'll follow up.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

devel/llvm38 install seems to be missing files (e.g., FileCheck)

[David Wolfskill]

After seeing that lang/rust failed to build again today (it had also
failed yesterday), I decided to actually check the typescript file (from
the portmaster run) to see if I could figure out what was wrong.

Here's a salient excerpt:

| ...
| ===>  Cleaning for rust-1.12.1
| ===>  License APACHE20  MIT accepted by the user
| ===>  Found saved configuration for rust-1.9.0_1
| ===>   rust-1.12.1 depends on file: /usr/local/sbin/pkg - found
| ===> Fetching all distfiles required by rust-1.12.1 for building
| ===>  Extracting for rust-1.12.1
| => SHA256 Checksum OK for rustc-1.12.1-src.tar.gz.
| => SHA256 Checksum OK for rustc-1.11.0-x86_64-unknown-freebsd.tar.gz.
| /bin/ln -sf 
/common/ports/distfiles//rustc-1.11.0-x86_64-unknown-freebsd.tar.gz 
| /common/ports/lang/rust/work/rustc-1.12.1/dl
| ===>  Patching for rust-1.12.1
| ===>  Applying FreeBSD patches for rust-1.12.1
| ===>   rust-1.12.1 depends on executable: cmake - found
| ===>   rust-1.12.1 depends on file: /usr/local/llvm38/bin/FileCheck - not 
found
| ===>  Installing for llvm38-3.8.1_5
| ===>   llvm38-3.8.1_5 depends on file: /usr/local/bin/python2.7 - found
| ===>   llvm38-3.8.1_5 depends on package: perl5>=5.24<5.25 - found
| ===>   llvm38-3.8.1_5 depends on shared library: libedit.so.0 - found 
(/usr/local/lib/libedit.so.0)
| ===>  Checking if llvm38 already installed
| ===>   llvm38-3.8.1_5 is already installed
|   You may wish to ``make deinstall'' and install this port again
|   by ``make reinstall'' to upgrade it properly.
|   If you really wish to overwrite the old port of llvm38
|   without deleting it first, set the variable "FORCE_PKG_REGISTER"
|   in your environment or the "make install" command line.
| *** Error code 1
| 

Oh.  Well...  So I checked, and... yes, devel/llvm38 is installed.  And
while /usr/local/llvm38/bin exists and has several entries, none of them
is named "FileCheck":

g1-252(11.0-S)[4] ls -lTa /usr/local/llvm38/bin/
total 547144
drwxr-xr-x  2 root  wheel  1536 Oct 23 04:51:57 2016 .
drwxr-xr-x  7 root  wheel   512 Oct 23 04:52:04 2016 ..
-rwxr-xr-x  1 root  wheel  13138520 Oct 23 04:51:36 2016 bugpoint
-rwxr-xr-x  1 root  wheel100664 Oct 23 04:51:26 2016 c-index-test
lrwxr-xr-x  1 root  wheel 9 Oct 23 04:51:25 2016 clang -> clang-3.8
-rwxr-xr-x  1 root  wheel  59401712 Oct 23 04:51:26 2016 clang-3.8
-rwxr-xr-x  1 root  wheel   1585752 Oct 23 04:51:29 2016 
clang-apply-replacements
-rwxr-xr-x  1 root  wheel  45048296 Oct 23 04:51:28 2016 clang-check
lrwxr-xr-x  1 root  wheel 5 Oct 23 04:51:26 2016 clang-cl -> clang
-rwxr-xr-x  1 root  wheel   1601648 Oct 23 04:51:26 2016 clang-format
-rwxr-xr-x  1 root  wheel  16670808 Oct 23 04:51:30 2016 clang-query
-rwxr-xr-x  1 root  wheel  15070640 Oct 23 04:51:29 2016 clang-rename
-r-xr-xr-x  1 root  wheel894224 Oct 23 04:51:45 2016 clang-tblgen
-rwxr-xr-x  1 root  wheel  19523696 Oct 23 04:51:30 2016 clang-tidy
lrwxr-xr-x  1 root  wheel 5 Oct 23 04:51:26 2016 clang++ -> clang
-rwxr-xr-x  1 root  wheel 18099 Jun 19 01:23:10 2015 git-clang-format
lrwxr-xr-x  1 root  wheel 3 Oct 23 04:51:32 2016 ld.lld -> lld
-rwxr-xr-x  1 root  wheel  32942112 Oct 23 04:51:38 2016 llc
-rwxr-xr-x  1 root  wheel  37288720 Oct 23 04:51:32 2016 lld
lrwxr-xr-x  1 root  wheel 3 Oct 23 04:51:32 2016 lld-link -> lld
lrwxr-xr-x  1 root  wheel10 Oct 23 04:51:35 2016 lldb -> lldb-3.8.1
-rwxr-xr-x  1 root  wheel 46168 Oct 23 04:51:35 2016 lldb-3.8.1
-rwxr-xr-x  1 root  wheel122752 Oct 23 04:51:35 2016 lldb-argdumper
lrwxr-xr-x  1 root  wheel13 Oct 23 04:51:35 2016 lldb-mi -> 
lldb-mi-3.8.1
-rwxr-xr-x  1 root  wheel611480 Oct 23 04:51:35 2016 lldb-mi-3.8.1
lrwxr-xr-x  1 root  wheel17 Oct 23 04:51:35 2016 lldb-server -> 
lldb-server-3.8.1
-rwxr-xr-x  1 root  wheel  23847256 Oct 23 04:51:35 2016 lldb-server-3.8.1
-rwxr-xr-x  1 root  wheel  16361392 Oct 23 04:51:39 2016 lli
-rwxr-xr-x  1 root  wheel  12055496 Oct 23 04:51:22 2016 llvm-ar
-rwxr-xr-x  1 root  wheel   2447984 Oct 23 04:51:39 2016 llvm-as
-rwxr-xr-x  1 root  wheel190760 Oct 23 04:51:39 2016 llvm-bcanalyzer
-rwxr-xr-x  1 root  wheel  27517160 Oct 23 04:51:40 2016 llvm-c-test
-rwxr-xr-x  1 root  wheel180752 Oct 23 04:51:22 2016 llvm-config
-rwxr-xr-x  1 root  wheel   2551408 Oct 23 04:51:40 2016 llvm-cov
-rwxr-xr-x  1 root  wheel   2371088 Oct 23 04:51:40 2016 llvm-cxxdump
-rwxr-xr-x  1 root  wheel   2285968 Oct 23 04:51:40 2016 llvm-diff
-rwxr-xr-x  1 root  wheel   1839320 Oct 23 04:51:40 2016 llvm-dis
-rwxr-xr-x  1 root  wheel  26568032 Oct 23 04:51:37 2016 llvm-dsymutil
-rwxr-xr-x  1 root  wheel   2512784 Oct 23 04:51:40 2016 llvm-dwarfdump
-rwxr-xr-x  1 root  wheel  26197712 Oct 23 04:51:41 2016 llvm-dwp
-rwxr-xr-x  1 root  wheel   2592368 Oct 23 04:51:41 2016 llvm-extract
lrwxr-xr-x  1 root  wheel 7 Oct 23 04:51:22 2016 llvm-lib -> llvm-ar
-rwxr-xr-x  1 root  wheel   2951672 Oct 23 04:51:41 2016 llvm-link
-rwx

Re: Staging failure for freshly-built www/firefox-49.0_8,1

[David Wolfskill]

On Mon, Oct 10, 2016 at 08:59:49AM -0700, David Wolfskill wrote:
> ...
> > After copying eacho those, firefox starts, then errors out:
> > 
> 
> On the other hand, with those in place, firefox-49.0_8,1 builds, stages,
> and installs OK... though it doesn't stay up for very long.  :-(
> 

OK; I fired up my poudriere package-builder (with ports still at
r423643):

...
[01:59:39] >> Failed ports: www/firefox:stage
[10amd64-ports-home] [2016-10-10_16h52m00s] [committing:] Queued: 284 Built: 
283 Failed: 1   Skipped: 0   Ignored: 0   Tobuild: 0Time: 01:59:35
[01:59:39] >> Logs: 
/usr/local/poudriere/data/logs/bulk/10amd64-ports-home/2016-10-10_16h52m00s

Folks who are interested may find a copy of the log at
<http://catwhisker.org/~david/FreeBSD/ports/firefox-49.0_8,1.log>
(I also placed a gzipped copy in the same directory, so it's only
217KB, vs. 5.2MB.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Staging failure for freshly-built www/firefox-49.0_8,1

[David Wolfskill]

On Mon, Oct 10, 2016 at 08:05:55AM -0700, David Wolfskill wrote:
> ...
> and thus, no longer installs /usr/local/lib/libplds4.so.1.
> 
> I was able to find a copy of /usr/local/lib/libplds4.so.1 on a system that
> I only update weekly (on Sundays).  I copied it over... only to that each
> of the following was also needed:
> 
> /usr/local/lib/libplc4.so.1
> /usr/local/lib/libnspr4.so.1
> /usr/local/lib/nss/libssl3.so.1
> /usr/local/lib/nss/libsmime3.so.1
> /usr/local/lib/nss/libnss3.so.1
> /usr/local/lib/nss/libnssutil3.so.1
> 
> After copying eacho those, firefox starts, then errors out:
> 

On the other hand, with those in place, firefox-49.0_8,1 builds, stages,
and installs OK... though it doesn't stay up for very long.  :-(

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Staging failure for freshly-built www/firefox-49.0_8,1

[David Wolfskill]

On Mon, Oct 10, 2016 at 07:53:13AM -0700, Kevin Oberman wrote:
> ...
> % locate libplds4.so.1
> /usr/local/lib/libplds4.so.1
> % pkg which /usr/local/lib/libplds4.so.1
> /usr/local/lib/libplds4.so.1 was installed by package nspr-4.13
> 

Thanks.  I tried (re-)installing devel/nspr, but it has been updated to
nspr-4.13_1:


r423591 | jbeich | 2016-10-09 05:10:02 -0700 (Sun, 09 Oct 2016) | 18 lines

devel/nspr, security/nss: drop version from SONAME

No other downstream appends synthetic library version, and doing so
causes underlinking due to fragile build system (see below). Not to
mention being unable to swap out bundled libs from upstream builds.

  $ cc -lplds4 -L/usr/local/lib
  /usr/lib/crt1.o: In function `_start1':
  crt1_c.c:(.text+0xa6): undefined reference to `main'
  /usr/local/lib/libplds4.so: undefined reference to `pthread_set_name_np'
  /usr/local/lib/libplds4.so: undefined reference to `pthread_create'
  /usr/local/lib/libplds4.so: undefined reference to `pthread_condattr_init'
  /usr/local/lib/libplds4.so: undefined reference to `pthread_setschedparam'
  /usr/local/lib/libplds4.so: undefined reference to `pthread_getschedparam'

PR: 213144
Exp-run by: antoine



and thus, no longer installs /usr/local/lib/libplds4.so.1.


I was able to find a copy of /usr/local/lib/libplds4.so.1 on a system that
I only update weekly (on Sundays).  I copied it over... only to that each
of the following was also needed:

/usr/local/lib/libplc4.so.1
/usr/local/lib/libnspr4.so.1
/usr/local/lib/nss/libssl3.so.1
/usr/local/lib/nss/libsmime3.so.1
/usr/local/lib/nss/libnss3.so.1
/usr/local/lib/nss/libnssutil3.so.1

After copying eacho those, firefox starts, then errors out:

g1-252(10.3-S)[10] firefox -no-remote
1476111314479   addons.manager  ERROR   Exception loading default provider 
"resource://gre/modules/addons/XPIProvider.jsm": [Exception... "Component 
returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) 
[nsIJSCID.getService]"  nsresult: "0x80570016 
(NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: 
resource://gre/modules/addons/XPIProvider.jsm ::  :: line 1701"  
data: no] Stack trace: resource://gre/modules/addons/XPIProvider.jsm:1701 < 
AddonManagerInternal.startup()@resource://gre/modules/AddonManager.jsm:924 < 
this.AddonManagerPrivate.startup()@resource://gre/modules/AddonManager.jsm:2965 
< amManager.prototype.observe()@resource://gre/components/addonManager.js:71
1476111314836   addons.manager  ERROR   Exception calling provider 
PluginProvider.getAddonsByTypes: [Exception... "Component returned failure 
code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]"  
nsresult: "0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE)"  location: "JS frame 
:: resource://gre/modules/addons/PluginProvider.jsm :: getIDHashForString :: 
line 33"  data: no] Stack trace: 
getIDHashForString()@resource://gre/modules/addons/PluginProvider.jsm:33 < 
PluginProvider.getPluginList()@resource://gre/modules/addons/PluginProvider.jsm:198
 < 
PluginProvider.buildPluginList()@resource://gre/modules/addons/PluginProvider.jsm:219
 < 
PluginProvider.getAddonsByTypes()@resource://gre/modules/addons/PluginProvider.jsm:147
 < callProviderAsync()@resource://gre/modules/AddonManager.jsm:263 < 
AddonManagerInternal.getAddonsByTypes/<.nextObject()@resource://gre/modules/AddonManager.jsm:2494
 < 
AsyncObjectCaller.prototype.callNext()@resource://gre/modules/AddonManager.jsm:382
 < 
AddonManagerInternal.getAddonsByTypes/<.nextObject/<()@resource://gre/modules/AddonManager.jsm:2499
 < 
GMPProvider.getAddonsByTypes()@resource://gre/modules/addons/GMPProvider.jsm:685
 < callProviderAsync()@resource://gre/modules/AddonManager.jsm:263 < 
AddonManagerInternal.getAddonsByTypes/<.nextObject()@resource://gre/modules/AddonManager.jsm:2494
 < 
AsyncObjectCaller.prototype.callNext()@resource://gre/modules/AddonManager.jsm:382
 < 
AddonManagerInternal.getAddonsByTypes/<.nextObject/<()@resource://gre/modules/AddonManager.jsm:2499
 < 
this.LightweightThemeManager.getAddonsByTypes()@resource://gre/modules/LightweightThemeManager.jsm:450
 < callProviderAsync()@resource://gre/modules/AddonManager.jsm:263 < 
AddonManagerInternal.getAddonsByTypes/<.nextObject()@resource://gre/modules/AddonManager.jsm:2494
 < 
AsyncObjectCaller.prototype.callNext()@resource://gre/modules/AddonManager.jsm:382
 < AsyncObjectCaller()@resource://gre/modules/AddonManager.jsm:362 < 
AddonManagerInternal.getAddonsByTypes()@resource://gre/modules/AddonManager.jsm:2492
 < 
this.AddonManager.getAddonsByTypes()@resource://gre/modules/AddonManager.jsm:3408
 < 
promiseGetAddonsByTypes/<()@resource://gre/modules/TelemetryEnvironment.jsm:250 
< promiseGetAddonsByTypes()@resource://gre/modules/TelemetryEnvironment.jsm:249 
< 
EnvironmentAddonBuilder.prototype._getActiveGMPlugins<()@res

Re: Staging failure for freshly-built www/firefox-49.0_8,1

[David Wolfskill]

On Mon, Oct 10, 2016 at 06:18:13AM -0700, David Wolfskill wrote:
> ...
> So... apparently I'm lacking "libplds4.so.1"??!?
> 
> 
> Clues welcomed
> 

Well  I now find that attempting to invoke firefox-49.0_7,1 -- the
one I had installed before -- also fails now:

g1-252(10.3-S)[1] firefox -no-remote 
XPCOMGlueLoad error for file /local/amd64/local/lib/firefox/libxul.so:
Shared object "libplds4.so.1" not found, required by "libxul.so"
Couldn't load XPCOM.
g1-252(10.3-S)[2] 

Lovely. :-(

Where may I find the apparently-missing "libplds4.so.1"?  (As in, "What
port provides it?")

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Staging failure for freshly-built www/firefox-49.0_8,1

[David Wolfskill]

This was observed on my laptop, freshly updated from:

FreeBSD g1-252.catwhisker.org 10.3-STABLE FreeBSD 10.3-STABLE #493  
r306880M/306902:1003508: Sun Oct  9 04:10:04 PDT 2016 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

to:

FreeBSD g1-252.catwhisker.org 10.3-STABLE FreeBSD 10.3-STABLE #494  
r306935M/306944:1003508: Mon Oct 10 04:02:26 PDT 2016 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

after updating my /usr/ports working copy to r423643, then running
"portmaster -ad".

portmaster reported:

...
===>>> All >> (17)
0;portmaster: All >> (17)^G
===>>> The following actions will be taken if you choose to proceed:
Upgrade ca_root_nss-3.27 to ca_root_nss-3.27.1
Upgrade nspr-4.13 to nspr-4.13_1
Upgrade png-1.6.23 to png-1.6.25
Upgrade sekrit-twc-zimg-2.2.1 to sekrit-twc-zimg-2.3
Upgrade apr-1.5.2.1.5.4_1 to apr-1.5.2.1.5.4_2
Upgrade curl-7.50.3 to curl-7.50.3_1
Upgrade ffmpeg-2.8.8_3,1 to ffmpeg-2.8.8_4,1
Upgrade libxul-45.4.0_5 to libxul-45.4.0_6
Install lang/rust
Upgrade nss-3.27 to nss-3.27.1_1
Upgrade p5-Variable-Magic-0.59 to p5-Variable-Magic-0.60
Upgrade p5-XSLoader-0.22 to p5-XSLoader-0.24
Upgrade poppler-0.46.0_1 to poppler-0.46.0_2
Upgrade spidermonkey170-17.0.0_1 to spidermonkey170-17.0.0_2
Upgrade firefox-49.0_7,1 to firefox-49.0_8,1
Install lang/gcc5
Install lang/gcc-ecj45

===>>> Proceed? y/n [y] 


and proceeded to exercise the laptop for a while.  Once things settled
down a bit, I saw that it reported:

...
===>  Staging for firefox-49.0_8,1
===>   Generating temporary packing list
gmake[2]: Entering directory '/common/ports/www/firefox/work/firefox-49.0'
Adding client.mk options from 
/common/ports/www/firefox/work/firefox-49.0/.mozconfig:

MOZ_OBJDIR=/common/ports/www/firefox/work/firefox-49.0/obj-x86_64-unknown-freebsd10.3

OBJDIR=/common/ports/www/firefox/work/firefox-49.0/obj-x86_64-unknown-freebsd10.3
FOUND_MOZCONFIG=/common/ports/www/firefox/work/firefox-49.0/.mozconfig
gmake -j8 -C 
/common/ports/www/firefox/work/firefox-49.0/obj-x86_64-unknown-freebsd10.3 
install
gmake[3]: Entering directory 
'/common/ports/www/firefox/work/firefox-49.0/obj-x86_64-unknown-freebsd10.3'
gmake[4]: Entering directory 
'/common/ports/www/firefox/work/firefox-49.0/obj-x86_64-unknown-freebsd10.3/browser/installer'
OMNIJAR_NAME=omni.ja \
NO_PKG_FILES="core bsdecho js js-config jscpucfg nsinstall viewer TestGtkEmbed 
elf-dynstr-gc mangle* maptsv* mfc* msdump* msmap* nm2tsv* nsinstall* 
res/samples res/throbber shlibsign* certutil* pk12util* BadCertServer* 
OCSPStaplingServer* GenerateOCSPResponse* chrome/chrome.rdf 
chrome/app-chrome.manifest chrome/overlayinfo components/compreg.dat 
components/xpti.dat content_unit_tests necko_unit_tests *.dSYM " \
/common/ports/www/firefox/work/firefox-49.0/obj-x86_64-unknown-freebsd10.3/_virtualenv/bin/python
 
/common/ports/www/firefox/work/firefox-49.0/toolkit/mozapps/installer/packager.py
 -DMOZ_APP_NAME=firefox -DPREF_DIR=defaults/preferences -DMOZ_GTK=1 
-DMOZ_SYSTEM_NSPR=1 -DMOZ_SYSTEM_NSS=1 -DJAREXT= 
-DMOZ_CHILD_PROCESS_NAME=plugin-container -DNECKO_WIFI -DDLL_PREFIX=lib 
-DDLL_SUFFIX=.so -DBIN_SUFFIX= -DDIR_MACOS= -DDIR_RESOURCES= -DBINPATH=bin 
-DRESPATH=bin -DLPROJ_ROOT=en -DMOZ_ICU_VERSION=56 -DMOZ_SYSTEM_ICU 
-DMOZ_ICU_DBG_SUFFIX= -DICU_DATA_FILE=icudt56l.dat -DA11Y_LOG=1 
-DACCESSIBILITY=1 -DATK_MAJOR_VERSION=2 -DATK_MINOR_VERSION=18 
-DATK_REV_VERSION=0 -DATTRIBUTE_ALIGNED_MAX=64 -DBUILD_CTYPES=1 
-DCROSS_COMPILE='' -DD_INO=d_ino -DENABLE_INTL_API=1 -DENABLE_MARIONETTE=1 
-DENABLE_SYSTEM_EXTENSION_DIRS=1 -DEXPOSE_INTL_API=1 -DFIREFOX_VERSION=49.0 
-DFORCE_PR_LOG=1 -DFUNCPROTO=15 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_26 
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_26 -DGL_PROVIDER_GLX=1 
-DHAVE_64BIT_BUILD=1 -DHAVE_ARC4RANDOM=1 -DHAVE_ARC4RANDOM_BUF=1 
-DHAVE_CLOCK_MONOTONIC=1 -DHAVE_CPUID_H=1 -DHAVE_DIRENT_H=1 -DHAVE_DLADDR=1 
-DHAVE_DLOPEN=1 -DHAVE_FONTCONFIG_FCFREETYPE_H=1 -DHAVE_FT_BITMAP_SIZE_Y_PPEM=1 
-DHAVE_FT_GLYPHSLOT_EMBOLDEN=1 -DHAVE_FT_LOAD_SFNT_TABLE=1 -DHAVE_GETOPT_H=1 
-DHAVE_GMTIME_R=1 -DHAVE_I18N_LC_MESSAGES=1 -DHAVE_INTTYPES_H=1 
-DHAVE_LANGINFO_CODESET=1 -DHAVE_LCHOWN=1 -DHAVE_LIBPNG=1 -DHAVE_LIBVPX=1 
-DHAVE_LIBXSS=1 -DHAVE_LOCALECONV=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MALLCTL=1 
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MEMMEM=1 -DHAVE_MEMORY_H=1 
-DHAVE_NETINET_IN_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_POSIX_FADVISE=1 
-DHAVE_POSIX_FALLOCATE=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_PTHREAD_H=1 
-DHAVE_RES_NINIT=1 -DHAVE_SA_LEN=1 -DHAVE_SCONN_LEN=1 -DHAVE_SETPRIORITY=1 
-DHAVE_SIN6_LEN=1 -DHAVE_SIN_LEN=1 -DHAVE_STDINT_H=1 -DHAVE_STRERROR=1 
-DHAVE_STRNDUP=1 -DHAVE_SYSCALL=1 -DHAVE_SYS_QUEUE_H=1 -DHAVE_SYS_SOUNDCARD_H=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_THREAD_TLS_KEYWORD=1 -DHAVE_UNISTD_H=1 
-DHAVE_VALLOC=1 -DHAVE_VA_COPY=1 -DHAVE_VA_LIST_AS_ARRAY=1 
-DHAVE_

"pkg upgrade" issue encountered & resolved: "Repository ... has a wrong packagesite, need to re-create database"

[David Wolfskill]

For my "production" machines at home, I build FreeBSD (from sources) and
build packages (from ports) on a dedicated "build machine," then install
onto the production machines, as described in
.

In preparation for the stable/10 -> stable/11 migration, I had restored
backup images from one of the production machines ("albert") to a very
similar machine, then changed /etc/rc.conf to reflect a different IP
address and hostname ("pogo").  I had verified that it worked, then
tried performing a "normal" (stable/10 -> stablbe/10) update to it; when
that worked, I then updated its installed packages; that also worked.

Then I tried updating from stable/10 -> stable/11 -- which worked.  And
I then made a list of the installed packages, blew away all of them,
then installed the lot (from my local repository).  And that worked.

Well, that was about a month ago (05 Sep).  So this morning, I thought
it was time to refresh things a bit.

I first refreshed the stable/11  FreeBSD base, going from:

FreeBSD pogo.catwhisker.org 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #51  
r305404M/305415:1100502: Mon Sep  5 04:22:27 PDT 2016 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/ALBERT  amd64

to

FreeBSD pogo.catwhisker.org 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #82  
r306879M/306902:1100503: Sun Oct  9 06:34:36 PDT 2016 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/ALBERT  amd64

On reboot, things seemed OK, so I started the package update, only to
get a whine:

Repository custom has a wrong packagesite, need to re-create database

after which the machine rebooted.  No messages in /var/log; the
machine doesn't have a console, and I was running it headless.

I tried a couple more times, while running other things to try to
find out what was happening.  (One time, I ran top(1), and it
provided a hint that something was using a lot of CPU just before
the reboot.)

But other than that (CPU usage), I had no clue.

I poked around a bit on the Net, to no avail.

Finally, I checked which version of pkg I had on my more-recently-updated
systems (pkg-1.8.7_3) vs. what was install on pogo (pkg-1.8.7_1)
and figured I'd try updating pkg first.

My first attempt ("pkg upgrade ports-mgmt/pkg") failed the same as the
other "pkg upgrade" attempts did, so then I:

pkg delete -f ports-mgmt/pkg

which worked, then

pkg bootstrap

which also worked (and even picked it up from my local repository, as
desired).

I then verified that pkg claimed to be pkg-1.8.7_3, then tried "pkg
upgrade" again.

Success!  :-)


...
Checking integrity... done (0 conflicting)
The following 103 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
opencv-core-2.4.9_3

New packages to be INSTALLED:
opencv2-core: 2.4.13.1_1

Installed packages to be UPGRADED:
xterm: 325 -> 327
x264: 0.144.2533_3 -> 0.148.2708
...
bind99: 9.9.9P2_1 -> 9.9.9P3
bash: 4.3.46_1 -> 4.4

Installed packages to be REINSTALLED:
webp-0.5.0 (needed shared library changed)
nspluginwrapper-1.4.4_5 (direct dependency changed: libX11)
linux-c6-xorg-libs-7.4_5 (direct dependency changed: 
linux-c6-fontconfig)
...
linux-c6-dri-11.0.7 (direct dependency changed: linux-c6-xorg-libs)
linux-c6-cups-libs-1.4.2_5 (direct dependency changed: linux-c6-gnutls)
linux-c6-alsa-plugins-oss-1.1.0 (direct dependency changed: 
linux-c6-alsa-lib)

Number of packages to be removed: 1
Number of packages to be installed: 1
Number of packages to be upgraded: 84
Number of packages to be reinstalled: 17

The operation will free 20 MiB.

Proceed with this action? [y/N]: y




Anyway, I thought I'd post about it in case anyone else needed hint.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

How to migrate from ports/emulators/linux_base-c6 to linux_base-c7?

[David Wolfskill]

Per ports/UPDATING entry 20141215, I have been using
emulators/linux_base-c6 on my laptop for some time.

I recently noticed that ports/emulators/linux_base-c7 now exists (as of
r421391: 2016-09-05 13:10:30 -0700 (Mon, 05 Sep 2016)).

On the other hand, while I count 76 "linux{,base}-c6*" ports (as
of ports/head @422979), I only see a single "linux{,_base}-c7*" port --
ports/emulators/linux_base-c7 itself.

Scanning through ports/UPDATING, the most recent entry on
emulators/linux* is the above-cited 20141215, and the previous entry
(20141209) is the latest entry to document a process for migrating from
one Linux emulation infrastructure to another.  I believe a few of the
particular it cites may well be rather out-of-date.

So I'm wondering:
* At what point might it be ... reasonable ... to consider migrating
  from linux_base-c6 to linux_base-c7?

* Are there any particular steps to take to accomplish such a migration?

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Serial ports guru help is needed

[David Wolfskill]

On Tue, Sep 27, 2016 at 07:10:33PM +0200, Kurt Jaeger wrote:
> ...
> So, back to this usecase: Will a software someone is using to
> talk to logic analyzers, MSOs, oscilloscopes, multimeters, LCR
> meters, sound level meters, thermometers, hygrometers, anemometers,
> light meters, DAQs, dataloggers, function generators, spectrum
> analyzers, power supplies, GPIB interfaces, and more, really
> be used on a serial port that is used to log in (the getty usecase) ?
> 
> In general, I guess: No.
> 
> So the change from cua* to tty* is, while not really needed, not
> really critical.
> 

Folks might want to (also) consider the use case of a serial console --
and being able to login to it (e.g., if all other access has failed, for
an out-of-band communication mechanism with a remote, headless server).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature