Re: Large builds with poudriere

2021-05-20 Thread Mark Millard via freebsd-ports



On 2021-May-20, at 21:10, Chris  wrote:

> On 2021-05-20 13:47, Mark Millard wrote:
>> Chris portmaster at bsdforge.com wrote on
>> Thu May 20 20:09:29 UTC 2021 :
>>> On 2021-05-20 12:21, Kevin Oberman wrote:
>>> > . . .
>>> >>
>>> > You can greatly reduce the build-time for devel/llvm* by changing the
>>> > config to BE_NATIVE to avoid building backends for all FreeBSD supported
>>> > platforms. Obviously this is not acceptable for many cases, but if you
>>> > never cross-compile for other platforms, it's a really big win.
>>> If I understand correctly. Isn't your suggestion synonymous with
>>> WITHOUT_CROSS_COMPILER?
>> So far as I know, devel/llvm* builds make no use of WITHOUT_CROSS_COMPILER
>> definitions ( documented in src.conf ) or what I mention below (also from
>> src.conf documentation).
>> As for what is analogous in src.conf's documentation for system
>> builds: BE_NATIVE in an devel/llvm* for a given context would be
>> analogous to using a specific mix of:
>>WITHOUT_LLVM_TARGET_AARCH64 vs. WITH_LLVM_TARGET_AARCH64
>>WITHOUT_LLVM_TARGET_ARM vs. WITH_LLVM_TARGET_ARM
>>WITHOUT_LLVM_TARGET_MIPSvs. WITH_LLVM_TARGET_MIPS
>>WITHOUT_LLVM_TARGET_POWERPC vs. WITH_LLVM_TARGET_POWERPC
>>WITHOUT_LLVM_TARGET_RISCV   vs. WITH_LLVM_TARGET_RISCV
>>WITHOUT_LLVM_TARGET_X86 vs. WITH_LLVM_TARGET_X86
>> Some of the mixes would simulate the various devel/llvm* ports
>> BE_NATIVE's intent for various platforms. (BE_NATIVE does not
>> work in all contexts, last I tried it anyway.)
> Ahh. My mistake I guess. I somehow got the idea that defining
> WITHOUT_CROSS_COMPILER caused llvm to build only what's needed
> build/bootstrap for the arch it's (currently) running on. Which
> would, of course. Slim down the buildtime/installed footprint.

(I'm not trying to have my wording below cover older gcc based
FreeBSD alternatives.)

13.x of FreeBSD building 14.0 (for example) generally uses a
bootstrap compiler even for the same architecture. A difference
is the default target of the two compilers, such as:

aarch64-unknown-freebsd13.0
vs.
aarch64-unknown-freebsd14.0

even if that were the only difference at the time. (A different
form of "cross"?)

devel/llvm* does not have this bootstrapping issue that
is driven by FreeBSD definitions for building FreeBSD
--instead of by processor architecture.

WITHOUT_CROSS_COMPILER for a FreeBSD system build
causes:

 WITHOUT_CLANG_BOOTSTRAP
 WITHOUT_ELFTOOLCHAIN_BOOTSTRAP
 WITHOUT_LLD_BOOTSTRAP

and so can not be used for the 13.x to 14.0
example: such is not an example of "close"
if I understand right:

  WITHOUT_CROSS_COMPILER
 Set to not build any cross compiler in the cross-tools stage of
 buildworld.  When compiling a different version of FreeBSD than
 what is installed on the system, provide an alternate compiler
 with XCC to ensure success.  When compiling with an identical
 version of FreeBSD to the host, this option may be safely used.
 This option may also be safe when the host version of FreeBSD is
 close to the sources being built, but all bets are off if there
 have been any changes to the toolchain between the versions.
 When set, it enforces these options:

 WITHOUT_CLANG_BOOTSTRAP
 WITHOUT_ELFTOOLCHAIN_BOOTSTRAP
 WITHOUT_LLD_BOOTSTRAP

(One might have compilers around for XCC and such symbol use
but that is a different kind of context.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Large builds with poudriere

2021-05-20 Thread Mark Millard via freebsd-ports
Kevin Oberman rkoberman at gmail.com wrote on
Thu May 20 21:37:28 UTC 2021 :

> On Thu, May 20, 2021 at 12:48 PM Mark Millard  wrote:
> 
> > Kevin Oberman rkoberman at gmail.com wrote on
> > Thu May 20 19:21:24 UTC 2021 :
> >
> > > You can greatly reduce the build-time for devel/llvm* by changing the
> > > config to BE_NATIVE to avoid building backends for all FreeBSD supported
> > > platforms. Obviously this is not acceptable for many cases, but if you
> > > never cross-compile for other platforms, it's a really big win.
> >
> >
> > Unfortunately, using something like (llvm10 is just one example,
> > llvm11 showed the same sort of problem at the time):
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU
> > CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE
> > BE_STANDARD
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE
> >
> > /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD
> >
> > does not work for all platforms/targets. On a Cortex-A57
> > this lead to:
> >
> > Registered Targets:
> >   amdgcn - AMD GCN GPUs
> >   r600   - AMD GPUs HD2XXX-HD6XXX
> >
> > In other words, aarch64 was missing. I had to pick
> > BE_STANDARD or BE_FREEBSD to get something that
> > would target aarch64 on aarch64.
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> > ( dsl-only.net went
> > away in early 2018-Mar)
> >
> Looks like the Makefile might need some work. I see stuff for handling
> aach64/arm64, so it SHOULD work, but there are things I don't understand
> about AARCH64 to figure it all out. Still, it should be detected.
> 
> Out of curiosity, if you do a "make -C  /usr/ports/devel/llvm10 config",
> the line for BE_NATIVE should show the architecture you are running on. If
> it's missing/something else, maybe you should ask brooks@ about it.


On two types of Cortex-A72 context
# make -C  /usr/ports/devel/llvm10 config

produced:

BE_NATIVE Backend(s) for this architecture ()

The same for each of:

# make -C  /usr/ports/devel/llvm80 config
# make -C  /usr/ports/devel/llvm90 config
# make -C  /usr/ports/devel/llvm11 config
# make -C  /usr/ports/devel/llvm12 config

But this turns out to be because:

# make -C  /usr/ports/devel/llvm10 -V ARCH
aarch64

yet the Makefiles have a test for arm64 instead:

.elif ${ARCH} == arm64
_NATIVE_BACKENDS=   AAarch64


FYI (from one of the test environments):

# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 
releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 
root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
  arm64 aarch64 1300139 1300139


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Large builds with poudriere

2021-05-20 Thread Mark Millard via freebsd-ports
Chris portmaster at bsdforge.com wrote on
Thu May 20 20:09:29 UTC 2021 :

> On 2021-05-20 12:21, Kevin Oberman wrote:
> > . . .
> >> 
> > You can greatly reduce the build-time for devel/llvm* by changing the
> > config to BE_NATIVE to avoid building backends for all FreeBSD supported
> > platforms. Obviously this is not acceptable for many cases, but if you
> > never cross-compile for other platforms, it's a really big win.
> 
> If I understand correctly. Isn't your suggestion synonymous with
> WITHOUT_CROSS_COMPILER?

So far as I know, devel/llvm* builds make no use of WITHOUT_CROSS_COMPILER
definitions ( documented in src.conf ) or what I mention below (also from
src.conf documentation).

As for what is analogous in src.conf's documentation for system
builds: BE_NATIVE in an devel/llvm* for a given context would be
analogous to using a specific mix of:

WITHOUT_LLVM_TARGET_AARCH64 vs. WITH_LLVM_TARGET_AARCH64
WITHOUT_LLVM_TARGET_ARM vs. WITH_LLVM_TARGET_ARM
WITHOUT_LLVM_TARGET_MIPSvs. WITH_LLVM_TARGET_MIPS
WITHOUT_LLVM_TARGET_POWERPC vs. WITH_LLVM_TARGET_POWERPC
WITHOUT_LLVM_TARGET_RISCV   vs. WITH_LLVM_TARGET_RISCV
WITHOUT_LLVM_TARGET_X86 vs. WITH_LLVM_TARGET_X86

Some of the mixes would simulate the various devel/llvm* ports
BE_NATIVE's intent for various platforms. (BE_NATIVE does not
work in all contexts, last I tried it anyway.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Large builds with poudriere

2021-05-20 Thread Mark Millard via freebsd-ports
Kevin Oberman rkoberman at gmail.com wrote on
Thu May 20 19:21:24 UTC 2021 :

> You can greatly reduce the build-time for devel/llvm* by changing the
> config to BE_NATIVE to avoid building backends for all FreeBSD supported
> platforms. Obviously this is not acceptable for many cases, but if you
> never cross-compile for other platforms, it's a really big win.


Unfortunately, using something like (llvm10 is just one example,
llvm11 showed the same sort of problem at the time):

/usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU
 CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE 
BE_STANDARD
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD

does not work for all platforms/targets. On a Cortex-A57
this lead to:

Registered Targets:
  amdgcn - AMD GCN GPUs
  r600   - AMD GPUs HD2XXX-HD6XXX

In other words, aarch64 was missing. I had to pick
BE_STANDARD or BE_FREEBSD to get something that
would target aarch64 on aarch64.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Large builds with poudriere

2021-05-20 Thread Mark Millard via freebsd-ports



On 2021-May-20, at 11:11, Mark Millard  wrote:

> Andrea Venturoli ml at netfence.it wrote on
> Thu May 20 14:54:50 UTC 2021 :
> 
>> On 5/20/21 4:11 PM, Alexis Praga wrote:
>>> 
>>> Thanks for the suggestions.
>>> 
 At least, if your machine is powerful enough, you can edit your
 /usr/local/etc/poudriere.conf and list these big ports in
 ALLOW_MAKE_JOBS_PACKAGES.
>>> I'm using ALLOW_MAKE_JOBS=yes already so it won't help unfortunately, I 
>>> think.
>> 
>> Those are not the same things. Check the docs.
>> 
>> Briefly, ALLOW_MAKE_JOBS will allow building several packages at once 
>> (one per core) with one core dedicated to each.
> 
> Nope: /usr/local/etc/poudriere.conf.sample reports that it enables
> more than one process per cpu:
> 
> # By default MAKE_JOBS is disabled to allow only one process per cpu
> # Use the following to allow it anyway   
> # ALLOW_MAKE_JOBS=yes

My wording was poor by being incomplete: ALLOW_MAKE_JOBS allows each
builder to have as many processes as there are cores/processors. So if
multiple builders are allowed (and happen to be in use), then the total
number of processes ready to run for building can be bigger than the
number of cores/processors, something that shows up in the load averages.

How many builders are allowed can be controlled with:

# parallel build support.
# 
# By default poudriere uses hw.ncpu to determine the number of builders.
# You can override this default by changing PARALLEL_JOBS here, or
# by specifying the -J flag to bulk/testport.
# 
# Example to define PARALLEL_JOBS to one single job
# PARALLEL_JOBS=1

Looking in /usr/ports/Mk/bsd.port.mk there is also the following,
that is part of where some of the "MAKE_JOBS" terminology comes
from:

# MAKE_JOBS_UNSAFE
#   - Disallow multiple jobs even when user set a 
global override.
# To be used with known bad ports.
# DISABLE_MAKE_JOBS
#   - Set to disable the multiple jobs feature.  
User settable.
# MAKE_JOBS_NUMBER
#   - Override the number of make jobs to be used.  
User settable.
# MAKE_JOBS_NUMBER_LIMIT
#   - Set a limit for maximum number of make jobs 
allowed to be
# used.

>> ALLOW_MAKE_JOBS_PACKAGES will let a single package build using more cores.
> 
> 
> Even when MAKE_JOBS is otherwise disabled:
> 
> # List of packages that will always be allowed to use MAKE_JOBS  
> # regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports 
> # which holdup the rest of the queue to build more quickly.
> #ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py*"

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Large builds with poudriere

2021-05-20 Thread Mark Millard via freebsd-ports
Andrea Venturoli ml at netfence.it wrote on
Thu May 20 14:54:50 UTC 2021 :

> On 5/20/21 4:11 PM, Alexis Praga wrote:
> > 
> > Thanks for the suggestions.
> > 
> >> At least, if your machine is powerful enough, you can edit your
> >> /usr/local/etc/poudriere.conf and list these big ports in
> >> ALLOW_MAKE_JOBS_PACKAGES.
> > I'm using ALLOW_MAKE_JOBS=yes already so it won't help unfortunately, I 
> > think.
> 
> Those are not the same things. Check the docs.
> 
> Briefly, ALLOW_MAKE_JOBS will allow building several packages at once 
> (one per core) with one core dedicated to each.

Nope: /usr/local/etc/poudriere.conf.sample reports that it enables
more than one process per cpu:

# By default MAKE_JOBS is disabled to allow only one process per cpu
# Use the following to allow it anyway   
# ALLOW_MAKE_JOBS=yes

> ALLOW_MAKE_JOBS_PACKAGES will let a single package build using more cores.


Even when MAKE_JOBS is otherwise disabled:

# List of packages that will always be allowed to use MAKE_JOBS  
# regardless of ALLOW_MAKE_JOBS. This is useful for allowing ports 
# which holdup the rest of the queue to build more quickly.
#ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py*"

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


On aarch64: "sysutils/hpacucli dependency on misc/compat4x has wrong PKGNAME"

2021-05-19 Thread Mark Millard via freebsd-ports
I was doing a poudriere pkgclean under:

# uname -apKU
FreeBSD CA72_16Gp_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 
releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 
root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
  arm64 aarch64 1300139 1300139

and got a message:

[00:07:18] Warning: sysutils/hpacucli dependency on misc/compat4x has wrong 
PKGNAME of 'compat4x-i386' but should be 'compat4x-aarch64'

For reference:

# cd /usr/ports
# ~/fbsd-based-on-what-commit.sh 
branch: main
merge-base: b309895b3544ffba9e8df8786062ec6013c752ff
merge-base: CommitDate: 2021-05-17 06:32:36 +
b309895b3544 (HEAD -> main, freebsd/main, freebsd/HEAD) 
x11-themes/kde-icons-black-and-white: add LICENSE, take MAINTAINER
n545993 (--first-parent --count for merge-base)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


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

2021-05-19 Thread Mark Millard via freebsd-ports
On 2021-May-19, at 14:17, Mark Millard  wrote:

> On 2021-May-19, at 10:29, Mark Millard  wrote:
> 
>> bob prohaska fbsd at www.zefox.net wrote on
>> Wed May 19 16:09:32 UTC 2021 :
>> 
>>> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
 
>>> 
>>> [portmaster background omitted] 
>>> 
 If you want to give the attached port a try, it will install LUA and some
>>> 
>>> 
>>> I tried ports-mgmt/portmaster, it got stuck the same as make.
>>> Unless the new version behaves very differently I'm doubtful it'll
>>> help.
>>> 
>>> At the moment it looks like lxqt requires both python37 and python38.
>>> The needs seem to arise at different stages of the build, so perhaps
>>> they can be invoked, used and removed sequentially, but at this point
>>> deleting python37 causes enough collateral damage to make further
>>> progress impossible, or at least non-obvious. 
>>> 
>>> If the conflict is really limited to merely naming two versions of 
>>> /usr/local/bin/easy_install fixing the naming convention seems to be 
>>> the obvious answer. I remain baffled why something called "easy_install" 
>>> remains essential after installatiion.  Unless of course it's not really 
>>> an installer. Even so, a more sensible naming scheme strikes me as helpful.
>>> 
>>> It isn't apparent to me that something like poudriere can solve this sort
>>> of problem either. If poudriere attempts to build lxqt in a single jail
>>> it looks like the conflict will emerge within the jail.
>> 
>> The FreeBSD port building servers use poudriere and are not having
>> a problem. The problem is your messed up environment that already
>> has the inappropriate mixed that poudriere and the package installers
>> it makes would never produce.
>> 
>> The following show lxqt (10 ports have that in their names) as
>> attempted to be built (not skipped) and all were successful
>> instead of any failing:
> 
> It may not be obvious that I looked up builds on
> ampere2.nyi.freebsd.org because that is the builder for
> targeting arrch64 main [so: 14] builds. That is why the
> url's below have: "mastername=main-arm64-default".
> Thus the evidence includes aarch64 coverage.
> 
>> Built with python37:
>> Apr 20:
>> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19
>> Apr 13:
>> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c
>> Apr 17:
>> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f
>> 
>> Built with python38:
>> May 11:
>> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e
>> May 15:
>> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab
>> May 18:
>> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c
>> May 6:
>> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0
>> 
>> These imply that all the prerequisite ports for the build
>> were also built and working for doing so.
>> 
>>> It'd have to
>>> split the build between two or more jails and then merge the (compatible)
>>> executables into a third jail for completion, AIUI. 
>> 
>> No such problems in a correctly configured system.
>> You are stuck trying to get out of a incorrect
>> system configuration.
>> 
>> poudriere ignores your system configuration and uses
>> its own separate one to do its builds.
>> 
>>> At this point I'm stuck. 
>> 
>> So you had a poudriere failure? If so, report the details,
>> such as publishing someplace the log file showing the
>> failure. Otherwise, you are not stuck.
>> 
>> Once poudriere has built the packages, you would set up
>> pkg to use those builds and then force-(re)install all
>> your ports to use the ones poudriere built. (Not just
>> lxqt.) This would get all your ports back to being
>> coherent with each other.
>> 
>> Presuming a file listing the packages that you want
>> to be sure are installed (not needing to list
>> dependencies) and that that pkg has arleady been
>> redirected to use the poudriere-built packages:
>> 
>> # pkg delete -a
>> # pkg install `cat file-listing-packages`
>> 
>> Technically, I do not know if your environment is so
>> messed up that pkg delete -a would fail.
>> 
>> I'll note that if pkg instead still points to the
>> FreeBSD servers (such as quarterly), the same 2
>> command sequence should re-establish those builds.
>> 
> 
> I started a:
> 
> # poudriere bulk -j13_0R-CA72 x11-wm/lxqt
> 
> on one of the aarch64 systems that I have access to
> (cortex-a72 with 4 cores). It reports (based on prior
> history of other ports building that might overlap and
> so avoid some things needing to be built this time):
> 
> . . .
> [00:00:25] Building 99 packages using 4 builders
> . . .
> [00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1
> . . .
> 
> so it looks like it will be hours from when 

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

2021-05-19 Thread Mark Millard via freebsd-ports



On 2021-May-19, at 10:29, Mark Millard  wrote:

> bob prohaska fbsd at www.zefox.net wrote on
> Wed May 19 16:09:32 UTC 2021 :
> 
>> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
>>> 
>> 
>> [portmaster background omitted] 
>> 
>>> If you want to give the attached port a try, it will install LUA and some
>> 
>> 
>> I tried ports-mgmt/portmaster, it got stuck the same as make.
>> Unless the new version behaves very differently I'm doubtful it'll
>> help.
>> 
>> At the moment it looks like lxqt requires both python37 and python38.
>> The needs seem to arise at different stages of the build, so perhaps
>> they can be invoked, used and removed sequentially, but at this point
>> deleting python37 causes enough collateral damage to make further
>> progress impossible, or at least non-obvious. 
>> 
>> If the conflict is really limited to merely naming two versions of 
>> /usr/local/bin/easy_install fixing the naming convention seems to be 
>> the obvious answer. I remain baffled why something called "easy_install" 
>> remains essential after installatiion.  Unless of course it's not really 
>> an installer. Even so, a more sensible naming scheme strikes me as helpful.
>> 
>> It isn't apparent to me that something like poudriere can solve this sort
>> of problem either. If poudriere attempts to build lxqt in a single jail
>> it looks like the conflict will emerge within the jail.
> 
> The FreeBSD port building servers use poudriere and are not having
> a problem. The problem is your messed up environment that already
> has the inappropriate mixed that poudriere and the package installers
> it makes would never produce.
> 
> The following show lxqt (10 ports have that in their names) as
> attempted to be built (not skipped) and all were successful
> instead of any failing:

It may not be obvious that I looked up builds on
ampere2.nyi.freebsd.org because that is the builder for
targeting arrch64 main [so: 14] builds. That is why the
url's below have: "mastername=main-arm64-default".
Thus the evidence includes aarch64 coverage.

> Built with python37:
> Apr 20:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19
> Apr 13:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c
> Apr 17:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f
> 
> Built with python38:
> May 11:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e
> May 15:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab
> May 18:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c
> May 6:
> http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0
> 
> These imply that all the prerequisite ports for the build
> were also built and working for doing so.
> 
>> It'd have to
>> split the build between two or more jails and then merge the (compatible)
>> executables into a third jail for completion, AIUI. 
> 
> No such problems in a correctly configured system.
> You are stuck trying to get out of a incorrect
> system configuration.
> 
> poudriere ignores your system configuration and uses
> its own separate one to do its builds.
> 
>> At this point I'm stuck. 
> 
> So you had a poudriere failure? If so, report the details,
> such as publishing someplace the log file showing the
> failure. Otherwise, you are not stuck.
> 
> Once poudriere has built the packages, you would set up
> pkg to use those builds and then force-(re)install all
> your ports to use the ones poudriere built. (Not just
> lxqt.) This would get all your ports back to being
> coherent with each other.
> 
> Presuming a file listing the packages that you want
> to be sure are installed (not needing to list
> dependencies) and that that pkg has arleady been
> redirected to use the poudriere-built packages:
> 
> # pkg delete -a
> # pkg install `cat file-listing-packages`
> 
> Technically, I do not know if your environment is so
> messed up that pkg delete -a would fail.
> 
> I'll note that if pkg instead still points to the
> FreeBSD servers (such as quarterly), the same 2
> command sequence should re-establish those builds.
> 

I started a:

# poudriere bulk -j13_0R-CA72 x11-wm/lxqt

on one of the aarch64 systems that I have access to
(cortex-a72 with 4 cores). It reports (based on prior
history of other ports building that might overlap and
so avoid some things needing to be built this time):

. . .
[00:00:25] Building 99 packages using 4 builders
. . .
[00:00:38] [03] [00:00:00] Building lang/rust | rust-1.52.1
. . .

so it looks like it will be hours from when I started
it before it will have finished, presuming that rust
builds to completion. (Rust takes longer and uses more
disk space and the like to build than any llvm* that
I normally build.)

I 

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

2021-05-19 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Wed May 19 16:09:32 UTC 2021 :

> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
> > 
>  
> [portmaster background omitted] 
>  
> > If you want to give the attached port a try, it will install LUA and some
> 
> 
> I tried ports-mgmt/portmaster, it got stuck the same as make.
> Unless the new version behaves very differently I'm doubtful it'll
> help.
> 
> At the moment it looks like lxqt requires both python37 and python38.
> The needs seem to arise at different stages of the build, so perhaps
> they can be invoked, used and removed sequentially, but at this point
> deleting python37 causes enough collateral damage to make further
> progress impossible, or at least non-obvious. 
> 
> If the conflict is really limited to merely naming two versions of 
> /usr/local/bin/easy_install fixing the naming convention seems to be 
> the obvious answer. I remain baffled why something called "easy_install" 
> remains essential after installatiion.  Unless of course it's not really 
> an installer. Even so, a more sensible naming scheme strikes me as helpful.
> 
> It isn't apparent to me that something like poudriere can solve this sort
> of problem either. If poudriere attempts to build lxqt in a single jail
> it looks like the conflict will emerge within the jail.

The FreeBSD port building servers use poudriere and are not having
a problem. The problem is your messed up environment that already
has the inappropriate mixed that poudriere and the package installers
it makes would never produce.

The following show lxqt (10 ports have that in their names) as
attempted to be built (not skipped) and all were successful
instead of any failing:

Built with python37:
Apr 20:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p338d8ba0f777_s5a89498d19
Apr 13:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c
Apr 17:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p9d5f4ef1a469_s86046cf55f

Built with python38:
May 11:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p0c0a4f4b9148_scb07628d9e
May 15:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p6ffbcd54bf8c_s91f251b2ab
May 18:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p7bfc2c072607_s8d2b4b2e7c
May 6:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0

These imply that all the prerequisite ports for the build
were also built and working for doing so.

> It'd have to
> split the build between two or more jails and then merge the (compatible)
> executables into a third jail for completion, AIUI. 

No such problems in a correctly configured system.
You are stuck trying to get out of a incorrect
system configuration.

poudriere ignores your system configuration and uses
its own separate one to do its builds.

> At this point I'm stuck. 

So you had a poudriere failure? If so, report the details,
such as publishing someplace the log file showing the
failure. Otherwise, you are not stuck.

Once poudriere has built the packages, you would set up
pkg to use those builds and then force-(re)install all
your ports to use the ones poudriere built. (Not just
lxqt.) This would get all your ports back to being
coherent with each other.

Presuming a file listing the packages that you want
to be sure are installed (not needing to list
dependencies) and that that pkg has arleady been
redirected to use the poudriere-built packages:

# pkg delete -a
# pkg install `cat file-listing-packages`

Technically, I do not know if your environment is so
messed up that pkg delete -a would fail.

I'll note that if pkg instead still points to the
FreeBSD servers (such as quarterly), the same 2
command sequence should re-establish those builds.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


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

2021-05-17 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Mon May 17 23:46:38 UTC 2021 :

> On Mon, May 17, 2021 at 12:28:24PM -0700, Mark Millard via freebsd-ports 
> wrote:
> > bob prohaska fbsd at www.zefox.net wrote on
> > Mon May 17 15:55:21 UTC 2021 :
> > 
> > > The existing conflict between versions of python strikes me as more of a 
> > > planning problem than a software bug. It may be naive, but I don't see
> > > why python37 and python38 can't use distinct names for files placed in
> > > system directories.
> > 
> > You seem to be under the impression that absent having
> > any common file paths, things would just work. This
> > seems unlikely. A simplified presentation of why
> > follows.
> > 
> 
> I'm under the impression that absence of common paths would help
> reduce conflicts.

True: possibly necessary, even if not sufficient.

> In the case at hand it might be sufficient. 

I do not know: I do not have a very complete understanding
of the full status of your environment after the problem.
(Nor of just what specifically lead to the problem.) I do
know that I do not deal with the issue in my context --but
that is because I use procedures that avoid the general
type of issue (tolerating any other tradeoffs involved).
(I have worked via portmaster and just plain make in the
past before using poudriere as well.)

> > Imagine two programs:
> > 
> > p37 that is set up for python37
> > p38 that is set up for python38
> > 
> > imagine that both use a library plib that is
> > not internal to each but external to both.
> > 
> > So should plib be built/present for python37?
> > python38? Both?
> > 
> > If both: it suggests building a huge set of python
> > software multiple times, once per supported version
> > in the range of to-be-supported python versions. (I
> > do assume python versions make for some degree of
> > incompatibility distinctions. It might be only only
> > some version changes have that property. But such
> > would not change the basic point.)
> > 
> 
> It suggests that p37 (installed first) would install
> its preferred version of plib. When p38 is installed, it
> would test for a compatible version of plib

So now p38 is required to classify all prior combinations
of versions of external libraries it might use (such plib),
and to put in tests for handling all the combinations.

And what if p38 is installed first and p37 second? p37
must do similarly --but has no way to well classify
combinations involving library versions that did not
exist when it was released.

One alternative in the industry is having each package
fully self contained (up to the interfacong with the OS
or whatever the kind of context is). The package-build
builds everything required and bundles what is needed
at run time all together so the package does not depend
on any other packages: its installer and installation
results are self sufficient (up to the "OS"). This
makes other tradeoffs.

There are examples that are similar in ports, some
tied to bootstrapping issues. For example, building
ports-mgmt/pkg builds far more internally because
pkg can not depend on other ports/packages that would
need pkg to already be operational to get things
setup.

https://github.com/freebsd/pkg/tree/master/external/
lists:

blake2/
libelf/
libfetch/
liblua/
libmachista/
libucl/
linenoise/
lua/
msgpuck/
picosat/
sqlite/
uthash/
yxml/

As I understand lang/rust contains and builds its
own (subset of?) some llvm version instead of
depending on one of llvm10/llvm11/llvm12. Its
build time and resource use may be illustrations
of some of the tradeoffs in this style: its build
of an llvm does no good at saving time for any
other port build that involves the same vintage of
llvm.

> and add a new 
> one, with a different name, if the prior version isn't 
> satisfactory. Libraries already seem to have a variety of
> suffixes on their names, so it appears something of the sort
> is already going on. Am I completely missing the point?

See notes above.

> > I know, for example, python39 invalidated code in
> > something I've built in a non-FreeBSD context. The
> > software had to be modified to be compatible with
> > both older python's and python39 (if they wanted
> > to support the older versions as well going
> > forward). (It was not a context of wanting to take
> > advantage of new things in the newer python. But
> > that kind of context is not universal.)
> 
> Not sure I see a fundamental problem here. Python
> 38 remaining useful/necessary after introduction of
> 39 doesn't seem so bad. It seems the norm.

How far back are the pre-supplied older versions
supposed to go? On operating system A? B? C? (Likely
differing choices 

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

2021-05-17 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Mon May 17 15:55:21 UTC 2021 :

> The existing conflict between versions of python strikes me as more of a 
> planning problem than a software bug. It may be naive, but I don't see
> why python37 and python38 can't use distinct names for files placed in
> system directories.

You seem to be under the impression that absent having
any common file paths, things would just work. This
seems unlikely. A simplified presentation of why
follows.

Imagine two programs:

p37 that is set up for python37
p38 that is set up for python38

imagine that both use a library plib that is
not internal to each but external to both.

So should plib be built/present for python37?
python38? Both?

If both: it suggests building a huge set of python
software multiple times, once per supported version
in the range of to-be-supported python versions. (I
do assume python versions make for some degree of
incompatibility distinctions. It might be only only
some version changes have that property. But such
would not change the basic point.)

I know, for example, python39 invalidated code in
something I've built in a non-FreeBSD context. The
software had to be modified to be compatible with
both older python's and python39 (if they wanted
to support the older versions as well going
forward). (It was not a context of wanting to take
advantage of new things in the newer python. But
that kind of context is not universal.)

Most ports having a separate upstream to deal with
and having a huge number of ports makes for
port-developer and upstream-developer coordination
based solutions having great difficulties overall.

No technical-content has been presented to make these
sorts of problems disappear. With the problems being
present, it is a matter of working in a way that
avoids running into the problems or with dealing with
fixing things when the problems occur. I've done both
basic styles over the years and recognize tradeoffs.
I'm happy to help someone explore one of the ways
in which poudriere can be an alternative. It is not
for me to declare how well it would end up fitting
their goals, context, preferences, and so on vs.
other alternatives overall.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


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

2021-05-16 Thread Mark Millard via freebsd-ports
On 2021-May-16, at 15:33, Tatsuki Makino  wrote:

> Mark Millard wrote on 2021/05/16 17:11:
>> On 2021-May-16, at 00:16, Tatsuki Makino  
>> wrote:
>> 
>>> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/ 
>>> -V VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
>>> 
>> Bob already does a buildworld based on /usr/src for other
>> reasons/uses than poudriere. My suggestions are targeted
>> to resusing that buildworld result instead of involving
>> doing another buildworld for poudriere. It is also biased
>> to not changing how he does that buildworld (out of scope
>> to what he was asking about). So far as I know he does
>> not use /usr/src/release to do builds. Bob's system is
>> not fast, each buildworld is time consuming.

I will note that in my context I use MAKEOBJDIRPREFIX=
to use unusual paths instead of the default /usr/obj/
paths. (I'll not get into why I choose to do this.)

Such need not be a problem for Bob's environment and I've
avoided telling Bob about my odd conventions or otherwise
involving them.

>> Would your command suggestion reuse his already-existing
>> buildworld?
>> 
> 
> The /usr/src/release that appeared here is just to create a version string.
> `make -C /usr/src/release/ -V VERSION 
> VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}` will create a string exactly like 
> 12.2-STABLE, no matter when /usr/src is.

Sounds good.

>> In my own use the same is true: I buildworld separately
>> before any poudriere activity (for other reasons/uses)
>> and then I reuse the buildworld that resulted for
>> also setting up poudriere later.
>> 
> 
> This one of mine is also a reuse of built world.
> The main idea of my buildworld, buildkernel, installkernel, and installworld 
> is as follows. (There are some commands mixed in that cannot be executed 
> directly.)
> 
> rm -rf -- /usr/obj/{*,.[^.]*,..?*}

I use WITH_META_MODE=yes and only clear out prior builds
as-needed/on-occasion.

> git -C /usr/src/ pull && git -C /usr/src/ reset --hard && git -C /usr/src/ 
> clean -dfx
> cat somepatches*.diff | patch -Nt -d /usr/src/

I was avoiding getting into Bob's buildworld
installworld details. I have some minor differences
in how I operate for the above sorts of things.
(I've actually explored more than one style
with git involved, two still in use.)

> cd /usr/src/
> make buildworld && make buildkernel
> mergemaster -p

Since git, I use etcupdate instead of merge master.

> make installkernel

Sometimes a shutdown -r now is required here
because the new world would not work with the
old kernel that is still live. On rare powerpc64
or powerpc updates I've had to installworld
and shutdown -r now first (announced/documented
at the time).

> make installworld
> make delete-old delete-old-libs

Doing delete-old-libs before installing updated
ports can break things: existing installed ports
might fail to work. Some configurations might
not be able to avoid having such a port's use
attempted before updates can be made. I do
the delete-old-libs later when such might be an
issue in my context.

I normally use BATCH_DELETE_OLD_FILES=yes with
the delete-old*'s.

> mergemaster

Again, since git, I use etcupdate instead of merge
master.

> reboot

I use "shutdown -r now" instead. "man reboot" reports:

QUOTE
 Normally, the shutdown(8) utility is used when the system needs to be
 halted or restarted, giving users advance warning of their impending doom
 and cleanly terminating specific programs.
END QUOTE

In my context it is only the "cleanly terminating
specific programs" part that leads to my making the
distinction. I've not explored the details.

Past this point in your sequence is not a type of
sequence that I've used.

> poudriere jail -u -j main# -j name is matched to above command.
> poudriere's jail -u will take care of everything from installworld to the 
> /etc installation.
> For poudriere-jail, buildworld will not run without -b option.

Good to know.

> A copy of /usr/src for jail will be made, but it is required to retain the 
> original source files for jail.

No such /usr/src copy is made with my sequence: /usr/src is
null mounted instead and used in the port builds that need
/usr/src/ access. Bob had indicated wanting to avoid extra
storage use that was unnecessary.

For my style of use, I'm not aware of any need for the older
/usr/src/ files in the jail at any point after updating
/usr/src/ . The same seemed to apply for Bob's context.

> And just to make things a little more interesting...
> The jail can be started with the following command.
> poudriere jail -s -j main -p default
> This jail will be logged in with the following command.
> jexec main-default-n env -i "TERM=$TERM" /usr/bin/login -f -p root
> This is where you can debug, etc. in a mostly clean environment.

I've only used -i to get in the session at the end of a
bulk build. Someday I may experiment with the above sort
of sequence. Thanks for the notes.

> If you break that environment too much, 

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

2021-05-16 Thread Mark Millard via freebsd-ports
On 2021-May-16, at 00:16, Tatsuki Makino  wrote:

> Mark Millard via freebsd-ports wrote on 2021/05/16 10:57:
>> In the form that I use poudriere I use something
>> like the following. I presume here that /usr/src
>> is populated and has the source for the system
>> involved. (I do not remember your describing its
>> status.)
> (Omitted below)
> 
> I was just wondering...
> If you want to use the sources in /usr/src and collect the files in /usr/obj 
> to make a jail, the following is easier.
> 
> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/ -V 
> VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
> 
> Updating it can be done with just the following.
> 
> poudriere jail -u -j main


Bob already does a buildworld based on /usr/src for other
reasons/uses than poudriere. My suggestions are targeted
to resusing that buildworld result instead of involving
doing another buildworld for poudriere. It is also biased
to not changing how he does that buildworld (out of scope
to what he was asking about). So far as I know he does
not use /usr/src/release to do builds. Bob's system is
not fast, each buildworld is time consuming.

Would your command suggestion reuse his already-existing
buildworld?


In my own use the same is true: I buildworld separately
before any poudriere activity (for other reasons/uses)
and then I reuse the buildworld that resulted for
also setting up poudriere later.

In essence, the same buildworld that generates what I
boot is later also used to set up (or update) a
poudriere. In other contexts, I set up (or update) an
independent chroot directory tree first and later a
poudriere directory tree --via one buildworld used
for setting up (or updating) both.

I do not use /usr/src/release to do buildworld or
installworld activities.

As most of the systems involved for my activity are
far from fast, avoiding extra buildworlds and reusing
buildworld results saves time. It also saves storage.
(I choose to work the same way on the fast
ThreadRipper 1950X for uniformity of procedure.)



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


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

2021-05-15 Thread Mark Millard via freebsd-ports
Something I've not asked about or otherwise referenced
is if you use non-default port options  for any of the
ports that you build.

There is:

poudriere options -jmain -c -f ~root/origins/main-origins.txt
or:
poudriere options -jmain -C -f ~root/origins/main-origins.txt

where -c vs. -C is:

QUOTE
 -c   Use 'config' target, which will always show the dialog for
  the given ports.

 -C   Use 'config-conditional' target, which will only bring up
  the dialog on new options for the given ports.  (This is the
  default)
END QUOTE

There is also:

QUOTE
 -n   Do not be recursive

 -r   Remove port options instead of configuring them

 -s   Show port options instead of configuring them
END QUOTE

See: man poudriere-options

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


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

2021-05-15 Thread Mark Millard via freebsd-ports



On 2021-May-15, at 16:37, bob prohaska  wrote:

> On Fri, May 14, 2021 at 07:29:15PM -0700, Mark Millard wrote:
>> bob prohaska fbsd at www.zefox.net wrote on
>> Fri May 14 01:35:28 UTC 2021 :
>> 
>>> Would use of poudriere help with this sort of problem?
>>> It isn't trivial to configure, but this sort of difficulty
>>> has been growing ever worse. I didn't want to deal with the 
>>> complexity and overhead, but maybe it's time. 
>>> 
>> 
>> I happen to use ports-mgmt/poudriere-devel and it
>> avoids such issues but does have build-time tradeoffs
>> and the like. (I'll note that I presume the sort of
>> sustem tuning to avoid Out Of Memory kills and I try
>> to scale to avoid a literal out of swap space
>> problems.)
>> 
> So far, OOM problems haven't appeared on the 8GB Pi4. If they
> do, the problems will be recognizable & the solutions known.
> 
>> I'll start with very overall background for port
>> building because I do not understand your context
>> or goals. Otherwise my material could end-up
>> implicitly be picking from the alternatives in
>> an inappropriate way. Some of this is relevant to
>> (all?) other forms of port building as well.
>> 
> 
> Build time is less a problem than completion. This is a single machine, 
> self-hosting for kernel and world. The only installation target for ports 
> is itself, at least for now.

Good to know.

>> Some basic questions will be:
>> 
>> A) ZFS vs. UFS? (There are some configuration setting(s)
>> dependent on which.)
>> 
> 
> The machine uses UFS, on a 1 TB mechanical hard disk over USB3
> Memory is 8GB, plus a like amount of swap. So far, no swap has been used.

Good to know.

> 
>> I currently have examples of both: I've started
>> experimenting with ZFS again in some contexts, after
>> years of not using it. No individual context is using
>> a mix of both and I use ZFS in contexts with >= 8
>> GiBytes of RAM. I do not try to tune it for small
>> memory contexts (small on ZFS's scale).
>> 
>> 
>> B) How a builder establishes a world-context to execute in?
>> For reasons of testing patches and such I build and
>> install a world into a directory tree and have poudriere
>> use that tree instead of poudriere installing or even
>> building its own world in a tree. (And I've never done it
>> any other way.)
>> 
> 
> I'm a bit confused here. I _think_ the world-context is the kernel
> and root directory, all living under / .

[I use some of your later notes in making
choices here.]

poudriere works in its own world in for a
builder's jail (no separate kernel involved).
Otherwise it would not being making a clean
build of the ports (producing packages for
later installation).

In the form that I use poudriere I use something
like the following. I presume here that /usr/src
is populated and has the source for the system
involved. (I do not remember your describing its
status.)

First, per "man poudriere-jail" and its description
of using "-m method" for method "null", the later
poudriere commands are based on already having set
up via something like (and picking a path for the
system poudriere is to use):

# cd /usr/src
# make installworld DESTDIR=/usr/obj/poudriere-system DB_FROM_SRC=1
# make distrib-dirs DESTDIR=/usr/obj/poudriere-system DB_FROM_SRC=1
# make distribution DESTDIR=/usr/obj/poudriere-system DB_FROM_SRC=1

Note that this system does not have any tailoring or any
pre-installed packages/ports. Having ports installed
messes up poudriere's operation: no longer clean.
poudriere only uses ports that it has built packages for:
it installs such packages in its system, but only as
needed for each port builder. (It cleans up between
ports.) It does not touch your live system's packages
or installed ports during the build.

(I'll not list deatils for updating /usr/obj/poudriere-system
as the system progresses over time. The above is initial
installation. But delete-old and delete-old-libs can be
involved. distrib-dirs and distribution are instead of
etcupdate or the like.)

As for setting up a ports binding and a jail:

# poudriere ports -c -m null -M /usr/ports
# poudriere jail -c -jmain -m null -M /usr/obj/poudriere-system -S /usr/src -v 
14.0-CURRENT

Note: the above picks the name "main" for the poudriere jail
and sets up to use /usr/src and is told the context is to be
14.0-CURRENT . Neither of these commands do the build:
they instead establish context for doing builds in the
future.

Note: the cd and 3 "DESTDIR=" lines are the kind of
activity that I called a "prebuild" of the system that
poudriere is to use. (So: poudriere itself is not
building or installing a system.) This style avoid
having another system build involved, just an install.
(I avoid the complications of describing alternatives
to this particular style.)

> If it's particular to the
> port being built please clarify.

Not particular to a port, but to a poudriere jail.
A poudriere jail does not have your installed
packages already installed, for example. (I'll
not try to list all 

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

2021-05-14 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Fri May 14 01:35:28 UTC 2021 :

> On Thu, May 13, 2021 at 01:35:50PM -0700, Mark Millard wrote:
> > You have apparently chosen to build/update ports via a
> > technique that requires you to manage the dependencies, at
> > least some of the time. (Not that when is necessarily
> > obvious up front.)
> > 
> 
> You give me too much credit 8-)
> 
> > Your environment is now based on a mix of python37 and
> > python 38 related materials. You are likely going to
> > need to rework/rebuild/reinstall things to avoid that.
> > 
> > Hints may come from that UPDATING that I quoted but
> > things are more broken overall than what UPDATING is
> > intended to cover. You might end up needing to
> > uninstall a bunch of stuff until python is unused
> > (or only one python is used) and then follow the
> > notes if you have only python37 use and want to
> > get to python38. Finally rebuild/reinstall what
> > was uninstalled, based on python38 as a context.
> > 
> Trying to deinstall both python37 and python38 didn't
> suffice. Python38's reinstall fails with the same
> conflict. Deleting the offending file doesn't help 
> If other things need to be deinstalled it's not clear
> what they might be.
>  
> > Due to how I build/install ports, I've not had to deal
> > with ending up with the mix so I'm not familiar with
> > the details for recovering from a messy mix.
> > 
> 
> Would use of poudriere help with this sort of problem?
> It isn't trivial to configure, but this sort of difficulty
> has been growing ever worse. I didn't want to deal with the 
> complexity and overhead, but maybe it's time. 
> 

I happen to use ports-mgmt/poudriere-devel and it
avoids such issues but does have build-time tradeoffs
and the like. (I'll note that I presume the sort of
sustem tuning to avoid Out Of Memory kills and I try
to scale to avoid a literal out of swap space
problems.)

I'll start with very overall background for port
building because I do not understand your context
or goals. Otherwise my material could end-up
implicitly be picking from the alternatives in
an inappropriate way. Some of this is relevant to
(all?) other forms of port building as well.

Some basic questions will be:

A) ZFS vs. UFS? (There are some configuration setting(s)
dependent on which.)

I currently have examples of both: I've started
experimenting with ZFS again in some contexts, after
years of not using it. No individual context is using
a mix of both and I use ZFS in contexts with >= 8
GiBytes of RAM. I do not try to tune it for small
memory contexts (small on ZFS's scale).


B) How a builder establishes a world-context to execute in?
For reasons of testing patches and such I build and
install a world into a directory tree and have poudriere
use that tree instead of poudriere installing or even
building its own world in a tree. (And I've never done it
any other way.)

I do this with separate world-trees for aarch64 vs. armv7
on an aarch64 system so I build for armv7 in a faster
context with more RAM and then transfer materials to
the armv7 system for pkg to use for pkg commands. (I've
not set up a server/client context.)

You could, of course, just deal with "native" and ignore
the RPi* aarch64's supporting doing armv7 builds.

I use the same buildworld for updating the running kernel
and world and for installing the world used for poudriere
when the same OS vintage/variation is to be used for both.

If you prebuild, there will be questions of what paths
you want to use to reference the for-poudriere build
trees.


C) How a builder establishes a ports tree? For reasons of
testing patches and such I have a /usr/ports tree of my
own (sometimes under another name) and have poudriere use
that tree instead of making its own.  (And I've never done
it any other way.)

I use the same /usr/ports for both aarch64 and armv7, so
only the one copy.

You might want a different path than /usr/ports if you
pre-establish the ports tree.


D) What FreeBSD versions to target? I do not happen to
use ports that must track the kernel version in detail
so I can target a releng/13's release/13.?.? and use the
ports for stable/13 as well. In fact, I can generally
get away with using those same ports on main [so: 14],
being explicit about the ABI for the pkg commands.

You might use ports to drive displays and such in a way
that leaves you required to track kernel versions more
closely. But if it is only RPi*'s, then may be not for
that. But there are other ports around that violate the
clean separation vs. kernel details.

To some extent this gets into "how many builds to cover
all the systems?". That in turn can influence how the
systems are set up, such as to eliminate some builds
being needed. Your context might be simple, with only
one type of context to cover.


E) Build as root? As non-root?

I happen to only have done build as root but the
systems are not used for other activities. There
could be ownership/permission issues that 

Re: Trubles compiling lxqt on RPi4

2021-05-13 Thread Mark Millard via freebsd-ports
On 2021-May-13, at 14:27, Tatsuki Makino  wrote:

> 20210425 of UPDATING doesn't take into care the environment where python37 
> and python38 are installed at the same time.
> This is a problem for people who installed 3.8 when 3.7 was the default. 
> (e.g. user of graphics/blender)
> 
> Can you experiment with the commands I've been thinking about in anticipation 
> of 3.9 becoming the default :)
> 
> # check dependencies.
> pkg check -d -n -a
> # gather the names of packages that will need to be reinstalled.
> pkg query -e '( %n !~ py37-* && %n !~ *-py37-* )' %n-:%dn | grep -e 
> ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > /tmp/py37.txt
> # gather the origins of manually installed packages where the FLAVOR will 
> change.
> pkg query -e '( %n ~ py37-* || %n ~ *-py37-* ) && %a = 0 && %#''r = 0' %o:%dn 
> | grep -e ':python37\|:py37-\|:.*-py37-' | cut -d : -f 1 | sort -u > 
> /tmp/py37-o.txt
> # delete the py37 packages
> pkg delete -f -g py37-\* \*-py37-\*
> # install the package of py37-o.txt
> xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37-o.txt
> # reinstall the package of py37.txt
> xargs -o -- portmaster (portmaster options of your choice) < /tmp/py37.txt
> 

My context is not based on using portmaster at all. I do
not create environments with multiple versions of python
in use (or other such potential conflicts).

So: It will not be me that tests such commands for handling
such contexts.

May be Bob P. will test your sequence.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Trubles compiling lxqt on RPi4

2021-05-13 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Thu May 13 15:39:41 UTC 2021 :

> On Thu, May 13, 2021 at 08:13:07AM +0200, Jan Beich wrote:
> > >
> > > Moving to /usr/ports/json-glib and using 
> > > make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 
> > > DISABLE_VULNERABILITIES=yes > make.log
> > > reports several instances of 
> > > error: unknown argument: '-fno-color-diagnostics'
> > 
> > Likely caused by desync between USES=meson and devel/meson, see
> > https://cgit.freebsd.org/ports/commit/?id=ff2796d5bc83
> > 
> > Try again after re-installing devel/meson.
> 
> That might be a hint which circles back to Mark's comments related to
> python37 vs -38. Trying to re-make devel/meson finds.
> 
> root at nemesis:/usr/ports/devel/meson # make -DBATCH FORCE_PKG_REGISTER=yes 
> install
> ===>   meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===>  Installing for py38-setuptools-44.0.0_1
> ===>   Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0 
> (installs files into the same place).  Problematic file: 
> /usr/local/bin/easy_install
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/devel/py-setuptools
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/devel/meson
> 
> The fix for the -37 vs-38 conflict invokes portmaster, might it 
> suffice to simply deinstall -37 and explicitly replace it with
> -38 ? I'll give it a try.
> 
> Hmm, no dice. After deinstalling python37 and reinstalling python38 an
> attempt to make devel/meson still stops with
> 
> root at nemesis:/usr/ports/devel/meson # make -DBATCH 
> DISABLE_VULNERABILITIES=yes install
> ===>   meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===>  Installing for py38-setuptools-44.0.0_1
> ===>  Checking if py38-setuptools is already installed
> ===>   Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0 
> (installs files into the same place).  Problematic file: 
> /usr/local/bin/easy_install
> *** Error code 1
> 
> How did python38 get installed without py38-setuptools?

You have apparently chosen to build/update ports via a
technique that requires you to manage the dependencies, at
least some of the time. (Not that when is necessarily
obvious up front.)

Your environment is now based on a mix of python37 and
python 38 related materials. You are likely going to
need to rework/rebuild/reinstall things to avoid that.

Hints may come from that UPDATING that I quoted but
things are more broken overall than what UPDATING is
intended to cover. You might end up needing to
uninstall a bunch of stuff until python is unused
(or only one python is used) and then follow the
notes if you have only python37 use and want to
get to python38. Finally rebuild/reinstall what
was uninstalled, based on python38 as a context.

(I'm not even sure uninstalls are going to always work
correctly/completely in the mixed context.)

QUOTE
20210425:
  AFFECTS: users of python
  AUTHOR: kai at FreeBSD.org


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

  For ports users wanting to keep version 3.7 as default,
  add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf

  Following procedures may ease the upgrade:

  For users of pre-build packages:
  # sh
  # for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-}; 
done
  # pkg upgrade

  For portmaster users:
  # sh
  # portmaster -o lang/python38 python37
  # REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
  # pkg delete -f "*py37*"
  # portmaster $REINSTALL
  # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : -f 
1 | sort -u)
  # portmaster $REBUILD
  # REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' | 
sort -u)
  # portmaster $REBUILD2
END QUOTE

Due to how I build/install ports, I've not had to deal
with ending up with the mix so I'm not familiar with
the details for recovering from a messy mix.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Troubles compiling lxqt on RPi4 [out of date Mk/Uses/meson.mk in use]

2021-05-13 Thread Mark Millard via freebsd-ports


On 2021-May-12, at 23:13, Mark Millard  wrote:

> 
> On 2021-May-12, at 22:28, bob prohaska  wrote:
> 
>> On Wed, May 12, 2021 at 09:16:29PM -0700, Mark Millard via freebsd-ports 
>> wrote:
>>> On 2021-May-12, at 20:48, bob prohaska  wrote:
>>> 
>>>> 
>>>> Moving to /usr/ports/json-glib and using 
>>>> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 
>>>> DISABLE_VULNERABILITIES=yes > make.log
>>>> reports several instances of 
>>>> error: unknown argument: '-fno-color-diagnostics'
>>>> 
>>>> Running make clean and restarting makes no difference. There don't seem to 
>>>> be
>>>> any user options for making json-glib,
>>> 
>>> The build log at:
>>> 
>>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>>> 
>>> is the one that just python38 and it reports:
>>> 
>>> ---Begin OPTIONS List---
>>> ===> The following configuration options are available for 
>>> json-glib-1.6.2_1:
>>>DOCS=on: Build and/or install documentation
>>>GIR=on: Build introspection data
>>> ===> Use 'make config' to modify these settings
>>> ---End OPTIONS List---
>>> 
>>> as the options that were used for the build. So
>>> there are 2 options, one of which is appearently
>>> tied to the code's operation (introspection data).
>>> 
>> 
>> Turning off both options and trying a manual make seems to end with the same 
>> error.
>> 
>> 
>> 
>>>> but I wonder if it might be inherting
>>>> an incompatible option from something else.
>>> 
>>> That build log also has lines showing the likes of:
>>> 
>>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . 
>>> -fno-color-diagnostics . . .
>>> 
>>> The compiler is reported in the log to be:
>>> 
>>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version 
>>> 11.0.1 (g...@github.com:llvm/llvm-project.git 
>>> llvmorg-11.0.1-0-g43ff75f2c3fe)")
>>> C linker for the host machine: cc ld.lld 11.0.1
>>> 
>>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my
>>> historical main [so: 14] environments.
>>> 
>>> So system-clang apparently allows the option.
>>> 
>>> You did not show any example command that got the complaint
>>> about  -fno-color-diagnostics so I can ont even be sure it
>>> was a cc command that had the option.
>>> 
>>> 
>> 
>> A copy of the make log is at
>> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log
> 
> Note: Your environment is not up to date enough to be using
> python38 . The log shows:
> 
> [  1% 4/69] /usr/local/bin/python3.7  . . .
> . . .
> 
> I'll note that /usr/ports/UPDATING reports:
> 
> 20210425:
>  AFFECTS: users of python
>  AUTHOR: k...@freebsd.org
> 
>  The default version of python3 and python was switched to 3.8.
> 
>  For ports users wanting to keep version 3.7 as default,
>  add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf
> 
>  Following procedures may ease the upgrade:
> 
>  For users of pre-build packages:
>  # sh
>  # for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-}; 
> done
>  # pkg upgrade
> 
>  For portmaster users:
>  # sh
>  # portmaster -o lang/python38 python37
>  # REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
>  # pkg delete -f "*py37*"
>  # portmaster $REINSTALL
>  # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : 
> -f 1 | sort -u)
>  # portmaster $REBUILD
>  # REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' 
> | sort -u)
>  # portmaster $REBUILD2
> 
> 
> 
> The log also shows the use of -Xclang in the cc commands:
> 
> cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang 
> -fno-color-diagnostics . . .
> 
> but:
> 
> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
> 
> does not show any use of -Xclang .
> 
> -Xclang makes the following argument be passed directly to the
> cc1 compiler stage. So the:
> 
> error: unknown argument: '-fno-color-diagnostics'
> 
> would be from cc1. "clang -cc1 --help" only reports one
> form of color-diagnostics option allowed by the -cc1
> stage:
> 
>  -fcolor-diagnosti

Re: Troubles compiling lxqt on RPi4

2021-05-13 Thread Mark Millard via freebsd-ports


On 2021-May-12, at 22:28, bob prohaska  wrote:

> On Wed, May 12, 2021 at 09:16:29PM -0700, Mark Millard via freebsd-ports 
> wrote:
>> On 2021-May-12, at 20:48, bob prohaska  wrote:
>> 
>>> 
>>> Moving to /usr/ports/json-glib and using 
>>> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 
>>> DISABLE_VULNERABILITIES=yes > make.log
>>> reports several instances of 
>>> error: unknown argument: '-fno-color-diagnostics'
>>> 
>>> Running make clean and restarting makes no difference. There don't seem to 
>>> be
>>> any user options for making json-glib,
>> 
>> The build log at:
>> 
>> http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log
>> 
>> is the one that just python38 and it reports:
>> 
>> ---Begin OPTIONS List---
>> ===> The following configuration options are available for json-glib-1.6.2_1:
>> DOCS=on: Build and/or install documentation
>> GIR=on: Build introspection data
>> ===> Use 'make config' to modify these settings
>> ---End OPTIONS List---
>> 
>> as the options that were used for the build. So
>> there are 2 options, one of which is appearently
>> tied to the code's operation (introspection data).
>> 
> 
> Turning off both options and trying a manual make seems to end with the same 
> error.
> 
> 
> 
>>> but I wonder if it might be inherting
>>> an incompatible option from something else.
>> 
>> That build log also has lines showing the likes of:
>> 
>> [ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . 
>> -fno-color-diagnostics . . .
>> 
>> The compiler is reported in the log to be:
>> 
>> C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version 
>> 11.0.1 (g...@github.com:llvm/llvm-project.git 
>> llvmorg-11.0.1-0-g43ff75f2c3fe)")
>> C linker for the host machine: cc ld.lld 11.0.1
>> 
>> That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my
>> historical main [so: 14] environments.
>> 
>> So system-clang apparently allows the option.
>> 
>> You did not show any example command that got the complaint
>> about  -fno-color-diagnostics so I can ont even be sure it
>> was a cc command that had the option.
>> 
>> 
> 
> A copy of the make log is at
> http://www.zefox.net/~fbsd/rpi4/lxqt/make.log

Note: Your environment is not up to date enough to be using
python38 . The log shows:

[  1% 4/69] /usr/local/bin/python3.7  . . .
. . .

I'll note that /usr/ports/UPDATING reports:

20210425:
  AFFECTS: users of python
  AUTHOR: k...@freebsd.org

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

  For ports users wanting to keep version 3.7 as default,
  add DEFAULT_VERSIONS+= python=3.7 python3=3.7 to make.conf

  Following procedures may ease the upgrade:

  For users of pre-build packages:
  # sh
  # for i in $(pkg query -g %n 'py37-*'); do pkg set -yn ${i}:py38-${i#py37-}; 
done
  # pkg upgrade

  For portmaster users:
  # sh
  # portmaster -o lang/python38 python37
  # REINSTALL="$(pkg info -o "*py37*" | awk '{printf "%s ", $2}')"
  # pkg delete -f "*py37*"
  # portmaster $REINSTALL
  # REBUILD=$(pkg query -g "%n:%dn" '*' | grep py3 | grep -v py38 | cut -d : -f 
1 | sort -u)
  # portmaster $REBUILD
  # REBUILD2=$(pkg list | grep python-37 | xargs pkg which | awk '{print $6}' | 
sort -u)
  # portmaster $REBUILD2



The log also shows the use of -Xclang in the cc commands:

cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . -Xclang 
-fno-color-diagnostics . . .

but:

http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log

does not show any use of -Xclang .

-Xclang makes the following argument be passed directly to the
cc1 compiler stage. So the:

error: unknown argument: '-fno-color-diagnostics'

would be from cc1. "clang -cc1 --help" only reports one
form of color-diagnostics option allowed by the -cc1
stage:

  -fcolor-diagnostics Enable colors in diagnostics

Viewed various ways that confirm:

# more main.c
static volatile char big_area[67001] = "This is a test";
int main ()
{
big_area[67000] = '9';
}

# clang -Xclang -fno-color-diagnostics main.c
error: unknown argument: '-fno-color-diagnostics'

But the detail of what is involved, showing the
-cc1 command that is internally generated, is:

# clang -### -Xclang -fno-color-diagnostics main.c
FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
 &

Re: Trubles compiling lxqt on RPi4

2021-05-12 Thread Mark Millard via freebsd-ports
On 2021-May-12, at 20:48, bob prohaska  wrote:

> On Wed, May 12, 2021 at 05:17:37PM -0700, Mark Millard via freebsd-ports 
> wrote:
>> bob prohaska fbsd at www.zefox.net wrote on
>> Wed May 12 21:10:02 UTC 2021 :
>> 
>>> Attempts to compile x11/x11-wm/lxqt on a Pi4 running -current
>>> get stuck with:
>>> ===>  Building for json-glib-1.6.2_1
> []
>>> FAILED: 
>>> json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o
>>> 
>>> Is there a workaround? Ports were up-to-date as of today, May 12, 2021.
>> 
>> You are not very explicit about the FreeBSD context and
>> such, beyond RPi4 (so aarm64/aarch64).
>> 
>> 
> 
> Moving to /usr/ports/json-glib and using 
> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 
> DISABLE_VULNERABILITIES=yes > make.log
> reports several instances of 
> error: unknown argument: '-fno-color-diagnostics'
> 
> Running make clean and restarting makes no difference. There don't seem to be
> any user options for making json-glib,

The build log at:

http://ampere2.nyi.freebsd.org/data/main-arm64-default/pcd62f0886c18_sd1cb8d11b0/logs/json-glib-1.6.2_1.log

is the one that just python38 and it reports:

---Begin OPTIONS List---
===> The following configuration options are available for json-glib-1.6.2_1:
 DOCS=on: Build and/or install documentation
 GIR=on: Build introspection data
===> Use 'make config' to modify these settings
---End OPTIONS List---

as the options that were used for the build. So
there are 2 options, one of which is appearently
tied to the code's operation (introspection data).

> but I wonder if it might be inherting
> an incompatible option from something else.

That build log also has lines showing the likes of:

[ 21% 16/69] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p . . . 
-fno-color-diagnostics . . .

The compiler is reported in the log to be:

C compiler for the host machine: cc (clang 11.0.1 "FreeBSD clang version 11.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)")
C linker for the host machine: cc ld.lld 11.0.1

That "llvmorg-11.0.1-0-g43ff75f2c3fe" matches what is in my
historical main [so: 14] environments.

So system-clang apparently allows the option.

You did not show any example command that got the complaint
about  -fno-color-diagnostics so I can ont even be sure it
was a cc command that had the option.

Still, your report suggests that the "cc" in your environment
for this build does not reach the normal system-clang.

Do you have /etc/make.conf or /etc/src.conf or the like that
might be interfering? Something else?

What does "cc -v" show in your context?

FYI:
As I remember, "-DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4"
is incoherent: the first says not to do the last.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Trubles compiling lxqt on RPi4

2021-05-12 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Wed May 12 21:10:02 UTC 2021 :

> Attempts to compile x11/x11-wm/lxqt on a Pi4 running -current
> get stuck with:
> ===>  Building for json-glib-1.6.2_1
> [  1% 1/53] cc -Ijson-glib/libjson-glib-1.0.so.0.600.2.p -Ijson-glib 
> -I../json-glib -I. -I.. -I/usr/
> local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
> -Xclang -fno-color-dia
> gnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O3 -O2 
> -fstack-protector-strong 
> -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include 
> -fPIC -pthread '-DG_LOG
> _DOMAIN="Json"' -DG_LOG_USE_STRUCTURED=1 -DJSON_COMPILATION 
> '-DJSON_LOCALEDIR="/usr/local/share/loca
> le"' -Wcast-align -Wmissing-declarations -Wmissing-format-attribute 
> -Wmissing-prototypes -Wmissing-n
> oreturn -Wold-style-definition -Wpointer-arith -Wshadow -Wstrict-prototypes 
> -Wunused -Wno-int-conver
> sion -fno-strict-aliasing -Wno-uninitialized -Werror=address 
> -Werror=array-bounds -Werror=empty-body
>  -Werror=format=2 -Werror=implicit -Werror=init-self 
> -Werror=int-to-pointer-cast -Werror=main -Werro
> r=missing-braces -Werror=nested-externs -Werror=nonnull 
> -Werror=pointer-to-int-cast -Werror=return-t
> ype -Werror=sequence-point -Werror=trigraphs -Werror=undef 
> -Werror=write-strings -fvisibility=hidden
>  -MD -MQ 
> json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o
>  -MF json-gli
> b/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o.d -o 
> json-glib/libjson-glib-1
> .0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o -c 
> json-glib/json-enum-types.c
> FAILED: 
> json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o
> 
> Is there a workaround? Ports were up-to-date as of today, May 12, 2021.

You are not very explicit about the FreeBSD context and
such, beyond RPi4 (so aarm64/aarch64).

It is also likely that there was more error-type reporting text
than just:

FAILED: 
json-glib/libjson-glib-1.0.so.0.600.2.p/meson-generated_.._json-enum-types.c.o

The error is from the build attempt for: devel/json-glib instead
of directly from lxqt.

http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=p46fc7df8540c_s1f64f32a4c
and:
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pcd62f0886c18_sd1cb8d11b0

show successful builds of json-glib-1.6.2_1 on/for main [so:
14]. The first used python37 and the 2nd python38 .

Most of the other modern build runs that show json-glib-1.6.2_1
queued indicate that it was skipped because of:

docbook-xml-5.0_3
sdocbook-xml-1.1_2,2

None listed failed builds, so no logs would match your report.

https://www.freshports.org/devel/json-glib indicates that the
last devel/json-glib update was on 2021-Apr-06. (I've not
checked other dependencies, beyond the basicis of the
python3 change.)

This may get into things like poudriere based builds vs.
some other ways of building that are more sensitive to
context oddities. But you were not explicit about that
aspect of things.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: FreeBSD:13:aarch64 packages are outdated

2021-05-11 Thread Mark Millard via freebsd-ports


Yuri yuri at FreeBSD.org wrote on
Tue May 11 16:54:05 UTC 2021 :

> I checked packages for www/authelia, www/adguardhome, science/siesta and 
> they are 2+ weeks outdated for thus architecture.

Using 
http://ampere2.nyi.freebsd.org/build.html?mastername=main-arm64-default=pe67ae562eb4c_s64fe4400da
to search for build status . . .

The "Failed ports" search for siesta reports:

258 siesta-4.1.5science/siesta  build   0   ??? 00:04:05

clicking on the Log link and looking shows, for example,

QUOTE
/wrkdirs/usr/ports/science/siesta/work/siesta-4.1.5/Src/ts_dq.F90:458:22:

  458 | USE, INTRINSIC :: IEEE_ARITHMETIC, ONLY: IEEE_IS_NAN
  |  1
Fatal Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1)
compilation terminated.
gmake[1]: *** [arch.make:59: ts_dq.o] Error 1
gmake[1]: *** Waiting for unfinished jobs
gmake[1]: Leaving directory 
'/wrkdirs/usr/ports/science/siesta/work/siesta-4.1.5/Obj'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
END QUOTE

By contrast, searching for adguardhome shows success. But the
overall build run reports :stopped:crashed: . . .

QUOTE
Master main-arm64-default
Build pe67ae562eb4c_s64fe4400da
Status stopped:crashed:
Jail main-arm64
Set
Ports Tree default
END QUOTE


As for authelia, the build run I looked up the above in only queued
16055 ports and authelia was not queued. (I searched "Queued ports".)

Of what:

http://ampere2.nyi.freebsd.org/jail.html?mastername=main-arm64-default

shows that have the new naming for git-based: 9 of
the 13 build runs show "stopped:crashed:". Seems
like they are having build problems.

Note:

http://ampere2.nyi.freebsd.org deals with:
main-arm64-deafult

http://ampere1.nyi.freebsd.org deals with:
130arm64-quarterly
130releng-arm64-quarterly
122arm64-quarterly

You can use these to look up the status.

But it is unfortunately and messy to deal with the
git naming giving no clue about the order in the
sequence of builds, such as no having time encoded
to making sorting by name work for such:

p0c0a4f4b9148_scb07628d9e

I wish that date-and-time had been encoded as a
prefix on the names. (To pick an example handling
of the issue.)

For http://ampere2.nyi.freebsd.org the one
listed on that page (currently showing):

main-arm64-default  p0c0a4f4b9148_scb07628d9e

is the active/most-recent build. That is the only
one that has some order-of-build information displayed.

For http://ampere1.nyi.freebsd.org :

130arm64-quarterly  61257645fee1
130releng-arm64-quarterly   ad3fc2921022
122arm64-quarterly  e680e4dc222a

are similarly listing the active or most recent
build of the type.

Under "Queued" on the same pages, one can see if the
build is for the full 31000+ list or a subset. The
same goes for "Queued" when you click through to
something like:

http://ampere2.nyi.freebsd.org/jail.html?mastername=main-arm64-default

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


ports-mgmt/poudriere-devel, lang/rust (for example), and USE_TMPFS that includes wrkdir (or yes)

2021-05-10 Thread Mark Millard via freebsd-ports
I've been using USE_TMPFS=yes (so "wrkdir data") on
various systems, both ZFS (recently) and UFS
(generally, even now). Only one system builds rust
(in order for something else to be built), at least
so far.

An example of the wrkdirs tmpfs use for rust is
(UFS context):

# df -m | grep tmpfs
Filesystem 1M-blocks   Used  Avail Capacity  Mounted on
. . .
tmpfs 301422  17859 283563 6%
/usr/local/poudriere/data/.m/FBSDFSSDjail-default/01/wrkdirs
. . .

This was near the end but the maximum figure was probably
somewhat higher than the 17 GiByte+ figure above. The
context the example is from is for the only large capacity
build machine that I have access to, an amd64 context. I
have other build contexts as well, but, so far, none have
had to deal with building rust.

Rust likely would fit the 8 GiByte RAM + 24 GiByte swap
aarch64 build context with USE_TMPFS including wrkdir if
it was the only builder running at the time. But the
existing builds for the context allow 4 builders in
parallel, one per core. [This deals just fine with
llvm10, llvm11, llvm12, and, gcc10 (no bootstrap) being
what happens to build in parallel, even with USE_TMPFS
that includes wrkdir. Rust is just uses more space all
by itself.]

If I end up with something that requires rust for the
aarch64 builder context, is there a different technique
to deal with the tradeoff other than giving up on
USE_TMPFS spanning wrkdir for all other other
ports/builder-instances as well, presuming the same
media and partitioning (such as total swap space)?

Imaginary examples could be:

A) Tell poudriere that lang/rust is to be built by itself
   despite the general 4-builder context.

B) Tell poudriere that USE_TMPFS excludes wrkdir for
   lang/rust's specific builder.

C) . . . (good question) . . .

So far all I've come up with is explicitly building
lang/rust by itself first, a form of (A):

# poudriere bulk -jNAME -w lang/rust
# poudriere bulk -jNAME -w -f ~/origins/CA72-origins.txt

(Hopefully, reliably remembering to do so.)

Is there any better technique that I've not noticed?

To some extent here, lang/rust is being used an example
of a more general issue: Other ports could have similar
issues with attempted wrkdir-included USE_TMPFS use.

Note: If I build using WITH_DEBUG, the one system that
I have access to that can build such a lang/rust with
workdir included in USE_TMPFS shows over 130 GiBytes
in the tmpfs earn the end of the builder's activity.
(This is a amd64 context with 128 GiBytes of RAM and
192 GiBytes of swapping/paging space.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: pkg builders order of jobs

2021-05-10 Thread Mark Millard via freebsd-ports
Tatsuki Makino tatsuki_makino at hotmail.com wrote on
Mon May 10 21:08:06 UTC 2021 :

> In poudriere.conf, there is a setting for BUILDNAME_FORMAT.
> It will be set to the default value of %Y-%m-%d_%Hh%Mm%Ss in 
> /usr/local/share/poudriere/common.sh
> 
> BUILDNAME_FORMAT is used as ${BUILDNAME:=$(date +${BUILDNAME_FORMAT})} and 
> becomes the default value for BUILDNAME.
> BUILDNAME can be set with the -B option of poudriere-bulk.
> 
> In other words, I want the official poudriere bulk to start with an option 
> like -B 210511060619-53863351e3fbec0d89e941ee9f0f288bd2461e87 too :)

Another, shorter option would be to truncate the hash to,
say, 12 characters (and I show all 4 digits of the year):

-B 20210511060619-53863351e3fb

Especially with content like 20210511060619 as context
in the name, 53863351e3fb is unlikely to not be
unique for built-commit identification.

However, the port builds identify two commits: one for
the port (p prefixed currently) and one for the system
(_s prefixed currently). So more like (using a real
build's hashes):

-B 20210511060619-p0ae18b07e470_sf5ff282bc0

Note that the text after the "-" is the same text now
used in the name.

The use of the date/time encoding as a prefix avoids
dealing with picking between the port and system
"rev-list --first-parent --count" figure or having to
list both in some order --and avoids the computational
effort to find those counts.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: pkg builders order of jobs

2021-05-09 Thread Mark Millard via freebsd-ports
Ronald Klop ronald-lists at klop.ws wrote on
Sun May 9 10:22:38 UTC 2021 :

> On the pkg builders the list of builds is ordered on git hash.
> 
> http://beefy18.nyi.freebsd.org/jail.html?mastername=main-amd64-default
> 
> (NB: ipv6 only)
> 
> This ordering is totally random to me. With svn the list was naturally  
> ordered because of the incremental commit id.
> 
> Is it possible to add the commit count to the job-name like  
> sys/conf/newvers.sh in base?
> git_cnt=$($git_cmd rev-list --first-parent --count HEAD 2>/dev/null)

Places like:

https://artifact.ci.freebsd.org/snapshot/stable-13/

have the same sort of problem, partially because the
dates(/times) shown at the displayed level need not
match what the files will have for date/time (when
the files even exist). An example from my past was:

https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M=D

lists ac845558f7b626d9a31b8f6dab686c45d39dc5a0/ as having
date/time 2021-Apr-10 18:43 .

QUOTE
https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/?C=M=D
lists:

powerpc/ and arm/ as having date/times 2021-Apr-10 18:54 and 2021-Apr-10 18:50
yet lists...
i386/ and arm64/ as having date/times 2021-Feb-19 19:00 and 2021-Feb-19 18:50 .

But it gets worse:

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/powerpc/?C=M=D

shows an empty directory. Same for:

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm/?C=M=D

By contrast,

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/?C=M=D

shows i386/ with date/time 2021-Apr-10 18:43 but

https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/i386/?C=M=D

shows all the file dates as 2021-Feb-19 19:00 .

. . .
END QUOTE

https://artifact.ci.freebsd.org/snapshot/*/ has already accumulated
a huge number of hash-only based naming subdirectories and trying to
do a "no-rebuild approximate bisect" via artifact builds has become
much more painful/impractical.

(It has never helped that architecture is in a deeper layer but
is also partial: only some architectures might build for the
commit in question. One has had to inspect to find examples of
the architecture of interest.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Xoscope nuisance console messages on Pi4 running -current

2021-05-03 Thread Mark Millard via freebsd-ports



On 2021-May-3, at 08:23, bob prohaska  wrote:

> On Mon, May 03, 2021 at 01:00:03AM -0700, Mark Millard via freebsd-ports 
> wrote:
> [detailed code tour omitted]
> 
>> 
>> My guess would be xoscope used a signed 32-bit type
>> that got a value with sign extension to 64 bits
>> before the value started being treated as unsigned.
>> If it had used an unsigned type instead, the padding
>> would have been a zero fill instead (presuming that
>> I've guessed right).
>> 
> 
> So this was an artifact of compiling a 32 program on a 64 bit machine?

I've no evidence that you were building the port for armv7
instead of aarch64. If you were, it would be good to report
that.

Otherwise, I expect the code produced was 64-bit (aarch64)
and the rest is just how the program's source code is set
up.

> And, perhaps unnecessary use of signed versus unsigned integers? 

That is what I expect is going on in the xoscope source code.
(I've not looked.)

> This begs two more questions: It is harmless (seemingly not always), 

I doubt that it is a problem (other than the messages). As I
wrote:

QUOTE
While I do not know the specifics for the command
and command group encoding, the truncated value
seems coherent with the code that is using it.
END QUOTE

> and would it go away if compiled and run on a 32 bit machine, say armv7?

"long int" and "int" are both 32-bits on armv7 (unsigned
or signed) so no extra 1-bits would be produced by sign
extension.

So I do not expect the messages would be generated when
executed via armv7 code.

As far as I can tell, the program likely works (ignoring
the messages) for aarch64. The messages are from the
FreeBSD you are using being a debug build with INVARIANTS
enabled. A non-debug FreeBSD build would not report the
messages.

(It is possible to buildworld for armv7 and install it
into a directory tree and use chroot into that directory
tree to run armv7 code on the RPi4's. This should not
produce the messages --and if it did then there would
be FreeBSD code to change for that kind of context.)

> Many thanks for the detailed explanation, but I'll admit not understanding
> much more than the quoted part above 8-(



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Xoscope nuisance console messages on Pi4 running -current

2021-05-03 Thread Mark Millard via freebsd-ports
On 2021-May-2, at 23:37, bob prohaska  wrote:

> After a successful compile of audio/xoscope on a Pi4 running current a
> stream of messages appeared on the console and in the security log
> while xoscope was running:
> 
> 
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045006
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045005
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045002
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045006
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045005
> +WARNING pid 26370 (xoscope): ioctl sign-extension ioctl c0045002
> 
> They seem to come at a fairly high rate and clutter the logfiles, but 
> apart from that nuisance nothing else seemed visibly amiss.
> 
> Are they of any significance?

The code from a mid 2021-Mar vintage of main [so: 14]
looks like:

/* ARGSUSED */
int
sys_ioctl(struct thread *td, struct ioctl_args *uap)
{
u_char smalldata[SYS_IOCTL_SMALL_SIZE] __aligned(SYS_IOCTL_SMALL_ALIGN);
uint32_t com;
int arg, error;
u_int size;
caddr_t data;

#ifdef INVARIANTS
if (uap->com > 0x) {
printf(
"WARNING pid %d (%s): ioctl sign-extension ioctl %lx\n",
td->td_proc->p_pid, td->td_name, uap->com);
}
#endif
com = (uint32_t)uap->com;
. . .

where sys/sys/sysproto.h shows:

struct ioctl_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char com_l_[PADL_(u_long)]; u_long com; char com_r_[PADR_(u_long)];
char data_l_[PADL_(char *)]; char * data; char data_r_[PADR_(char *)];
};

So, uap->com is unsigned with 64 bits for aarch64 and the
0x is converted to match that for the > test (C
rules).

The assignment to uint32_t com would end up with a
truncated value recorded whenever the warning is
produced.

Thus a value like 0xc0045006ul ends up with
com == 0xc0045006u instead.

Then looking at the usage of com leads to sys/sys/ioccom.h :

. . .
/*
 * Ioctl's have the command encoded in the lower word, and the size of
 * any in or out parameters in the upper word.  The high 3 bits of the
 * upper word are used to encode the in/out status of the parameter.
 *
 *   31 29 28 16 158 7 0
 *  +---+
 *  | I/O | Parameter Length| Command Group | Command   |
 *  +---+
 */
#define IOCPARM_SHIFT   13  /* number of bits for ioctl size */
#define IOCPARM_MASK((1 << IOCPARM_SHIFT) - 1) /* parameter length mask */
#define IOCPARM_LEN(x)  (((x) >> 16) & IOCPARM_MASK)
#define IOCBASECMD(x)   ((x) & ~(IOCPARM_MASK << 16))
#define IOCGROUP(x) (((x) >> 8) & 0xff)

#define IOCPARM_MAX (1 << IOCPARM_SHIFT) /* max size of ioctl */

#define IOC_VOID0x2000UL/* no parameters */
#define IOC_OUT 0x4000UL/* copy out parameters */
#define IOC_IN  0x8000UL/* copy in parameters */
#define IOC_INOUT   (IOC_IN|IOC_OUT)/* copy parameters in and out */
#define IOC_DIRMASK (IOC_VOID|IOC_OUT|IOC_IN)/* mask for IN/OUT/VOID */
. . .

So, com == 0xc0045006u ends up with:

I/O matching:: IOC_IN | IOC_OUT
Command matching   (byte): 0x06u
Command Group matching (byte): 0x50u
Parameter Length matching: 0x0004u

While I do not know the specifics for the command
and command group encoding, the truncated value
seems coherent with the code that is using it.

My guess would be xoscope used a signed 32-bit type
that got a value with sign extension to 64 bits
before the value started being treated as unsigned.
If it had used an unsigned type instead, the padding
would have been a zero fill instead (presuming that
I've guessed right).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: When will git be supported for ports?

2021-04-29 Thread Mark Millard via freebsd-ports



On 2021-Apr-28, at 22:26, Kurt Jaeger  wrote:
> 
>>> https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html
>> 
>> The https://github.com/bsdimp/freebsd-git-docs/ material
>> for git-why.md is still available via:
>> 
>> https://github.com/bsdimp/freebsd-git-docs/commits/483527525db5cd7cf27141a2ca21059d9a3b158e/git-why.md
>> 
>> It had commits on 2020-Oct-20, 2020-Dec-02, and 2020-Dec-03. So
>> it was updated a little from the 2020-Sep blog variant. The
>> changes may not be important. I've not gone through them.
> 
> Thanks -- how did you find the commit hash / link and the dates ?

In a web browser I did the sequence:

Go to: https://github.com/bsdimp/freebsd-git-docs/
Click on "186 commits"
Click on the "<>" to the right of "72f477a"
(that skips past the 3ebc4f7 commit titled "git-why is obsolete")

Click on "git-why.md"

Note: at this point the most recent git-why.md document
version should be displayed.

Click on "History"

Note: at this point the history of the commits to the
document should be displayed, dates shown.

The hashes/links that I supplied were there to copy in
the web browser during this sequence, so that I what I
did to supply them.

> 
> It's the old saying: Give a man a fish, so he will not be hungry
> for a day, teach him to fish and he will be fed for a livetime 8-}


I hope that the above proves of future use. But a
lifetime of complete meals? I doubt it . . .


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: When will git be supported for ports?

2021-04-28 Thread Mark Millard via freebsd-ports
Kurt Jaeger pi at freebsd.org wrote on
Wed Apr 28 19:30:32 UTC 2021 :

> > > > The 'why' was explained here:
> > > >
> > > > https://github.com/bsdimp/freebsd-git-docs/
> 
> Ah, here's the link to the 'why' post:
> 
> https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html

The https://github.com/bsdimp/freebsd-git-docs/ material
for git-why.md is still available via:

https://github.com/bsdimp/freebsd-git-docs/commits/483527525db5cd7cf27141a2ca21059d9a3b158e/git-why.md

It had commits on 2020-Oct-20, 2020-Dec-02, and 2020-Dec-03. So
it was updated a little from the 2020-Sep blog variant. The
changes may not be important. I've not gone through them.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: SVNWEB not updated for ports

2021-04-19 Thread Mark Millard via freebsd-ports
George Mitchell george+freebsd at m5p.com wrote on
Mon Apr 19 14:51:54 UTC 2021 :

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


Two ways starting from a tree view:

A) On the same line as the file/directory of interest, click on log
   and the commit sequence for file/directory will be shown, with
   dates listed.

B) On the same line as the file of interest (not directory),
   click on blame first then on the page that is displayed
   hover the mouse over a commit-id for a range of lines
   and it will show the author, committer, dates, and the
   one-line summary for the commit identified.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set

2021-04-09 Thread Mark Millard via freebsd-ports



On 2021-Apr-8, at 10:46, Mark Millard  wrote:

> Building devel/llvm10 via poudriere-devel on a Cortex-A57
> system (OverDrive 1000), I ended up with just:
> 
> # /usr/local/llvm10/bin/llc -version
> LLVM (http://llvm.org/):
>  LLVM version 10.0.1
>  Optimized build.
>  Default target: aarch64-portbld-freebsd14.0
>  Host CPU: (unknown)
> 
>  Registered Targets:
>amdgcn - AMD GCN GPUs
>r600   - AMD GPUs HD2XXX-HD6XXX
> 
> from a context that has:
> 
> # grep -r BE /usr/local/etc/poudriere.d/options/devel_llvm10/
> /usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU
>  CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE 
> BE_STANDARD
> /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU
> /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD
> /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE
> /usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD
> 
> (I've used the combination in various llvm*'s for years,
> including using such for llvm10. Something has changed.)
> 
> I'll not repeat the material here but llvm11 got the same
> sort of result.
> 
> May be that "Host CPU: (unknown)" has something to do with
> it?
> 
> This has been true since I built and installed back on
> 2021-Feb-11 and is true of my updating build started
> yesterday (bulk still in progress). LLVM10 pkg info
> from active install:
> 
> # pkg info llvm10
> llvm10-10.0.1_5
> Name   : llvm10
> Version: 10.0.1_5
> Installed on   : Thu Feb 11 12:05:43 2021 PST
> Origin : devel/llvm10
> Architecture   : FreeBSD:14:aarch64
> Prefix : /usr/local
> Categories : devel lang
> Licenses   : MIT, BSD3CLAUSE, PD, LLVM, REGEX, LLVM2
> Maintainer : bro...@freebsd.org
> WWW: http://llvm.org/
> Comment: LLVM and Clang
> Options:
>   BE_AMDGPU  : on
>   BE_FREEBSD : off
>   BE_NATIVE  : on
>   BE_STANDARD: off
>   CLANG  : on
>   DOCS   : on
>   EXTRAS : on
>   LIT: on
>   LLD: on
>   LLDB   : on
>   LLD_LINK   : on
>   OPENMP : on
>   PYCLANG: off
> Shared Libs required:
>   libedit.so.0
>   liblua-5.2.so
>   libpython3.7m.so.1.0
>   libxml2.so.2
> Shared Libs provided:
>   libRemarks.so.10
>   libarcher.so
>   libclang-cpp.so.10
>   liblldb.so.10
>   libLTO.so.10
>   libLLVM-10.so
>   libomptarget.so
>   libomp.so
>   libclang.so.10
> Annotations:
>   FreeBSD_version: 144
>   repo_type  : binary
>   repository : custom
> Flat size  : 509MiB
> Description:
> The LLVM Project is a collection of modular and reusable compiler and
> toolchain technologies.
> 
> This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker),
> LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure
> these are built on.
> 
> WWW: http://llvm.org/
> 
> 
> (So the above predates the git conversion.)
> 
> The issue was first noticed via build failures like (from a
> log file):
> 
> . . .
> Sanity testing C compiler: /usr/local/bin/clang10
> Is cross compiler: False.
> Sanity check compiler command line: /usr/local/bin/clang10 
> /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.c
>  -o 
> /wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.exe
>  -O2 -pipe -mcpu=cortex-a57 -g -fstack-protector-strong -fno-strict-aliasing 
> -mcpu=cortex-a57 -pipe -D_FILE_OFFSET_BITS=64 -Wl,-rpath=/usr/local/llvm10/lib
> Sanity check compile stdout:
> 
> -
> Sanity check compile stderr:
> error: unable to create target: 'No available targets are compatible with 
> triple "aarch64-portbld-freebsd14.0"'
> 1 error generated.
> . . .
> 
> 
> The FreeBSD is a non-debug build based on main 7381bbee29df:
> 
> # ~/fbsd-based-on-what-freebsd-main.sh 
> FreeBSD FBSDCA57 14.0-CURRENT FreeBSD 14.0-CURRENT 
> mm-src-n245445-def0058cc690 GENERIC-NODBG  arm64 aarch64 145 145
> def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git 
> context.
> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
> merge-base: CommitDate: 2021-03-12 20:29:42 +
> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all 
> XPT_ASYNC ccbs in a dedicated thread
> n245444 (--first-parent --count for merge-base)

Using OPTIONS_FILE_SET+=BE_STANDARD instead of
OPTIONS_FILE_SET+=BE_NATIVE did not have this
problem. (I've not tried BE_FREEBSD so far.)

Also, my Cortex-A7 (so: armv7) context did not have
the "amdgcn/r600 only" problem with
OPTIONS_FILE_SET+=BE_NATIVE :

# /usr/local/llvm10/bin/llc -version
LLVM (http://llvm.org/):
  LLVM version 10.0.1
  Optimized build.
  Default 

Re: Specific svn/git package update use case

2021-04-09 Thread Mark Millard via freebsd-ports
Simon Wright simon.wright at gmx.net wrote on
Fri Apr 9 10:12:04 UTC 2021 :

> Excellent Mark, thank you, then that is exactly what I need, the git
> equivilent of svn up -r xx ${portsdir}.
> 
> And is there a need to do git-commit or git-merge to deal with the
> 'detached HEAD' message or can I just suppress this? Any local
> modifications live in an overlay for poudriere to use so there is
> nothing unique in my /usr/ports and I only track main, no other branches.

So far as I know, you could just ignore the messages about
detached HEAD for your intended style of use, if I
understand your usage correctly.

You may have other git use besides FreeBSD ports (now or
someday), so I'm cautious about claiming the specifics
below are fully appropriate, but you could do something
like:

git config --global advice.detachedHead false

to make detached HEADs status easier to ignore: no more
messages, or at least in fewer contexts. (I'm unsure if
it would disable git status reporting on the that
specific type of status information.)

As indicated already, you may want to periodically use
git status to cross-check on if something unexpected
happened in your use that should be cleaned up.

> On 09/04/2021 1:23 pm, Mark Millard via freebsd-ports wrote:
>> Simon Wright simon.wright at gmx.net wrote on
>> Fri Apr 9 02:48:47 UTC 2021 :
>> 
>>> I'm still not clear though whether checking out this commit brings in
>>> all the commits from git clone to this one or only this commit. My
>>> reading seems to say that this is *only* this one commit which is not my
>>> need. Can anyone confirm this please?
>> 
>> [My wording is not trying to be explicit about multi-branch
>> merge points. Nor does it try to deal much with if you have
>> local changes or staged changes in place at the time of the
>> activity or if you have extra files not checked into git in
>> the tree as well. And so on: a simple same-branch context.]
>> 
>> A commit hash/id identifies everything on the branch at the
>> time the commit finished, including what did not change
>> compared to the prior commit on the branch. Checking out the
>> commit spans all of it. Jumping forward (or backward) a bunch
>> of commits on a branch does not require doing them one by one
>> to get the net effect.
>> 
>> You may want to inspect after checkouts (or similar activity)
>> that "git status" does not display any surprises that need
>> to be cleaned up in the local file system via some variant(s)
>> of git restore or/and git clean or the like.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Specific svn/git package update use case

2021-04-08 Thread Mark Millard via freebsd-ports
Simon Wright simon.wright at gmx.net wrote on
Fri Apr 9 02:48:47 UTC 2021 :

> I'm still not clear though whether checking out this commit brings in
> all the commits from git clone to this one or only this commit. My
> reading seems to say that this is *only* this one commit which is not my
> need. Can anyone confirm this please?

[My wording is not trying to be explicit about multi-branch
merge points. Nor does it try to deal much with if you have
local changes or staged changes in place at the time of the
activity or if you have extra files not checked into git in
the tree as well. And so on: a simple same-branch context.]

A commit hash/id identifies everything on the branch at the
time the commit finished, including what did not change
compared to the prior commit on the branch. Checking out the
commit spans all of it. Jumping forward (or backward) a bunch
of commits on a branch does not require doing them one by one
to get the net effect.

You may want to inspect after checkouts (or similar activity)
that "git status" does not display any surprises that need
to be cleaned up in the local file system via some variant(s)
of git restore or/and git clean or the like.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set

2021-04-08 Thread Mark Millard via freebsd-ports
Building devel/llvm10 via poudriere-devel on a Cortex-A57
system (OverDrive 1000), I ended up with just:

# /usr/local/llvm10/bin/llc -version
LLVM (http://llvm.org/):
  LLVM version 10.0.1
  Optimized build.
  Default target: aarch64-portbld-freebsd14.0
  Host CPU: (unknown)

  Registered Targets:
amdgcn - AMD GCN GPUs
r600   - AMD GPUs HD2XXX-HD6XXX

from a context that has:

# grep -r BE /usr/local/etc/poudriere.d/options/devel_llvm10/
/usr/local/etc/poudriere.d/options/devel_llvm10/options:_FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU
 CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE 
BE_STANDARD
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_AMDGPU
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_FREEBSD
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_SET+=BE_NATIVE
/usr/local/etc/poudriere.d/options/devel_llvm10/options:OPTIONS_FILE_UNSET+=BE_STANDARD

(I've used the combination in various llvm*'s for years,
including using such for llvm10. Something has changed.)

I'll not repeat the material here but llvm11 got the same
sort of result.

May be that "Host CPU: (unknown)" has something to do with
it?

This has been true since I built and installed back on
2021-Feb-11 and is true of my updating build started
yesterday (bulk still in progress). LLVM10 pkg info
from active install:

# pkg info llvm10
llvm10-10.0.1_5
Name   : llvm10
Version: 10.0.1_5
Installed on   : Thu Feb 11 12:05:43 2021 PST
Origin : devel/llvm10
Architecture   : FreeBSD:14:aarch64
Prefix : /usr/local
Categories : devel lang
Licenses   : MIT, BSD3CLAUSE, PD, LLVM, REGEX, LLVM2
Maintainer : bro...@freebsd.org
WWW: http://llvm.org/
Comment: LLVM and Clang
Options:
BE_AMDGPU  : on
BE_FREEBSD : off
BE_NATIVE  : on
BE_STANDARD: off
CLANG  : on
DOCS   : on
EXTRAS : on
LIT: on
LLD: on
LLDB   : on
LLD_LINK   : on
OPENMP : on
PYCLANG: off
Shared Libs required:
libedit.so.0
liblua-5.2.so
libpython3.7m.so.1.0
libxml2.so.2
Shared Libs provided:
libRemarks.so.10
libarcher.so
libclang-cpp.so.10
liblldb.so.10
libLTO.so.10
libLLVM-10.so
libomptarget.so
libomp.so
libclang.so.10
Annotations:
FreeBSD_version: 144
repo_type  : binary
repository : custom
Flat size  : 509MiB
Description:
The LLVM Project is a collection of modular and reusable compiler and
toolchain technologies.

This port includes Clang (a C/C++/Objective-C compiler), LLD (a linker),
LLDB (a debugger), an OpenMP runtime library, and the LLVM infrastructure
these are built on.

WWW: http://llvm.org/


(So the above predates the git conversion.)

The issue was first noticed via build failures like (from a
log file):

. . .
Sanity testing C compiler: /usr/local/bin/clang10
Is cross compiler: False.
Sanity check compiler command line: /usr/local/bin/clang10 
/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.c
 -o 
/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-20.2.3/_build/meson-private/sanitycheckc.exe
 -O2 -pipe -mcpu=cortex-a57 -g -fstack-protector-strong -fno-strict-aliasing 
-mcpu=cortex-a57 -pipe -D_FILE_OFFSET_BITS=64 -Wl,-rpath=/usr/local/llvm10/lib
Sanity check compile stdout:

-
Sanity check compile stderr:
error: unable to create target: 'No available targets are compatible with 
triple "aarch64-portbld-freebsd14.0"'
1 error generated.
. . .


The FreeBSD is a non-debug build based on main 7381bbee29df:

# ~/fbsd-based-on-what-freebsd-main.sh 
FreeBSD FBSDCA57 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 
GENERIC-NODBG  arm64 aarch64 145 145
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git 
context.
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all 
XPT_ASYNC ccbs in a dedicated thread
n245444 (--first-parent --count for merge-base)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Any plan to fix ports git main history compatibility with old GitHub master?

2021-04-05 Thread Mark Millard via freebsd-ports
[The original send attempt for this failed somehow.]

Eric Turgeon ericbsd at freebsd.org wrote on
Mon Apr 5 20:33:22 UTC 2021 :

> Today when trying to sync the GhostBSD ports tree with the FreeBSD ports
> tree, I found out the main branch history is not compatible with the old
> GitHub master.
> 
> Any plan to migrate to main with hold git history as we had with
> freebsd-src?

https://wiki.freebsd.org/git says in part (items not
completed):

QUOTE
Apr 4th lwhsu Enable push access to Git deploying to production env and 
verifying 
Apr 5th lwhsu Enable push access to Git
Apr 6th lwhsu Enable push access to Git (worst-case) 
  lwhsu Push “Welcome to Git” commit 
  lwhsu Starting pushing to external mirrors (github, gitlab, etc.) 
  portmgr 2021Q2 quarterly branch created 
END QUOTE

Note the "Starting pushing to external mirrors (github, gitlab, etc.)"
that was added to the schedule on 2021-04-05 09:12:09 UTC. That might
be what you are waiting for. Still not listed as started, last I looked.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Any plan to fix ports git main history compatibility with old GitHub master?

2021-04-05 Thread Mark Millard via freebsd-ports


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


Read-only https://cgit.freebsd.org/ports/ accessible now; push access not reported as available yet

2021-04-05 Thread Mark Millard via freebsd-ports
https://cgit.freebsd.org/ shows:

QUOTE
NameDescription IdleLinks
development
doc FreeBSD documentation tree  16 hourssummarylogtree
ports   FreeBSD ports tree  57 min. summarylogtree
src FreeBSD source tree 3 days  summarylogtree
END QUOTE


https://wiki.freebsd.org/git now reports "deploying to production env"
but does not yet indicate "Enable push access to Git".

The schedule now has an explicit "Starting pushing to external mirrors
(github, gitlab, etc.)" after "Push “Welcome to Git” commit", neither
of which have happened yet.

"2021Q2 quarterly branch created" is listed last.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: gitip usage.

2021-04-04 Thread Mark Millard via freebsd-ports
Carmel carmel_ny at outlook.com wrote on
Sun Apr 4 18:05:17 UTC 2021 :

> On Sun, 4 Apr 2021 19:49:04 +0200 (CEST), Helge Oldach stated:
> >Jeffrey Bouquet via freebsd-ports wrote on Sun, 04 Apr 2021 18:46:15
> >+0200 (CEST):
> >> running 12.2 STABLE, I would like a complete DEFAULTS and PORTS 
> >> example for gitup.conf.  
> >
> > "defaults" : {
> > "host"   : "git.freebsd.org",
> > "port"   : 443,
> > "verbosity"  : 1,
> > "work_directory" : "/var/db/gitup",
> > },
> >
> > "ports" : {
> > "repository" : "/ports.git",
> > "branch" : "main",
> > "target" : "/usr/ports",
> > "ignores": [
> > "distfiles",
> > "packages",
> > ],
> > },
> >
> >Note this will not work at present - migration is still underway.
> >
> >Kind regards
> >Helge
> 
> This seems to work for me.
> 
>   "defaults" : {
>   "host"   : "git.freebsd.org",
>   "port"   : 443,
>   "verbosity"  : 1,
>   "work_directory" : "/var/db/gitup",
>   },
> 
>   "ports" : {
>   "host"   : "github.com",
>   "repository" : "/freebsd/freebsd-ports.git",

The just-above gets you access to github's ports
repository, which is not yet based on the new git
repository.

Until https://cgit.freebsd.org starts showing ports
(in addition to the existing doc and src) not even
read-only access to the updated FreeBSD ports git
repository is available for browsing use. (Any
github update likely comes later?)

Going along with that is that the schedule listed at
https://wiki.freebsd.org/git still indicates "verifying
result in staging env" and does not yet indicate that
the "Welcome to Git" commit as in place.

Unlike for src, the ports schedule makes no mention of
the likes of "Starting pushing to external mirrors
(github, gitlab, etc.)". The following *presumes* such
will be done but the status of such in unclear.

Once github is updated(?) to be tracking the new ports
git repository, you may have some more to do to again
have things be coherent vs. the older github
repository content (hashid changes?).

>   "branch" : "main",
>   "target" : "/usr/ports",
>   "ignores": [
>   "distfiles",
>   "packages",
>   ],
>   },


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: No update for a day on ports?

2021-04-03 Thread Mark Millard via freebsd-ports
Felix Palmen felix at palmen-it.de wrote on
Sat Apr 3 20:35:46 UTC 2021 :

> * Mark Millard via freebsd-ports  [20210403 
> 10:02]:
> > Felix Palmen felix at palmen-it.de wrote on
> > > There was an announcement to deprecate it, but it's still built with
> > > releng/13 so far, and I'd be surprised if the snapshots for it wouldn't
> > > be available any more. Deprecation of portsnap AFAIK isn't directly
> > > related to moving to git. (someone correct me please if I'm wrong)
> > 
> > /usr/sbin/portsnap is just a shell script:
> --snip--
> 
> Please see the original announcement for context:
> <https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html>

Good point:

QUOTE
* Make WITHOUT_PORTSNAP default in base. Currently not certain when this 
will happen. May not happen before 13.0, but hopefully it will.

* Eventually, portsnap servers will see low enough usage they can be 
disabled.
END QUOTE

Even if WITHOUT_PORTSNAP was the default, the wording suggests that
WITH_PORTSNAP would be allowed for a time.

And it suggests that portsnap servers disabling would be based on
monitoring usage of the servers.

> In a nutshell: It was *planned* to no longer build portsnap by default
> in 13. Now, it's still built, so I assume that's intentional and
> snapshots will still be available (for some time).

Seems so.

> These snapshots aren't provided by SVN, therefore I doubt having ports
> in GIT will cause any technical trouble creating them?

The /usr/ports/ content provided by portsnap is extracted from
SVN historically and will have to be extracted from git going
forward. I expect that there is some implementation change to
have the materials show up in the portsnap servers. I'm
not claiming to estimate how difficult the change would be.

> Side note: your postings have no meaningful References and therefore
> don't show up in the correct location in the thread, maybe check your
> mail client?


Sorry for such problems.

>  And please don't CC me, I'm reading the list.

Okay, but long term I may not remember. I've gotten
requests for the other way as well and I'm not likely
to try to track all the individual preferences in any
reliable manor.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: No update for a day on ports?

2021-04-03 Thread Mark Millard via freebsd-ports
Felix Palmen felix at palmen-it.de wrote on
Fri Apr 2 22:49:58 UTC 2021 :

> * Guido Falsi via freebsd-ports  [20210403 
> 00:35]:
> > On 02/04/21 23:16, The Doctor via freebsd-ports wrote:
> > > but I use pkg/portsnap .
> > > 
> > > How does that affect us?
> > 
> > AFAIK you can't use it anymore. Use gitup. It's almost a drop-in
> > replacement.
> 
> There was an announcement to deprecate it, but it's still built with
> releng/13 so far, and I'd be surprised if the snapshots for it wouldn't
> be available any more. Deprecation of portsnap AFAIK isn't directly
> related to moving to git. (someone correct me please if I'm wrong)

/usr/sbin/portsnap is just a shell script:

# file /usr/sbin/portsnap 
/usr/sbin/portsnap: POSIX shell script, ASCII text executable

Just because the shell script portsnap is installed does not
mean that it will provide updates (that would ultimately
be based the FreeBSD ports git repository content).

The lines in the script that fetch the compressed snapshot
look like:

echo "Fetching snapshot generated at `date -r ${SNAPSHOTDATE}`:"
fetch -r http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz || return 1

where by default SERVERNAME is as shown below:

# grep SERVERNAME /etc/portsnap.conf
SERVERNAME=portsnap.FreeBSD.org

(It gets the SNAPSHOTHASH from another file fetched from the
server. I'll not indicate such details.)

Saying that portsnap is to be deprecated is to say that the
http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz files (and related)
will not have updated versions to fetch --and that will cause
portsnap to stop working for its purpose, eve if installed.

It is likely that the lack of:

http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz

files (and related) is tied to not producing such files
from the new FreeBSD ports git repository.

So, likely: Yes, directly related to moving to git.

> 
> Still, in the long run, expect it to vanish.
> 

When /usr/sbin/portsnap is removed from the file systems
is not in control of when useful:

http://${SERVERNAME}/s/${SNAPSHOTHASH}.tgz

files exist. But there is not much point to having
/usr/sbin/portsnap in the file systems once useful
versions of such files are no longer available to
fetch.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: No update for a day on ports?

2021-04-03 Thread Mark Millard via freebsd-ports



On 2021-Apr-2, at 20:24, The Doctor  wrote:

> On Sat, Apr 03, 2021 at 07:45:56AM +0600, Muhammad Moinur Rahman wrote:
>> Once it is publicly mentioned that the conversion is completed run the 
>> following command:
>> 
>> sed -e '/github.com/d' -e 's/freebsd\/freebsd-//g' /usr/local/etc/gitup.conf
>> 
>> then do `gitup ports`
>> 
>> Kind Regards,
>> Moin
>> 
>>> On 3 Apr, 2021, at 07:20, The Doctor via freebsd-ports 
>>>  wrote:
>>> 
>>> On Fri, Apr 02, 2021 at 05:54:48PM -0700, Mark Millard via freebsd-ports 
>>> wrote:
>>>> 
>>>> 
>>>> On 2021-Apr-2, at 17:41, Mark Millard  wrote:
>>>> 
>>>>> . . .
>>>> 
>>> 
>>> So what patch is needed to fix the ports issue?
>>> 
>>>> 
>>>> =. . .
>>> 
>>> . . .
>> 
> 
> 50/50 .
> 
> FreeBSD 13.0-RC workstation works.
> 
> Ns2 works
> 
> ns1 is hung up.
> 

So far I'm unable to interpret the above as a reply
to Moin's text. 50/50? Ns2? ns1? 13.0-RC?
How does that match up to the sed suggestion?

Also, the conversion has not been made accessible
yet from what I can tell. For example,

https://cgit.freebsd.org/

lists "doc" and "src" but not (yet) "ports".
So, likely:

https://git.freebsd.org/ports.git
and:
ssh://anon...@git.freebsd.org/ports.git

are also not working notations yet.

Thus, removing github.com references in a way that
would try to use one of the above would mean not
finding a ports repository at all (yet). (Justifying
Moin's "Once it is publicly mentioned that the
conversion is completed . . ." wording?)

(I've no clue if the specifics of the sed suggestion
are correct or not.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: No update for a day on ports?

2021-04-02 Thread Mark Millard via freebsd-ports



On 2021-Apr-2, at 18:20, The Doctor  wrote:

> On Fri, Apr 02, 2021 at 05:54:48PM -0700, Mark Millard via freebsd-ports 
> wrote:
>> 
>> 
>> On 2021-Apr-2, at 17:41, Mark Millard  wrote:
>> 
>>> The Doctor doctor at doctor.nl2k.ab.ca wrote on
>>> Sat Apr 3 00:27:42 UTC 2021 :
>>> 
>>> Results:
>>> 
>>>> gitup -v 1 ports
>>>> # Host: github.com
>>>> # Port: 443
>>>> # Repository: /freebsd/freebsd-ports.git
>>>> # Target: /usr/ports
>>>> gitup: get_commit_details: refs/heads/master doesn't exist in 
>>>> /freebsd/freebsd-ports.git: Invalid argument
>>> 
>>> When I look at:
>>> 
>>> https://github.com/freebsd/freebsd-ports/
>>> 
>>> and look at the popup for selecting a branch
>>> I see a "main" but do not see a "master".
>>> 
>>> By contrast when I look at:
>>> 
>>> https://github.com/freebsd/freebsd-ports-legacy/
>>> 
>>> and look at the popup for selecting a branch
>>> I see a "master" but do not see a "main".
>>> 
>>> It looks like the your gitup is configured for
>>> before the conversion, when only the combination:
>> 
>> One aspect of the above sentence is poor: which
>> "conversion"? It might not be the current
>> svn to git one one. For all I know
>> /freebsd/freebsd-ports-legacy/ could have existed
>> under that naming for a while and
>> /freebsd/freebsd-ports/ could have been tracking
>> svn over the same time frame.
>> 
>>> /freebsd/freebsd-ports.git
>>> refs/heads/master
>>> 
>>> existed. Since then the old /freebsd/freebsd-ports.git
>>> was effectively renamed to /freebsd/freebsd-ports-legacy/
>>> and a new /freebsd/freebsd-ports/ was created that used
>>> "main" instead of "master".
>> 
> 
> So what patch is needed to fix the ports issue?
> 

I only recognized the "master" (github/older) vs. "main"
(modern) terminology issue, which was enough to prompt me
to look and see what things looked like and report on
what I found.

I've not done my ports conversion experiments yet and I
will be using git, not gitup. I've never used gitup. So
I do not know the operational details for fixing what
gitup references. (I use git for FreeBSD src.)

I can say that you would want to use
/freebsd/freebsd-ports.git and whatever notation is
appropriate for "main" in order to track ongoing
updates. (Presumes that you stick with github instead
of the FreeBSD servers.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: No update for a day on ports?

2021-04-02 Thread Mark Millard via freebsd-ports



On 2021-Apr-2, at 17:41, Mark Millard  wrote:

> The Doctor doctor at doctor.nl2k.ab.ca wrote on
> Sat Apr 3 00:27:42 UTC 2021 :
> 
> Results:
> 
>> gitup -v 1 ports
>> # Host: github.com
>> # Port: 443
>> # Repository: /freebsd/freebsd-ports.git
>> # Target: /usr/ports
>> gitup: get_commit_details: refs/heads/master doesn't exist in 
>> /freebsd/freebsd-ports.git: Invalid argument
> 
> When I look at:
> 
> https://github.com/freebsd/freebsd-ports/
> 
> and look at the popup for selecting a branch
> I see a "main" but do not see a "master".
> 
> By contrast when I look at:
> 
> https://github.com/freebsd/freebsd-ports-legacy/
> 
> and look at the popup for selecting a branch
> I see a "master" but do not see a "main".
> 
> It looks like the your gitup is configured for
> before the conversion, when only the combination:

One aspect of the above sentence is poor: which
"conversion"? It might not be the current
svn to git one one. For all I know
/freebsd/freebsd-ports-legacy/ could have existed
under that naming for a while and
/freebsd/freebsd-ports/ could have been tracking
svn over the same time frame.

> /freebsd/freebsd-ports.git
> refs/heads/master
> 
> existed. Since then the old /freebsd/freebsd-ports.git
> was effectively renamed to /freebsd/freebsd-ports-legacy/
> and a new /freebsd/freebsd-ports/ was created that used
> "main" instead of "master".


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: No update for a day on ports?

2021-04-02 Thread Mark Millard via freebsd-ports
The Doctor doctor at doctor.nl2k.ab.ca wrote on
Sat Apr 3 00:27:42 UTC 2021 :

Results:

> gitup -v 1 ports
> # Host: github.com
> # Port: 443
> # Repository: /freebsd/freebsd-ports.git
> # Target: /usr/ports
> gitup: get_commit_details: refs/heads/master doesn't exist in 
> /freebsd/freebsd-ports.git: Invalid argument

When I look at:

https://github.com/freebsd/freebsd-ports/

and look at the popup for selecting a branch
I see a "main" but do not see a "master".

By contrast when I look at:

https://github.com/freebsd/freebsd-ports-legacy/

and look at the popup for selecting a branch
I see a "master" but do not see a "main".

It looks like the your gitup is configured for
before the conversion, when only the combination:

/freebsd/freebsd-ports.git
refs/heads/master

existed. Since then the old /freebsd/freebsd-ports.git
was effectively renamed to /freebsd/freebsd-ports-legacy/
and a new /freebsd/freebsd-ports/ was created that used
"main" instead of "master".

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: No update for a day on ports?

2021-04-01 Thread Mark Millard via freebsd-ports
George Mitchell george+freebsd at m5p.com wrote on
Thu Apr 1 22:19:32 UTC 2021 :

> On 4/1/21 6:04 PM, Tatsuki Makino wrote:
> > Dewayne Geraghty wrote on 2021/04/01 17:47:
> >> [...]
> >> Would appreciate if anyone can provide insight as to the 4 git commands
> >> that I need to function, in a manner similar to the way I use svnlite
> >> use.  Git equivalents for:
> >>
> >> svnlite update /usr/ports
> >> svnlite update -r '{$-$MM-$DD}' /usr/ports/$category/$port
> >> svnlite log -l $N /usr/ports/$category/$port
> >> svnlite diff /usr/ports/$category/$port
> >>
> > 
> > We have to learn by looking at such files. orz
> > https://git.wiki.kernel.org/index.php/File:Git-svn-cheatsheet.pdf
> > [...]
> 
> Thank you very much for this link!  -- George

Be careful: Git-svn-cheatsheet.pdf is about how to use git
with a svn server, not with a git server:

"Cheatsheet for Git as an SVN Client"

The "as an SVN Client" is what says that the
server involved is an SVN server.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: www/joomla3 is no longer in the FreeBSD pkg repo

2021-03-04 Thread Mark Millard via freebsd-ports
Chris Rees crees at bayofrum.net wrote on
Thu Mar 4 09:48:12 UTC 2021 :

> . . .
> I'm afraid that this, which I found in pdflib-lite's readme.txt [1] 
> differs on that opinion.
> 
> 
> 
> - PDFlib Lite
>Open-source edition for basic PDF generation, free for personal use.
>PDFlib Lite does not support all languages, and is not available on
>EBCDIC platforms.
> 
> 
> "Free for personal use" is not Free, and that's why the licence must be 
> acknowledged.
> 
> Unless you have found explicit mention that it is definitely under the 
> PHP licence?
> 
> Chris
> 
> [1] 
> https://github.com/Distrotech/PDFlib-Lite

Looking at the github materials I find:

https://github.com/Distrotech/PDFlib-Lite/blob/master/doc/pdflib/PDFlib-Lite-license.pdf

which indicates: "This agreement defines the licensing terms
for the software product called PDFlib Lite 7.0.5" Its section
2.1 is an "Open Source Developer Exemption" and section 2.2 is
a "Private non-Profit User Exemption" and section 2.3 is a
"Educational and Research Exemption". Its section 6 indicates
that: "This license is governed by the laws of Germany,
excluding choice of law rules."

I make no claim about any validity of depending on any of the
content of the PDFlib-Lite-license.pdf referenced.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: When did pkg(8) drop support for 12-STABLE?

2021-02-23 Thread Mark Millard via freebsd-ports



On 2021-Feb-23, at 19:26, Tatsuki Makino  wrote:

> Hello.
> 
> Jonathan Chen wrote on 2021/02/24 11:25:
>> 
>> You're running 12.1, and not -STABLE. The EOL for 12.1 was Nov-2019.
>> 
>> You need to get a later version or run -STABLE (ie: build from source
>> off the stable/12 branch).
> 
> No, it's the 12.x-STABLE. But it's older than 12.2-RELEASE.
> 
> By the way, now 12.x-STABLE needs to bring the source with the following git 
> command.
> Is there an announcement about it anywhere?
> 
> git clone -b stable/12 "https://git.FreeBSD.org/src.git; /usr/src
> git -C /usr/src/ fetch -- origin stable/12
> git -C /usr/src/ merge --
> git -C /usr/src/ reset --hard HEAD --

For only getting 12's source (not for committing source)
. . .

For stable/12/ and releng/12.*/ and release/12.*.*/
svn can still be used: git use is and will be optional,
although svn is somewhat delayed from git for when
commits appear. (There was a recent problem that
made for a huge delay for svn to have the commits
appear. That has been fixed and the delays are back
to the normal timescale as I understand.)

For stable/13/ and releng/13.*/ and relelase/13.*/
and main (14) and later: snv can no longer be used
to get source.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: When did pkg(8) drop support for 12-STABLE?

2021-02-23 Thread Mark Millard via freebsd-ports
Chris portmaster at bsdforge.com wrote on
Tue Feb 23 23:31:09 UTC 2021 :

> On 2021-02-23 14:58, @lbutlr wrote:
> > On 23 Feb 2021, at 13:26, Chris  wrote:
> >> OK On a virgin 12 stable install.
> > 
> > The current release is 12.2-RELEASE. 12.0-RELEASE was EOLed last February. 
> > I 
> > am
> > not sure what build you mean by "12-STABLE"
> It was from a 12-STABLE usb stick (probably 12.1). Is there no way forward, 
> save
> building up to 12.2?


You might want to report the output of:

# uname -apKU

if you can still run it in the environment in question.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: bogus warning from pkg

2021-02-15 Thread Mark Millard via freebsd-ports
On 2021-Feb-15, at 20:18, Mark Millard  wrote:

> Steve Kargl sgk at troutmask.apl.washington.edu wrote on
> Tue Feb 16 02:14:06 UTC 2021 :
> 
>> On Mon, Feb 15, 2021 at 05:10:54PM -0800, Mark Millard via freebsd-ports 
>> wrote:
>>> Steve Kargl sgk at troutmask.apl.washington.edu wrote on
>>> Mon Feb 15 20:39:19 UTC 2021 :
>>> 
>>>> Step 1).  Install FreeBSD 13.0 on empty disk.
>>>> Step 2).  Install git from ports and grab FreeBSD 14.0 src.
>>>> Step 3).  Buildworld/kernel for FreeBSD 14.0
>>>> Step 4).  Install FreeBSD 14.0 and reboot.
>>>> Step 5).  Delete all ports.
>>>> Step 6).  Re-install pkg, portmaster, and 589 other ports.
>>> 
>>> It does not sound like Step 6 was "rebuild ports and install"
>>> but just pkg install use, at least for pkg itself.
>> 
>> Ports are rebuilt on the system as the pre-built ports
>> have options selected that do not match the requirements
>> of the system.  It takes a week or more to rebuild 
>> everything, which why I'm concerned with the bogus
>> warning and whether 'pkg bootstrap -f' would rebuild
>> everything.
>> 
>> I also do
>> 
>> % cd /usr/ports
>> % svn update
>> % make fetchindex
>> % pkg audit -qF
>> 
>> before I build any port.  That third step pulls down
>> the INDEX-14, which again leads to confusion when pkg
>> issues a warning about 13.
> 
> If you still have the context to do the comparison:
> 
> How does the output of "pkg info pkg" compare to:
> 
> . . .
> Architecture   : FreeBSD:13:amd64

I should have listed i386 from what I understand.

> . . .
> Annotations:
>   FreeBSD_version: 13?
> . . .
> 
> Does it have "14"s instead of "13"s?

Do you use:

https://www.freshports.org/ports-mgmt/port-maintenance-tools/

? I ask because:

https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120156.html

reported having to reinstall it to get rid of having
"Warning: Major OS version upgrade detected" notices.

Since it is a meta-port, the thing that was fixed might
have been fixed via one or more of (from freshports):

Runtime dependencies:
• portupgrade : ports-mgmt/portupgrade
• svn : devel/subversion
• pkg_cutleaves : ports-mgmt/pkg_cutleaves
• pkg_tree : ports-mgmt/pkg_tree
• portdowngrade : ports-mgmt/portdowngrade



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: bogus warning from pkg

2021-02-15 Thread Mark Millard via freebsd-ports
Steve Kargl sgk at troutmask.apl.washington.edu wrote on
Tue Feb 16 02:14:06 UTC 2021 :

> On Mon, Feb 15, 2021 at 05:10:54PM -0800, Mark Millard via freebsd-ports 
> wrote:
> > Steve Kargl sgk at troutmask.apl.washington.edu wrote on
> > Mon Feb 15 20:39:19 UTC 2021 :
> > 
> > > Step 1).  Install FreeBSD 13.0 on empty disk.
> > > Step 2).  Install git from ports and grab FreeBSD 14.0 src.
> > > Step 3).  Buildworld/kernel for FreeBSD 14.0
> > > Step 4).  Install FreeBSD 14.0 and reboot.
> > > Step 5).  Delete all ports.
> > > Step 6).  Re-install pkg, portmaster, and 589 other ports.
> > 
> > It does not sound like Step 6 was "rebuild ports and install"
> > but just pkg install use, at least for pkg itself.
> 
> Ports are rebuilt on the system as the pre-built ports
> have options selected that do not match the requirements
> of the system.  It takes a week or more to rebuild 
> everything, which why I'm concerned with the bogus
> warning and whether 'pkg bootstrap -f' would rebuild
> everything.
> 
> I also do
> 
> % cd /usr/ports
> % svn update
> % make fetchindex
> % pkg audit -qF
> 
> before I build any port.  That third step pulls down
> the INDEX-14, which again leads to confusion when pkg
> issues a warning about 13.

If you still have the context to do the comparison:

How does the output of "pkg info pkg" compare to:

. . .
Architecture   : FreeBSD:13:amd64
. . .
Annotations:
FreeBSD_version: 13?
. . .

Does it have "14"s instead of "13"s?

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: bogus warning from pkg

2021-02-15 Thread Mark Millard via freebsd-ports
Steve Kargl sgk at troutmask.apl.washington.edu wrote on
Mon Feb 15 20:39:19 UTC 2021 :

> On Mon, Feb 15, 2021 at 12:01:47PM -0800, Kevin Oberman wrote:
> > On Mon, Feb 15, 2021 at 11:10 AM Steve Kargl <
> > sgk at troutmask.apl.washington.edu> wrote:
> > 
> > > I have a system installed from late January FreeBSD-current
> > > sources and at that point an up-to-date ports tree.  All
> > > installed ports where builtin after I installed FreeBSD. So,
> > > I am running FreeBSD-14.0.  For some reason, I am getting
> > > bogus warnings from pkg.
> > >
> > > % pkg info > /dev/null
> > > pkg: Warning: Major OS version upgrade detected.  Running \
> > > "pkg bootstrap -f" recommended
> > >
> > > Short of running the bootstrap command, how do I get
> > > rid of these messages, which are clearly bogus.
> > >
> > > --
> > > Steve
> > >
> > Are you sure that you reinstalled pkg since the move to 14? That message
> > means that pkg was built on a prior version of FreeBSD. As you build ports
> > and don't do packages, just build and install pkg and that should do the
> > trick.
> 
> Step 1).  Install FreeBSD 13.0 on empty disk.
> Step 2).  Install git from ports and grab FreeBSD 14.0 src.
> Step 3).  Buildworld/kernel for FreeBSD 14.0
> Step 4).  Install FreeBSD 14.0 and reboot.
> Step 5).  Delete all ports.
> Step 6).  Re-install pkg, portmaster, and 589 other ports.

It does not sound like Step 6 was "rebuild ports and install"
but just pkg install use, at least for pkg itself.

main a53ce3fc4938 (2021-01-22 00:10:07 +) was "Bump CURRENT
to 14.0", the earliest 14 you could have built in Step 3.

The first main-i386 ports build with 3+ queued after that
was: p562431_sd6327ae8c which completed on Sat, 40:10:40 after
it started on Sun, 24 Jan 2021 01:16:53 GMT . (There likely is
more time for the build's material to be distributed to various
servers. But I do not know how to track down those times.)

Did you happen to to do step 6 before the first FreeBSD:14
ports showed up? If yes, then you were still working against
FreeBSD:13 ports from pkg install; if no, then you should have
gotten FreeBSD:14 ports.

>From your description and the timings that I do not know how
to track down, I can not tell what is likely.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: bogus warning from pkg

2021-02-15 Thread Mark Millard via freebsd-ports
Steve Kargl sgk at troutmask.apl.washington.edu wrote on
Mon Feb 15 19:10:36 UTC 2021 :

> I have a system installed from late January FreeBSD-current
> sources and at that point an up-to-date ports tree.  All
> installed ports where builtin after I installed FreeBSD. So,
> I am running FreeBSD-14.0.  For some reason, I am getting
> bogus warnings from pkg.
> 
> % pkg info > /dev/null
> pkg: Warning: Major OS version upgrade detected.  Running \
> "pkg bootstrap -f" recommended
> 
> Short of running the bootstrap command, how do I get 
> rid of these messages, which are clearly bogus.

I expect that "pkg info pkg" will report something
like:

. . .
Architecture   : FreeBSD:13:amd64
. . .
Annotations:
FreeBSD_version: 13?
. . .

I'm unclear if you build your own ports vs. use
pkg install to get ones from the FreeBSD servers.

But, either way, if I understand right, the warning
implies the above (presuming you have not forced
a definition of ABI). I'm not sure if a definition
of ABI can lead to such notices when it mismatches
with the architecture/annotations for pkg.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Bind9 security upgrade

2021-02-07 Thread Mark Millard via freebsd-ports
> On arm64 (Pi3) under 
> FreeBSD pelorus.zefox.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 #2 
> stable/13-c256281-gc415d0df47f: Fri Feb  5 08:09:12 PST 2021 
> bob at pelorus.zefox.org
> :/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCAM  arm64
> it looks like dialog4ports is out of whack. It doesn't 
> display in the usual way, the dialog box is outlined by 
> characters such as ^@^@^@^@^@^@^@^ across the top
> and < down the left margin. The background color varies,
> parts white, green and  black. The display is distorted 
> both on the HDMI console and in an X window on the system.
> It's equally but differently addled on a RaspiOS xterm.
> 
> Worse yet, when selecting , it dumps core and fails
> to save changes. That's a real troublemaker. Is there
> a simple way to omit docs from the build without using
> dialog4ports?
> 

Did you rebuild dialog4ports after:

20210105:
ncurses installation has been modified to only keep the widechar
enabled version.  Incremental build is broken for that change, so it
requires a clean build.

? Even if you did: Unfortunately, they did not make such an UPDATING
note for libraries that use ncurses when they updated those to avoid
the dependency on the now-missing ncurses material:

QUOTE
author  John Baldwin  2021-02-02 01:09:33 +
committer   John Baldwin  2021-02-02 01:11:49 +
commit  0b7f1af804f06a285717b490bef80e24648adcbe (patch)
treee35db81ed51f71ccc1afc82c7cd04e8bb2fb8860
parent  7787e7eed9d2a43fb6eb6040f1b495995a2f (diff)
downloadsrc-0b7f1af804f06a285717b490bef80e24648adcbe.tar.gz
src-0b7f1af804f06a285717b490bef80e24648adcbe.zip

Bump shared library versions after ncurses bump in 13.
A few shared libraries in the base system link against ncurses.  An
upgrade from a 12.x host to 13 results in ABI breakage for existing
binaries since the newer versions of these libraries link against the
newer ncurses while the binary itself links against the older ncurses.
For example, dialog4ports built on 12.x sometimes crashes on 13 since
it depends on libdialog which links against ncurses internally.

MFC after:  3 days
Reviewed by:kib, delphij
Differential Revision:  
https://reviews.freebsd.org/D28448
. . .

diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc
index 29cf25e152e6..696243470b14 100644
--- a/ObsoleteFiles.inc
+++ b/ObsoleteFiles.inc
@@ -36,6 +36,17 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 20210201: bump shared libraries which link against ncurses
+OLD_LIBS+=lib/libedit.so.7
+OLD_LIBS+=usr/lib/libdialog.so.8
. . .
END QUOTE

So now there is a /usr.lib/libdialog.so.9 instead and
a correctly built dialog4ports will show it in the
ldd output:

# ldd `which dialog4ports`
/usr/local/bin/dialog4ports:
libncursesw.so.9 => /lib/libncursesw.so.9 (0x402a1000)
libm.so.5 => /lib/libm.so.5 (0x4033a000)
libdialog.so.9 => /usr/lib/libdialog.so.9 (0x403a5000)
libc.so.7 => /lib/libc.so.7 (0x40408000)

An incorrectly built dialog4ports will show
/usr.lib/libdialog.so.8 instead.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Bind9 security upgrade

2021-02-06 Thread Mark Millard via freebsd-ports

https://www.freshports.org/devel/autoconf reports that
perl is a dependency:

Build dependencies:
• gm4 : devel/m4
• help2man : misc/help2man
• gmake : devel/gmake
• makeinfo : print/texinfo
• perl5>=5.28.r1<5.29 : lang/perl5.28
Runtime dependencies:
• gm4 : devel/m4
• autoconf-wrapper : devel/autoconf-wrapper
• perl5>=5.28.r1<5.29 : lang/perl5.28
• indexinfo : print/indexinfo

The Makefile has as shown by:

# grep perl /usr/ports/devel/autoconf/Makefile
USES=   gmake makeinfo perl5 tar:xz

This suggests that your system may be messed up
by having some indication that some lang/perl5.*
is installed, despite things being missing. That
would be consistent with your report of:

/usr/local/lib/perl5/5.30/perl/man/man1/perl.1.gz

existing. /usr/ports/UPDATING reports:

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

  The default Perl version has been switched to Perl 5.32.  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
  instructions in entry 20161103, it should still be the same.



What does:

pkg info perl5

report?

You may need to cause a delete of messed up material
and then a reinstall if that command reports that
perl5 is installed.


An example output for reference:

# pkg info perl5
perl5-5.32.0_1
Name   : perl5
Version: 5.32.0_1
Installed on   : Sat Jan 30 01:49:54 2021 PST
Origin : lang/perl5.32
Architecture   : FreeBSD:14:aarch64
Prefix : /usr/local
Categories : devel perl5 lang
Licenses   : GPLv1+, ART10
Maintainer : m...@freebsd.org
WWW: https://www.perl.org/
Comment: Practical Extraction and Report Language
Options:
DEBUG  : off
DOT_INC: off
GDBM   : off
MULTIPLICITY   : on
PERL_64BITINT  : on
PERL_MALLOC: off
SITECUSTOMIZE  : off
THREADS: on
Shared Libs provided:
libperl.so.5.32
Annotations:
FreeBSD_version: 142
cpe: cpe:2.3:a:perl:perl:5.32.0:freebsd14:aarch64:1
repo_type  : binary
repository : custom
Flat size  : 71.6MiB
Description:
Perl is a language that combines some of the features of C, sed, awk and
shell.  See the manual page for more hype.  There are also many books
published by O'Reilly & Assoc.  See pod/perlbook.pod for more
information.

WWW: https://www.perl.org/


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Bind9 security upgrade

2021-02-06 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Sat Feb 6 16:50:16 UTC 2021 :

> Looks like a path problem, so
> 
> root at pelorus
> :/usr/ports/devel/autoconf # $PATH
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin: 
> Command not found.
> 
> Paths look reasonable, but what's with "Command not found" in response to 
> $PATH ?

Most folks would type something like:

echo $PATH

in order to see the translation of PATH .

But you typed to use the translation of PATH as the command
to execute. There is no command with the path:

/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin

Thus the error that it reported.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: "pkg-static: POST-INSTALL script failed" during poudriere based builds: gettext-tools install can attempt use of indexinfo before print/indexinfo is installed for the build

2021-02-04 Thread Mark Millard via freebsd-ports



On 2021-Feb-4, at 16:47, Tatsuki Makino  wrote:

> Mark Millard wrote on 2021/02/05 09:39:
>> 
>> 
>> On 2021-Feb-4, at 15:54, Tatsuki Makino  
>> wrote:
>> 
>>> Is there indexinfo in deps in +MANIFEST extracted from your 
>>> /usr/local/poudriere/data/packages/FBSDpowerpc64-default/.building/All/indexinfo-0.3.1.txz
>>>  ?
>> 
> 
> Sorry. I'm so sorry. This is my copy and paste mistake.

No problem.

> /usr/local/poudriere/data/packages/FBSDpowerpc64-default/.building/All/"gettext-tools-0.21.txz"
>  instead of indexinfo-0.3.1.txz
> If it is normal, there will be indexinfo after deps. Like below.
> 
> ... 
> "deps":{"gettext-runtime":{"origin":"devel/gettext-runtime","version":"0.21"},"indexinfo":{"origin":"print/indexinfo","version":"0.3.1"},
>  ...

# tar -xpf 
/usr/local/poudriere/data/packages/FBSDpowerpc64-default/.building/All/gettext-tools-0.21.txz
# grep deps +MANIFEST
#

So no "deps" at all. That indicates that I've been looking in
the wrong place.

Looking in: gettext-tools-0.21.log I find:

===
===>  Building package for gettext-tools-0.21
Child process pid=44950 terminated abnormally: Segmentation fault
Child process pid=44956 terminated abnormally: Segmentation fault
actual-package-depends: dependency on /usr/local/lib/libtextstyle.so not 
registered (normal if it belongs to base)
Child process pid=44958 terminated abnormally: Segmentation fault
Child process pid=44962 terminated abnormally: Segmentation fault
Child process pid=44971 terminated abnormally: Segmentation fault
actual-package-depends: dependency on /usr/local/lib/libintl.so not registered 
(normal if it belongs to base)
Child process pid=44973 terminated abnormally: Segmentation fault
Child process pid=44977 terminated abnormally: Segmentation fault
Child process pid=44980 terminated abnormally: Segmentation fault
actual-package-depends: dependency on /usr/local/bin/indexinfo not registered 
(normal if it belongs to base)
Child process pid=44982 terminated abnormally: Segmentation fault

(Prior to that looks normal so far.)

Interestingly those are the only "Segmentation fault" notices
so far in the logs for the (currently 201+) builds:

# grep Segmentation 
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/*.log
 | more
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44950 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44956 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44958 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44962 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44971 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44973 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44977 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44980 terminated abnormally: Segmentation fault
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s/logs/gettext-tools-0.21.log:Child
 process pid=44982 terminated abnormally: Segmentation fault

So only gettext-tools seems to have had the problem.

It is too bad that the port build process does not handle
such as an error and record the .txz of the build attempt's
status. I would have had something to look at then.

Thanks much for getting me pointed in the right direction.
Now I'll need to figure out how to investigate the package
phase of building gettext-tools (at last once the overall
build completes).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: "pkg-static: POST-INSTALL script failed" during poudriere based builds: gettext-tools install can attempt use of indexinfo before print/indexinfo is installed for the build

2021-02-04 Thread Mark Millard via freebsd-ports



On 2021-Feb-4, at 15:54, Tatsuki Makino  wrote:

> make -C /usr/ports/devel/gettext-tools -V _STAGE_SEQ
> 
> is usually
> 
> ... 150:run-depends ... 750:post-install-script ...
> 
> So, RUN_DEPENDS is sufficient for that.

Okay. Good to know, thanks.

> I suspect that RUN_DEPENDS is not recorded in gettext-tools-0.21.txz either.
> There might be something somewhere that erases the definition of INFO.
> 
> Is there indexinfo in deps in +MANIFEST extracted from your 
> /usr/local/poudriere/data/packages/FBSDpowerpc64-default/.building/All/indexinfo-0.3.1.txz
>  ?

# tar -xpf 
/usr/local/poudriere/data/packages/FBSDpowerpc64-default/.building/All/indexinfo-0.3.1.txz
tar: Removing leading '/' from member names
# cat +MANIFEST 
{"name":"indexinfo","origin":"print/indexinfo","version":"0.3.1","comment":"Utility
 to regenerate the GNU info page 
index","maintainer":"b...@freebsd.org","www":"https://github.com/bapt/indexinfo","abi":"FreeBSD:14:powerpc64","arch":"freebsd:14:powerpc:64:eb","prefix":"/usr/local","flatsize":37247,"licenselogic":"single","licenses":["BSD2CLAUSE"],"desc":"Small
 utility designed to regenerate the GNU info page indexes\n\nWWW: 
https://github.com/bapt/indexinfo","categories":["ports-mgmt","print"],"annotations":{"FreeBSD_version":"143"},"files":{"/usr/local/bin/indexinfo":"1$0231cd46617eb332e640aec15dee7f273a675e8f9669154d821613232de51c20","/usr/local/share/licenses/indexinfo-0.3.1/catalog.mk":"1$2db081dfa45ee21ff5fcdab1dd9611a513adbce0ed2e5de9916af182388dbb21","/usr/local/share/licenses/indexinfo-0.3.1/LICENSE":"1$5a0d3730c307e5043500dfa15cbf67dbd44c48215a7cacc445347d55b8c6bf77","/usr/local/share/licenses/indexinfo-0.3.1/BSD2CLAUSE":"1$1f5bf6112c6c74e5aa1dfbee2c4d6a15a52a8643a5e2523
 16e4e573768e2d2c5"}}

> Mark Millard wrote on 2021/02/05 08:33:
>> 
>> 
>> On 2021-Feb-4, at 15:11, Tatsuki Makino  
>> wrote:
>> 
>>> In rare cases, a package with missing contents may be created.
>>> If there is a problem after checking with
>>> 
>>> tar -t -f 
>>> /usr/local/poudriere/data/packages/jail-portstree/All/indexinfo-0.3.1.txz
>>> 
>>> , etc., you can force it to be rebuilt by doing the following:
>>> 
>>> poudriere bulk -j jail -p portstree -C print/indexinfo
>> 
>> That is not, of itself, going to change anything. This whole
>> build (that is still going) was based on -c (and I show
>> from print/indexinfo starting through gettext-tools finishing ):
> 
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: "pkg-static: POST-INSTALL script failed" during poudriere based builds: gettext-tools install can attempt use of indexinfo before print/indexinfo is installed for the build

2021-02-04 Thread Mark Millard via freebsd-ports
On 2021-Feb-4, at 15:33, Mark Millard  wrote:

> On 2021-Feb-4, at 15:11, Tatsuki Makino  wrote:
> 
>> In rare cases, a package with missing contents may be created.
>> If there is a problem after checking with
>> 
>> tar -t -f 
>> /usr/local/poudriere/data/packages/jail-portstree/All/indexinfo-0.3.1.txz
>> 
>> , etc., you can force it to be rebuilt by doing the following:
>> 
>> poudriere bulk -j jail -p portstree -C print/indexinfo

Better evidence that the content is not missing:

# tar -tf 
/usr/local/poudriere/data/packages/FBSDpowerpc64-default/.building/All/indexinfo-0.3.1.txz
 | grep indexinfo
/usr/local/bin/indexinfo
/usr/local/share/licenses/indexinfo-0.3.1/catalog.mk
/usr/local/share/licenses/indexinfo-0.3.1/LICENSE
/usr/local/share/licenses/indexinfo-0.3.1/BSD2CLAUSE

> That is not, of itself, going to change anything. This whole
> build (that is still going) was based on -c (and I show
> from print/indexinfo starting through gettext-tools finishing ):
> 
> # poudriere bulk -jFBSDpowerpc64 -c -w -f ~/origins/powerpc64-origins.txt
> . . .
> [00:03:36] (-c) Cleaning all packages... done
> . . .
> [00:15:03] [01] [00:00:00] Building print/indexinfo | indexinfo-0.3.1
> [00:15:03] [02] [00:00:00] Building devel/pkgconf | pkgconf-1.7.3,1
> [00:15:18] [01] [00:00:15] Finished print/indexinfo | indexinfo-0.3.1: Success
> [00:15:19] [01] [00:00:00] Building devel/gettext-runtime | 
> gettext-runtime-0.21
> [00:16:07] [02] [00:01:04] Finished devel/pkgconf | pkgconf-1.7.3,1: Success
> [00:16:10] [02] [00:00:00] Building devel/libtextstyle | libtextstyle-0.21
> [00:20:35] [01] [00:05:16] Finished devel/gettext-runtime | 
> gettext-runtime-0.21: Success
> [00:21:19] [01] [00:00:00] Building devel/libffi | libffi-3.3_1
> [00:23:31] [02] [00:07:21] Finished devel/libtextstyle | libtextstyle-0.21: 
> Success
> [00:23:54] [01] [00:02:35] Finished devel/libffi | libffi-3.3_1: Success
> [00:24:02] [01] [00:00:00] Building devel/readline | readline-8.0.4
> [00:24:17] [02] [00:00:00] Building devel/gettext-tools | gettext-tools-0.21
> [00:25:54] [01] [00:01:52] Finished devel/readline | readline-8.0.4: Success
> [00:25:56] [01] [00:00:00] Building lang/perl5.32 | perl5-5.32.0_1
> [00:55:34] [02] [00:31:17] Finished devel/gettext-tools | gettext-tools-0.21: 
> Success
> . . .
> 
> For reference for the on going build:
> 
> load: 3.67  cmd: paste 72178 [runnable] 0.03r 0.00u 0.00s 0% 196k
> mi_switch+0x144 kern_yield+0x98 maybe_yield+0x4c uiomove_fromphys+0x1c0 
> vn_io_fault_pgmove+0x64 vn_read_from_obj+0x154 ufs_read_pgcache+0x60 
> VOP_READ_PGCACHE_APV+0x54 vn_read+0xbc vn_io_fault_doio+0x78 
> vn_io_fault1+0x1a4 vn_io_fault+0x254 dofileread+0xb0 sys_read+0xf0 trap+0x6fc 
> powerpc_interrupt+0x1b4 
> [FBSDpowerpc64-default] [2021-02-04_02h19m21s] [parallel_build:] Queued: 476 
> Built: 185 Failed: 3   Skipped: 150 Ignored: 0   Tobuild: 138  Time: 12:46:31
>[01]: devel/boost-libs  | boost-libs-1.72.0_3   stage  
>  (05:15:27 / 07:05:58)
>[02]: lang/gcc10| gcc10-10.2.0  build  
>  (02:04:18 / 02:11:34)
> [12:47:16] Logs: 
> /usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s
> 
> 
> If you look at the devel/gettext-tools/Makefile you will
> find a lack of any specificiation that indexinfo is used
> at build time (BUILD_DEPENDS). The likes of /usr/ports/Mk/bsd.port.mk
> only lists indexinfo in RUN_DEPENDS.
> 
> The dependency is missing as far as I can tell. If so, it
> needs to be added.
> 
>> Mark Millard wrote on 2021/02/05 07:58:
>>> 
>>> 
>>> On 2021-Feb-4, at 14:44, Tatsuki Makino  
>>> wrote:
>>> 
 Hello.
 
 It's the one that happens when environment variable PATH does not contain 
 ${LOCALBASE}/bin.
>>> 
>>> Unforutunately, it is not that simple. The log files show that
>>> /usr/local/bin is listed in each PATH for each failing context:
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: "pkg-static: POST-INSTALL script failed" during poudriere based builds: gettext-tools install can attempt use of indexinfo before print/indexinfo is installed for the build

2021-02-04 Thread Mark Millard via freebsd-ports



On 2021-Feb-4, at 15:11, Tatsuki Makino  wrote:

> In rare cases, a package with missing contents may be created.
> If there is a problem after checking with
> 
> tar -t -f 
> /usr/local/poudriere/data/packages/jail-portstree/All/indexinfo-0.3.1.txz
> 
> , etc., you can force it to be rebuilt by doing the following:
> 
> poudriere bulk -j jail -p portstree -C print/indexinfo

That is not, of itself, going to change anything. This whole
build (that is still going) was based on -c (and I show
from print/indexinfo starting through gettext-tools finishing ):

# poudriere bulk -jFBSDpowerpc64 -c -w -f ~/origins/powerpc64-origins.txt
. . .
[00:03:36] (-c) Cleaning all packages... done
. . .
[00:15:03] [01] [00:00:00] Building print/indexinfo | indexinfo-0.3.1
[00:15:03] [02] [00:00:00] Building devel/pkgconf | pkgconf-1.7.3,1
[00:15:18] [01] [00:00:15] Finished print/indexinfo | indexinfo-0.3.1: Success
[00:15:19] [01] [00:00:00] Building devel/gettext-runtime | gettext-runtime-0.21
[00:16:07] [02] [00:01:04] Finished devel/pkgconf | pkgconf-1.7.3,1: Success
[00:16:10] [02] [00:00:00] Building devel/libtextstyle | libtextstyle-0.21
[00:20:35] [01] [00:05:16] Finished devel/gettext-runtime | 
gettext-runtime-0.21: Success
[00:21:19] [01] [00:00:00] Building devel/libffi | libffi-3.3_1
[00:23:31] [02] [00:07:21] Finished devel/libtextstyle | libtextstyle-0.21: 
Success
[00:23:54] [01] [00:02:35] Finished devel/libffi | libffi-3.3_1: Success
[00:24:02] [01] [00:00:00] Building devel/readline | readline-8.0.4
[00:24:17] [02] [00:00:00] Building devel/gettext-tools | gettext-tools-0.21
[00:25:54] [01] [00:01:52] Finished devel/readline | readline-8.0.4: Success
[00:25:56] [01] [00:00:00] Building lang/perl5.32 | perl5-5.32.0_1
[00:55:34] [02] [00:31:17] Finished devel/gettext-tools | gettext-tools-0.21: 
Success
. . .

For reference for the on going build:

load: 3.67  cmd: paste 72178 [runnable] 0.03r 0.00u 0.00s 0% 196k
mi_switch+0x144 kern_yield+0x98 maybe_yield+0x4c uiomove_fromphys+0x1c0 
vn_io_fault_pgmove+0x64 vn_read_from_obj+0x154 ufs_read_pgcache+0x60 
VOP_READ_PGCACHE_APV+0x54 vn_read+0xbc vn_io_fault_doio+0x78 vn_io_fault1+0x1a4 
vn_io_fault+0x254 dofileread+0xb0 sys_read+0xf0 trap+0x6fc 
powerpc_interrupt+0x1b4 
[FBSDpowerpc64-default] [2021-02-04_02h19m21s] [parallel_build:] Queued: 476 
Built: 185 Failed: 3   Skipped: 150 Ignored: 0   Tobuild: 138  Time: 12:46:31
[01]: devel/boost-libs  | boost-libs-1.72.0_3   stage   
(05:15:27 / 07:05:58)
[02]: lang/gcc10| gcc10-10.2.0  build   
(02:04:18 / 02:11:34)
[12:47:16] Logs: 
/usr/local/poudriere/data/logs/bulk/FBSDpowerpc64-default/2021-02-04_02h19m21s


If you look at the devel/gettext-tools/Makefile you will
find a lack of any specificiation that indexinfo is used
at build time (BUILD_DEPENDS). The likes of /usr/ports/Mk/bsd.port.mk
only lists indexinfo in RUN_DEPENDS.

The dependency is missing as far as I can tell. If so, it
needs to be added.

> Mark Millard wrote on 2021/02/05 07:58:
>> 
>> 
>> On 2021-Feb-4, at 14:44, Tatsuki Makino  
>> wrote:
>> 
>>> Hello.
>>> 
>>> It's the one that happens when environment variable PATH does not contain 
>>> ${LOCALBASE}/bin.
>> 
>> Unforutunately, it is not that simple. The log files show that
>> /usr/local/bin is listed in each PATH for each failing context:
> 
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: "pkg-static: POST-INSTALL script failed" during poudriere based builds: gettext-tools install can attempt use of indexinfo before print/indexinfo is installed for the build

2021-02-04 Thread Mark Millard via freebsd-ports



On 2021-Feb-4, at 14:44, Tatsuki Makino  wrote:

> Hello.
> 
> It's the one that happens when environment variable PATH does not contain 
> ${LOCALBASE}/bin.

Unforutunately, it is not that simple. The log files show that
/usr/local/bin is listed in each PATH for each failing context:

rhash-1.4.0.log . . .

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
LOCALBASE=/usr/local
. . .
--CONFIGURE_ENV--
. . . 
PATH=/wrkdirs/usr/ports/security/rhash/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
. . .
--MAKE_ENV--
. . . 
PATH=/wrkdirs/usr/ports/security/rhash/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
. . .



glib-2.66.3,1.log . . .

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
LOCALBASE=/usr/local
. . .
--MAKE_ENV--
. . . 
PATH=/wrkdirs/usr/ports/devel/glib20/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
. . .



libXpm-3.5.13.log . . .

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
LOCALBASE=/usr/local
. . .
--CONFIGURE_ENV--
. . . 
PATH=/wrkdirs/usr/ports/x11/libXpm/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
. . .
--MAKE_ENV--
. . . 
PATH=/wrkdirs/usr/ports/x11/libXpm/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
. . .



> Mark Millard via freebsd-ports wrote on 2021/02/05 07:14:
>> 
>> Looks like print/indexinfo is not being installed before
>> installing gettext-tools tries to use indexinfo in various
>> contexts.
>> 
>> 
>> ===
>> ===>   rhash-1.4.0 depends on executable: msgfmt - not found
>> ===>   Installing existing package /packages/All/gettext-tools-0.21.txz
>> [FBSDG5L] Installing gettext-tools-0.21...
>> [FBSDG5L] Extracting gettext-tools-0.21: .. done
>> /bin/sh: indexinfo: not found
>> pkg-static: POST-INSTALL script failed
>> ===>   rhash-1.4.0 depends on executable: msgfmt - found
>> ===>   Returning to build of rhash-1.4.0
>> ===
>> ===
>> ===>   rhash-1.4.0 depends on shared library: libintl.so - not found
>> ===>   Installing existing package /packages/All/gettext-runtime-0.21.txz
>> [FBSDG5L] Installing gettext-runtime-0.21...
>> [FBSDG5L] `-- Installing indexinfo-0.3.1...
>> [FBSDG5L] `-- Extracting indexinfo-0.3.1:  done
>> [FBSDG5L] Extracting gettext-runtime-0.21: .. done
>> ===>   rhash-1.4.0 depends on shared library: libintl.so - found 
>> (/usr/local/lib/libintl.so)
>> ===>   Returning to build of rhash-1.4.0
>> 
>> 
>> and:
>> 
>> ===>   glib-2.66.3,1 depends on executable: msgfmt - not found
>> ===>   Installing existing package /packages/All/gettext-tools-0.21.txz
>> [FBSDG5L] Installing gettext-tools-0.21...
>> [FBSDG5L] Extracting gettext-tools-0.21: .. done
>> /bin/sh: indexinfo: not found
>> pkg-static: POST-INSTALL script failed
>> ===>   glib-2.66.3,1 depends on executable: msgfmt - found
>> ===>   Returning to build of glib-2.66.3,1
>> ===>   glib-2.66.3,1 depends on executable: xsltproc - not found
>> ===>   Installing existing package /packages/All/libxslt-1.1.34_1.txz
>> [FBSDG5L] Installing libxslt-1.1.34_1...
>> [FBSDG5L] `-- Installing libgcrypt-1.8.7...
>> [FBSDG5L] |   `-- Installing indexinfo-0.3.1...
>> [FBSDG5L] |   `-- Extracting indexinfo-0.3.1:  done
>> . . .
>> ===>   glib-2.66.3,1 depends on executable: xsltproc - found
>> ===>   Returning to build of glib-2.66.3,1
>> 
>> 
>> and:
>> 
>> ===>   libXpm-3.5.13 depends on executable: msgfmt - not found
>> ===>   Installing existing package /packages/All/gettext-tools-0.21.txz
>> [FBSDG5L] Installing gettext-tools-0.21...
>> [FBSDG5L] Extracting gettext-tools-0.21: .. done
>> /bin/sh: indexinfo: not found
>> pkg-static: POST-INSTALL script failed
>> ===>   libXpm-3.5.13 depends on executable: msgfmt - found
>> ===>   Returning to build of libXpm-3.5.13
>> . . .
>> ===
>> ===>   libXpm-3.5.13 depends on shared library: libintl.so - not found
>> ===>   Installing existing package /packages/All/gettext-runtime-0.21.txz
>> [FBSDG5L] Installing gettext-runtime-0.21...
>> [FBSDG5L] `-- Installing indexinfo-0.3.1...
>> [FBSDG5L] `-- Extracting indexinfo-0.3.1:  done
>> [FBSDG5L] Extracting gettext-runtime-0.21: .

"pkg-static: POST-INSTALL script failed" during poudriere based builds: gettext-tools install can attempt use of indexinfo before print/indexinfo is installed for the build

2021-02-04 Thread Mark Millard via freebsd-ports


Looks like print/indexinfo is not being installed before
installing gettext-tools tries to use indexinfo in various
contexts.


===
===>   rhash-1.4.0 depends on executable: msgfmt - not found
===>   Installing existing package /packages/All/gettext-tools-0.21.txz
[FBSDG5L] Installing gettext-tools-0.21...
[FBSDG5L] Extracting gettext-tools-0.21: .. done
/bin/sh: indexinfo: not found
pkg-static: POST-INSTALL script failed
===>   rhash-1.4.0 depends on executable: msgfmt - found
===>   Returning to build of rhash-1.4.0
===
===
===>   rhash-1.4.0 depends on shared library: libintl.so - not found
===>   Installing existing package /packages/All/gettext-runtime-0.21.txz
[FBSDG5L] Installing gettext-runtime-0.21...
[FBSDG5L] `-- Installing indexinfo-0.3.1...
[FBSDG5L] `-- Extracting indexinfo-0.3.1:  done
[FBSDG5L] Extracting gettext-runtime-0.21: .. done
===>   rhash-1.4.0 depends on shared library: libintl.so - found 
(/usr/local/lib/libintl.so)
===>   Returning to build of rhash-1.4.0


and:

===>   glib-2.66.3,1 depends on executable: msgfmt - not found
===>   Installing existing package /packages/All/gettext-tools-0.21.txz
[FBSDG5L] Installing gettext-tools-0.21...
[FBSDG5L] Extracting gettext-tools-0.21: .. done
/bin/sh: indexinfo: not found
pkg-static: POST-INSTALL script failed
===>   glib-2.66.3,1 depends on executable: msgfmt - found
===>   Returning to build of glib-2.66.3,1
===>   glib-2.66.3,1 depends on executable: xsltproc - not found
===>   Installing existing package /packages/All/libxslt-1.1.34_1.txz
[FBSDG5L] Installing libxslt-1.1.34_1...
[FBSDG5L] `-- Installing libgcrypt-1.8.7...
[FBSDG5L] |   `-- Installing indexinfo-0.3.1...
[FBSDG5L] |   `-- Extracting indexinfo-0.3.1:  done
. . .
===>   glib-2.66.3,1 depends on executable: xsltproc - found
===>   Returning to build of glib-2.66.3,1


and:

===>   libXpm-3.5.13 depends on executable: msgfmt - not found
===>   Installing existing package /packages/All/gettext-tools-0.21.txz
[FBSDG5L] Installing gettext-tools-0.21...
[FBSDG5L] Extracting gettext-tools-0.21: .. done
/bin/sh: indexinfo: not found
pkg-static: POST-INSTALL script failed
===>   libXpm-3.5.13 depends on executable: msgfmt - found
===>   Returning to build of libXpm-3.5.13
. . .
===
===>   libXpm-3.5.13 depends on shared library: libintl.so - not found
===>   Installing existing package /packages/All/gettext-runtime-0.21.txz
[FBSDG5L] Installing gettext-runtime-0.21...
[FBSDG5L] `-- Installing indexinfo-0.3.1...
[FBSDG5L] `-- Extracting indexinfo-0.3.1:  done
[FBSDG5L] Extracting gettext-runtime-0.21: .. done
===>   libXpm-3.5.13 depends on shared library: libintl.so - found 
(/usr/local/lib/libintl.so)
===>   Returning to build of libXpm-3.5.13


Looks like devel/gettext-tools/Makefile needs something
like:

BUILD_DEPENDS+= indexinfo:print/indexinfo

Although this might be viewed as a /usr/ports/Mk/bsd.port.mk
issue that needs such instead. As things are there is:

.if defined(INFO)
RUN_DEPENDS+=   indexinfo:print/indexinfo
. . .

but there is no BUILD_DEPENDS addition there.


The poudriere run will likely be going for a couple of days.
There could be more examples in the 476 ports it is trying
to build, possibly things other than involving gettext-tools.
(I'm trying to update an old PowerMac powerpc64 context to
FreeBSD:14 based ABI builds for ports.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Warning: Major OS version upgrade detected

2021-01-30 Thread Mark Millard via freebsd-ports
Xavier Humbert xavier at groumpf.org wrote on
Sat Jan 30 22:02:51 UTC 2021 :

> I was running 13-CURRENT, and as of 01/22 I switched to 13-STABLE
> 
> Now, when I run any ports/pkg command - I use only ports-, I got
> 
> > pkg-static: Warning: Major OS version upgrade detected.  Running "pkg 
> > bootstrap -f" recommended
> No a big deal, I thought, but :
> 
> > [root at numenor ~]# pkg bootstrap -f
> > The package management tool is not yet installed on your system.
> > Do you want to fetch and install it now? [y/N]: y
> > Bootstrapping pkg from 
> > pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest, please wait...
> > Verifying signature with trusted certificate 
> > pkg.freebsd.org.2013102301... done
> > pkg-static: Warning: Major OS version upgrade detected.  Running "pkg 
> > bootstrap -f" recommended
> > Installing pkg-1.16.2...
> > pkg-static: wrong architecture: FreeBSD:13:amd64 instead of 
> > *FreeBSD:14:amd64*
> > package pkg is already installed, forced install
> > Extracting pkg-1.16.2: 100%
> > [root at numenor ~]# pkg check -Bd
> > pkg: Warning: Major OS version upgrade detected.  Running "pkg 
> > bootstrap -f" recommended
> 
> The message is still there. I never had 14-CURRENT on this system.
> 
> Reinstalled ports-mgmt/pkg from source, didn't help
> 


I stayed on main but how to follow from main to stable/N is of
interest. So I'll watch to see what you learn. (I only just
finished updating everything to 14, including all my
from-source ports builds, but skipping powerpc and powerpc64.)

It would be interesting to know the commit-id of the last
main branch commit that you had. This might be essential
to someone being able to figure out what happened.

author  Glen Barber   2021-01-22 00:06:26 +
committer   Glen Barber   2021-01-22 00:08:57 +
commit  bfd15705156b0436cfe79aea11868dcc0c6e078a (patch)
Create the stable/13 branch

author  Glen Barber   2021-01-22 00:10:07 +
committer   Glen Barber   2021-01-22 00:10:07 +
commit  a53ce3fc4938e37d5ec89304846203d2083c61a2 (patch)
Bump CURRENT to 14.0

There is not much time (minutes) after stable/13 was created
before main switched to 14.

The 30,000+ package builds did not start for more than a day
after that for main and for stable/13 (and each takes more
than 2 days to build):

main-amd64 default   build start: Sat, 23 Jan 2021 01:25:15 GMT

13stable-amd64 quarterly build start: Sun, 24 Jan 2021 01:33:13 GMT
13stable-amd64 default   build start: Sun, 24 Jan 2021 01:34:10 GMT

So it would seem unlikely you could have picked up a pkg that was
built for/from stable/13 or main as 14-CURRENT on Jan-22nd or soon
after.

This leaves me curious about what to avoid at such transitions.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: math/suitesparse from ports head -r557893 fails for armv7 by default: "/usr/local/bin/ld: cannot find -lomp"

2020-12-14 Thread Mark Millard via freebsd-ports
On 2020-Dec-14, at 13:34, Mark Millard  wrote:

> This was on aarch64 doing a build targeting armv7 via poudriere --but might 
> apply to other platforms that by default do not have LLVM's OpenMP runtime:
> 
>WITHOUT_OPENMP
> Set to not build LLVM's OpenMP runtime.
> 
> This is a default setting on arm/armv6, arm/armv7, mips/mips,
> mips/mips64, powerpc/powerpc, riscv/riscv64 and riscv/riscv64sf.
> 
> # poudriere jail -jFBSDFSSDjailArmV7 -i
> Jail name: FBSDFSSDjailArmV7
> Jail version:  13.0-CURRENT
> Jail arch: arm.armv7
> Jail method:   null
> Jail mount:/usr/obj/DESTDIRs/clang-armv7-installworld-poud
> Jail fs:   
> Jail updated:  2020-04-21 22:39:35
> 
> /usr/obj/DESTDIRs/clang-armv7-installworld-poud is at: head -r368500
> (as is the containing aarch64 environment).
> 
> Apparently, armv7 (at least) requires a manual/explicit OPENMP=off 
> configuration option for math/suitesparse . Is this intentional?
> 
> 
> poudriere reported:
> 
> [02:42:51] [01] [00:00:00] Building math/suitesparse | suitesparse-5.8.1
> [02:46:41] [01] [00:03:50] Saving math/suitesparse | suitesparse-5.8.1 wrkdir
> [02:46:45] [01] [00:03:54] Saved math/suitesparse | suitesparse-5.8.1 wrkdir 
> to: 
> /usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/suitesparse-5.8.1.tar
> [02:46:55] [01] [00:04:04] Finished math/suitesparse | suitesparse-5.8.1: 
> Failed: build
> [02:46:59] [01] [00:04:08] Skipping math/eigen3 | eigen-3.3.8: Dependent port 
> math/suitesparse | suitesparse-5.8.1 failed
> [02:46:59] [01] [00:04:08] Skipping multimedia/ffmpeg | ffmpeg-4.3.1_9,1: 
> Dependent port math/suitesparse | suitesparse-5.8.1 failed
> [02:46:59] [01] [00:04:08] Skipping multimedia/gstreamer1-libav | 
> gstreamer1-libav-1.16.2: Dependent port math/suitesparse | suitesparse-5.8.1 
> failed
> [02:46:59] [01] [00:04:08] Skipping multimedia/gstreamer1-plugins-core | 
> gstreamer1-plugins-core-1.16: Dependent port math/suitesparse | 
> suitesparse-5.8.1 failed
> [02:46:59] [01] [00:04:08] Skipping x11/lumina | lumina-1.6.0,3: Dependent 
> port math/suitesparse | suitesparse-5.8.1 failed
> [02:46:59] [01] [00:04:08] Skipping x11/lumina-core | lumina-core-1.6.0: 
> Dependent port math/suitesparse | suitesparse-5.8.1 failed
> [02:46:59] [01] [00:04:08] Skipping graphics/opencv-core | 
> opencv-core-3.4.1_37: Dependent port math/suitesparse | suitesparse-5.8.1 
> failed
> . . .
> [02:48:20] Failed ports: math/suitesparse:build
> [02:48:20] Skipped ports: graphics/opencv-core math/eigen3 multimedia/ffmpeg 
> multimedia/gstreamer1-libav multimedia/gstreamer1-plugins-core x11/lumina 
> x11/lumina-core
> 
> (That last gives a clue what types of things are blocked by the failure.)
> 
> The log showed the -lomp issue:
> 
> . . .
> /usr/local/bin/ranlib libcholmod.a
> /usr/local/bin/ld: cannot find -lomp
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> gmake[4]: *** [Makefile:544: 
> /wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/lib/libcholmod.so.3.0.14]
>  Error 1
> gmake[4]: Leaving directory 
> '/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/CHOLMOD/Lib'
> gmake[3]: *** [Makefile:31: library] Error 2
> gmake[3]: Leaving directory 
> '/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/CHOLMOD/Lib'
> gmake[2]: *** [Makefile:19: library] Error 2
> gmake[2]: Leaving directory 
> '/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/CHOLMOD'
> gmake[1]: *** [Makefile:135: library] Error 2
> gmake[1]: Leaving directory 
> '/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1'
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> . . .
> 
> Other context details . . .
> 
> # svnlite info /usr/ports/
> Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: svn://svn.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 557893
> Node Kind: directory
> Schedule: normal
> Last Changed Author: manu
> Last Changed Rev: 557893
> Last Changed Date: 2020-12-13 03:53:57 -0800 (Sun, 13 Dec 2020)
> 
> # uname -apKU
> FreeBSD FBSDmacch 13.0-CURRENT FreeBSD 13.0-CURRENT #47 r368500M: Thu Dec 10 
> 03:15:10 PST 2020 
> root@FBSDFHUGE:/usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG
>   arm64 aarch64 1300131 1300131
> 


An explicit use of OPTIONS_FILE_UNSET+=OPENMP in the below was sufficient to 
allow the build:

# more 
/usr/local/etc/poudriere.d/FBSDFSSDjailArmV7-options/math_suitesparse/options 
# This file is auto-generated by 'make config'.
# Options for suitesparse-5.8.1
_OPTIONS_READ=suitesparse-5.8.1
_FILE_COMPLETE_OPTIONS_LIST=DEMOS DOCS TBB ATLAS GOTOBLAS NETLIB OPENBLAS
OPTIONS_FILE_UNSET+=DEMOS
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=TBB

math/suitesparse from ports head -r557893 fails for armv7 by default: "/usr/local/bin/ld: cannot find -lomp"

2020-12-14 Thread Mark Millard via freebsd-ports
This was on aarch64 doing a build targeting armv7 via poudriere --but might 
apply to other platforms that by default do not have LLVM's OpenMP runtime:

WITHOUT_OPENMP
 Set to not build LLVM's OpenMP runtime.

 This is a default setting on arm/armv6, arm/armv7, mips/mips,
 mips/mips64, powerpc/powerpc, riscv/riscv64 and riscv/riscv64sf.

# poudriere jail -jFBSDFSSDjailArmV7 -i
Jail name: FBSDFSSDjailArmV7
Jail version:  13.0-CURRENT
Jail arch: arm.armv7
Jail method:   null
Jail mount:/usr/obj/DESTDIRs/clang-armv7-installworld-poud
Jail fs:   
Jail updated:  2020-04-21 22:39:35

/usr/obj/DESTDIRs/clang-armv7-installworld-poud is at: head -r368500
(as is the containing aarch64 environment).

Apparently, armv7 (at least) requires a manual/explicit OPENMP=off 
configuration option for math/suitesparse . Is this intentional?


poudriere reported:

[02:42:51] [01] [00:00:00] Building math/suitesparse | suitesparse-5.8.1
[02:46:41] [01] [00:03:50] Saving math/suitesparse | suitesparse-5.8.1 wrkdir
[02:46:45] [01] [00:03:54] Saved math/suitesparse | suitesparse-5.8.1 wrkdir 
to: 
/usr/local/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/suitesparse-5.8.1.tar
[02:46:55] [01] [00:04:04] Finished math/suitesparse | suitesparse-5.8.1: 
Failed: build
[02:46:59] [01] [00:04:08] Skipping math/eigen3 | eigen-3.3.8: Dependent port 
math/suitesparse | suitesparse-5.8.1 failed
[02:46:59] [01] [00:04:08] Skipping multimedia/ffmpeg | ffmpeg-4.3.1_9,1: 
Dependent port math/suitesparse | suitesparse-5.8.1 failed
[02:46:59] [01] [00:04:08] Skipping multimedia/gstreamer1-libav | 
gstreamer1-libav-1.16.2: Dependent port math/suitesparse | suitesparse-5.8.1 
failed
[02:46:59] [01] [00:04:08] Skipping multimedia/gstreamer1-plugins-core | 
gstreamer1-plugins-core-1.16: Dependent port math/suitesparse | 
suitesparse-5.8.1 failed
[02:46:59] [01] [00:04:08] Skipping x11/lumina | lumina-1.6.0,3: Dependent port 
math/suitesparse | suitesparse-5.8.1 failed
[02:46:59] [01] [00:04:08] Skipping x11/lumina-core | lumina-core-1.6.0: 
Dependent port math/suitesparse | suitesparse-5.8.1 failed
[02:46:59] [01] [00:04:08] Skipping graphics/opencv-core | 
opencv-core-3.4.1_37: Dependent port math/suitesparse | suitesparse-5.8.1 failed
. . .
[02:48:20] Failed ports: math/suitesparse:build
[02:48:20] Skipped ports: graphics/opencv-core math/eigen3 multimedia/ffmpeg 
multimedia/gstreamer1-libav multimedia/gstreamer1-plugins-core x11/lumina 
x11/lumina-core

(That last gives a clue what types of things are blocked by the failure.)

The log showed the -lomp issue:

. . .
/usr/local/bin/ranlib libcholmod.a
/usr/local/bin/ld: cannot find -lomp
c++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[4]: *** [Makefile:544: 
/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/lib/libcholmod.so.3.0.14]
 Error 1
gmake[4]: Leaving directory 
'/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/CHOLMOD/Lib'
gmake[3]: *** [Makefile:31: library] Error 2
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/CHOLMOD/Lib'
gmake[2]: *** [Makefile:19: library] Error 2
gmake[2]: Leaving directory 
'/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1/CHOLMOD'
gmake[1]: *** [Makefile:135: library] Error 2
gmake[1]: Leaving directory 
'/wrkdirs/usr/ports/math/suitesparse/work/SuiteSparse-5.8.1'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
. . .

Other context details . . .

# svnlite info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 557893
Node Kind: directory
Schedule: normal
Last Changed Author: manu
Last Changed Rev: 557893
Last Changed Date: 2020-12-13 03:53:57 -0800 (Sun, 13 Dec 2020)

# uname -apKU
FreeBSD FBSDmacch 13.0-CURRENT FreeBSD 13.0-CURRENT #47 r368500M: Thu Dec 10 
03:15:10 PST 2020 
root@FBSDFHUGE:/usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG
  arm64 aarch64 1300131 1300131



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: DEFAULT_VERSIONS+=llvm=90 ignored?

2020-12-05 Thread Mark Millard via freebsd-ports



On 2020-Dec-5, at 07:02, Steve Kargl  
wrote:

> On Sat, Dec 05, 2020 at 01:18:34AM -0800, Mark Millard wrote:
>> Steve Kargl sgk at troutmask.apl.washington.edu wrote on:
>>> 
>>> Well, I guess that pretty much kills LLVM_DEFAULT for any
>>> modern hardware (even a 8 year old laptop) that uses drm
>>> unless a user wants base-system llvm, llvm90, and llvm10 
>>> installed.  One will certainly be able to compile any
>>> c/c++ thrown ones way.
>> 
>> LLVM's API seems to be unstable enough from LLVM release to
>> LLVM release that maintaining many-release build compatibility
>> for projects using the LLVM API is not all that common.
> 
> I'm well aware the llvm API instability, which comes back
> to the irrelevance of LLVM_DEFAULT.  Someday llvm may get
> it's act together.

I frequently have LLVM set to more recent than the
from-svn /usr/ports/Mk/bsd.default-versions.mk
indicates, for other reasons than minimizing the
number of LLVM builds/installs. Seems to work fine
for such in my limited context.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: DEFAULT_VERSIONS+=llvm=90 ignored?

2020-12-05 Thread Mark Millard via freebsd-ports
Steve Kargl sgk at troutmask.apl.washington.edu wrote on:
Fri Dec 4 22:59:46 UTC 2020

> On Fri, Dec 04, 2020 at 11:41:41PM +0100, Jan Beich wrote:
> > Steve Kargl  writes:
> > 
> > > It takes a long time to compile on my laptop.  I have
> > >
> > > DEFAULT_VERSIONS+=llvm=90
> > 
> > Why do you need to redefine current default?
> 
> Simply changed /etc/make.conf on my laptop from 80 to 90
> when I got a similar problem trying to rebuild gnuplot.
> Getting llvm10 when LLVM_DEFAULT=80 or 90 seems dubious.
> 
> > Mk/bsd.default-versions.mk:
> > LLVM_DEFAULT?=  90
> > 
> > > % portmaster -Byd gnuplot
> > > ...
> > > Install devel/llvm10
> > > ...
> > > Install devel/llvm90
> > 
> > devel/llvm10 is pinned by graphics/mesa-* likely to reduce QA after a
> > fiasco in bug 239682. Trying to unpin in bug 250869 was rejected.
> > 
> > graphics/mesa-dri/Makefile.common:
> > LLVM_DEFAULT=   10
> 
> Well, I guess that pretty much kills LLVM_DEFAULT for any
> modern hardware (even a 8 year old laptop) that uses drm
> unless a user wants base-system llvm, llvm90, and llvm10 
> installed.  One will certainly be able to compile any
> c/c++ thrown ones way.

LLVM's API seems to be unstable enough from LLVM release to
LLVM release that maintaining many-release build compatibility
for projects using the LLVM API is not all that common.

I expect that graphics/mesa-* is using the LLVM API, not just
clang/clang++ compilers. Base-system LLVM does not provide the
API (too unstable to hold unchanged for a FreeBSD release support
period). So base-system LLVM is not an option for things using
the LLVM API.

Having all ports using the same LLVM API release is probably
not an option (upstream issues).

In other words: software that chooses to be in part based on the
LLVM API tends to lead to needing various vintages of LLVM to
be installed.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: How to build sysutils/edk2@rpi4 (for example) that matches https://github.com/pftf/RPi4/releases/tag/v1.18 (for example)

2020-08-15 Thread Mark Millard via freebsd-ports
On 2020-Aug-10, at 23:44, Mark Millard  wrote:

> I noticed the sysutils/edk2 addition. So I've tried to figure
> out how to use it to reproduce the pftf RPi4 V1.18 release
> (as an example), by, say, adjusting the distinfo file to pick
> up the matching source.
> 
> Looking at https://github.com/pftf/RPi4/releases/
> there is a 4dd0f24 listed for the most recent release
> (v1.18) that is a link to:
> 
> https://github.com/pftf/RPi4/commit/4dd0f24d03cf73ed8e7bd29f88d8e86779410e69
> 
> That in turn lists the release's changes for Submodules:
> 
> edk2
> edk2-non-osi
> edk2-platforms
> 
> that are references to the
> https://github.com/tianocore/ material.
> 
> edk2 has an updated "222 files" link which takes one to
> a page that shows the commit history ending at
> aa211bb .
> 
> edk2-non-osi has an updated "4 files" link which takes
> one to a page that shows the commit history ending at
> 4f88718 .
> 
> edk2-platforms has an updated "55 files" link which takes
> one to a page that shows the commit history ending at
> b2eebc1 .
> 
> These appear to be what to use to try to reproduce
> the V1.18 pftf RPi4 release based on
> https://github.com/tianocore/ materials.
> 
> 
> 
> Doing the same sort of thing for
> https://github.com/pftf/RPi3/releases/ there is a
> ab5895d listed for the most recent release (v1.29)
> that is a link to:
> 
> https://github.com/pftf/RPi3/commit/ab5895ddee99b0dd9030ec052fd67b838116c377
> 
> Again the 3 Submodules are listed on the page that
> takes one to:
> 
> edk2
> edk2-non-osi
> edk2-platforms
> 
> Looking at each shows that they match the RPi4 example:
> 
> edk2:   aa211bb
> edk2-non-osi:   4f88718
> edk2-platforms: b2eebc1
> 
> (This may be normal when they release the pair together.)
> 
> 
> Unfortunately, I'm not aware of anything for macchiatobin
> that is analogous to https://github.com/pftf/RPi3 and
> https://github.com/pftf/RPi4 off which to derive what
> source would reproduce some known release that might
> have been put to use with FreeBSD (a tested combination).
> 
> 
> Also I found nothing referencing:
> 
> openssl-openssl
> ucb-bar-berkeley-softfloat
> kkos-oniguruma
> google-brotli
> 
> but I've not checked if these are only used for the
> macchiatobin flavor vs. being more widely used.
> 
> 
> 
> It will be some time before I try to update from
> pftf RPi4 v1.17 to v1.18 via an adjusted sysutils/edk2
> built in poudriere. So I'm unsure if the above is
> sufficient or not.
> 
> (Note: pftf RPi4 v1.18 in part was a work around for
> a problematical start4.elf / fixup4.dat update,
> reverting to "a version published before 2020.07.14"
> for the .elf and .dat returned to things working.
> bd816db is what broke them and 46e2c3e included
> the fix to them. The same applies to RPI3's v1.29,
> but for start.elf and fixup.dat instead.)
> 
> 
> I have access to a MACCHITObin Double Shot --but it is
> based on using a personal uefi/acpi build that I was
> given access to. I've no clue how to reproduce it
> from what source. I've no clue what would be good to
> build for @macchiatobin use. (It need not match what
> is good for the RPi3 and RPi4 as far as I can tell,
> although such might work currently(?).)
> 

Looks like pftf/RPi4 gave up on getting edk2 to
follow the standard on something that have some
users dependent on older behavior later specified
to be incorrect behavior. (Backwards compatibility
won over forward standards conformance.) So there
is now (as part of v1.19):

QUOTE
• This firmware was built from the official EDK2 repository, with 
0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch applied to the 
edk2 submodule. If you need more information, please refer to that repository.
END QUOTE

https://github.com/pftf/RPi4/ has the patch listed.


v1.19 includes more than that.

But edk2-non-osi is as it was for v1.18 . That
points that that exploring a specific:

https://github.com/pftf/RPi4/commit/[OMITTED]

need not show all the relevant "what to use"
information for the 3 modules from:

https://github.com/tianocore/

I had not mentioned such issues previously.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: How to build sysutils/edk2@rpi4 (for example) that matches https://github.com/pftf/RPi4/releases/tag/v1.18 (for example)

2020-08-11 Thread Mark Millard via freebsd-ports
On 2020-Aug-11, at 00:46, Mark Murray  wrote:

>> On 11 Aug 2020, at 07:44, Mark Millard via freebsd-arm 
>>  wrote:
>> 
>> Unfortunately, I'm not aware of anything for macchiatobin
>> that is analogous to https://github.com/pftf/RPi3 and
>> https://github.com/pftf/RPi4 off which to derive what
>> source would reproduce some known release that might
>> have been put to use with FreeBSD (a tested combination).
> 
> I have a MacchiatoBin Double Shot doing dual duty as an ARM
> build box and firewall. It has a dual-port PCI NIC in it.
> 
> I may have the same edk2 build as you, and it works really well.
> 
> In an ideal world, I'd be using the native ethernet ports and I'd
> have a cheap video card in the PCI slot, but the serial console
> works well enough for now.

Nothing the this one's PCI slot.

Realtek USB 10/100/1000 LAN via using
https://reviews.freebsd.org/D25809 .

Serial console.

SATA SSD.

FYI:

Its -j4 buildworld buildkernel results are somewhat slower than
for an OverDrive 1000. (Similarly for poudriere bulk runs. Single
threaded activity is a different story.) Builds are CPU/memory
bound, not I/O bound, for both systems.


ENVIRONMENT: -mcpu=cortex-a57 OverDrive 1000 @1.7G Hz, 8 GiByte RAM total
 (2 DIMMs slots, both populated):

World built in 15508 seconds, ncpu: 4, make -j4
Kernel(s)  GENERIC-NODBG built in 1117 seconds, ncpu: 4, make -j4


ENVIRONMENT: -mcpu=cortex-a72 MACCHIATObin Double Shot @ 2G Hz, 16 GiByte RAM
 (1 DIMM slot):

World built in 18789 seconds, ncpu: 4, make -j4
Kernel(s)  GENERIC-NODBG built in 1296 seconds, ncpu: 4, make -j4


The only differences in my equivalents of src.conf are the 57's
vs. 72's in -mcpu= usage (same arch different tuning). head
-r363590 doing self-hosted, from-scratch rebuilds.

What contributes? L0-L2 cache size differences and dual DIMM
(dual channel? interleaving?) vs. single DIMM. Cache performance
for 4 active threads keeps the two systems similarly performant
for problems that fit in both sizes of RAM cache. But the
OverDrive looks to have 4 times the RAM cache. That matters for
-j4 buildworld buildkernel .

[The .png (that will not make it to the list) is a graph
of benchmark data from my C++17 variant of some old HINT
benchmarks. Data types: d=double, ull=unsigned long long,
ul=unsigned long, ui=unsigned int. In this context,
variations in ull vs. ul results for a given system give
a clue as to the degree of other sources of variability:
both are 64-bit unsigned here. Y-axis: larger is faster.
While gcc10 was used, the system libc++ and such were
used instead of gcc's libraries.]


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


How to build sysutils/edk2@rpi4 (for example) that matches https://github.com/pftf/RPi4/releases/tag/v1.18 (for example)

2020-08-11 Thread Mark Millard via freebsd-ports
I noticed the sysutils/edk2 addition. So I've tried to figure
out how to use it to reproduce the pftf RPi4 V1.18 release
(as an example), by, say, adjusting the distinfo file to pick
up the matching source.

Looking at https://github.com/pftf/RPi4/releases/
there is a 4dd0f24 listed for the most recent release
(v1.18) that is a link to:

https://github.com/pftf/RPi4/commit/4dd0f24d03cf73ed8e7bd29f88d8e86779410e69

That in turn lists the release's changes for Submodules:

edk2
edk2-non-osi
edk2-platforms

that are references to the
https://github.com/tianocore/ material.

edk2 has an updated "222 files" link which takes one to
a page that shows the commit history ending at
aa211bb .

edk2-non-osi has an updated "4 files" link which takes
one to a page that shows the commit history ending at
4f88718 .

edk2-platforms has an updated "55 files" link which takes
one to a page that shows the commit history ending at
b2eebc1 .

These appear to be what to use to try to reproduce
the V1.18 pftf RPi4 release based on
https://github.com/tianocore/ materials.



Doing the same sort of thing for
https://github.com/pftf/RPi3/releases/ there is a
ab5895d listed for the most recent release (v1.29)
that is a link to:

https://github.com/pftf/RPi3/commit/ab5895ddee99b0dd9030ec052fd67b838116c377

Again the 3 Submodules are listed on the page that
takes one to:

edk2
edk2-non-osi
edk2-platforms

Looking at each shows that they match the RPi4 example:

edk2:   aa211bb
edk2-non-osi:   4f88718
edk2-platforms: b2eebc1

(This may be normal when they release the pair together.)


Unfortunately, I'm not aware of anything for macchiatobin
that is analogous to https://github.com/pftf/RPi3 and
https://github.com/pftf/RPi4 off which to derive what
source would reproduce some known release that might
have been put to use with FreeBSD (a tested combination).


Also I found nothing referencing:

openssl-openssl
ucb-bar-berkeley-softfloat
kkos-oniguruma
google-brotli

but I've not checked if these are only used for the
macchiatobin flavor vs. being more widely used.



It will be some time before I try to update from
pftf RPi4 v1.17 to v1.18 via an adjusted sysutils/edk2
built in poudriere. So I'm unsure if the above is
sufficient or not.

(Note: pftf RPi4 v1.18 in part was a work around for
a problematical start4.elf / fixup4.dat update,
reverting to "a version published before 2020.07.14"
for the .elf and .dat returned to things working.
bd816db is what broke them and 46e2c3e included
the fix to them. The same applies to RPI3's v1.29,
but for start.elf and fixup.dat instead.)


I have access to a MACCHITObin Double Shot --but it is
based on using a personal uefi/acpi build that I was
given access to. I've no clue how to reproduce it
from what source. I've no clue what would be good to
build for @macchiatobin use. (It need not match what
is good for the RPi3 and RPi4 as far as I can tell,
although such might work currently(?).)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: security/nss build failure under poudriere, "symlink creation race", head -r363590 FreeBSD and head -r543636 ports

2020-07-31 Thread Mark Millard via freebsd-ports



On 2020-Jul-30, at 23:11, Tatsuki Makino  wrote:
> 
> Hmmm, I was using 2 builders by -J 2:4. But I don't remember if there
> were other jobs available when nss was building :)
> How is your poudriere set up for NO_ZFS? I'm using it with NO_ZFS=yes.

I do not have any media with ZFS in use in any of the systems that
I have access to. I instead use UFS in all of them. So I use
NO_ZFS=yes .

> And BASEFS exists within UFS.

For my context that got the problem, there is
only UFS [ignoring the efi partition contents
and the swap partitions].


Other choices in my poudriere configuration on the
cortexA57 system that are different than in
/usr/local/etc/poudriere.conf.sample :

USE_TMPFS=no
SAVE_WRKDIR=yes
WRKDIR_ARCHIVE_FORMAT=tar
ALLOW_MAKE_JOBS=yes
ALLOW_MAKE_JOBS_PACKAGES="pkg ccache py* gcc* llvm* ghc* *webkit* *office* 
chromium* iridium* mongodb*"
NOHANG_TIME=14400
BUILD_AS_NON_ROOT=no

(ALLOW_MAKE_JOBS_PACKAGES is just in case I temporarily
disable ALLOW_MAKE_JOBS for some reason.)

> I'm suspicious of gmake and UFS on this issue. But I don't know the
> details of that :)

I've no clue what to blaim for the race, other than the
retry logic that will never retry. (I do not claim to
know that such a retry would be appropriate.)


I forced poudriere to rebuild the same set of ports to
try the "large load average" context again. nss built
fine. (llvm10 and llvm11 are still building.)

Even trying to establish if MAKE_JOBS_UNSAFE use made
a difference would be problematical: failure is rare
without MAKE_JOBS_UNSAFE in my context.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: security/nss build failure under poudriere, "symlink creation race", head -r363590 FreeBSD and head -r543636 ports

2020-07-30 Thread Mark Millard via freebsd-ports


On 2020-Jul-29, at 23:34, Tatsuki Makino  wrote:

> Hello.
> 
> The same thing happened to me.
> If you want the build to succeed, I think enabling DISABLE_MAKE_JOBS
> will solve the problem.

Running bulk again had no troubles, no use of MAKE_JOBS_UNSAFE
involved.

However, I use poudriere with ALLOW_MAKE_JOBS=yes and do not
restrict PARALLEL_JOBS. The first run had 4 builders running
(one per core), each allowed 4 active processes. The 2nd run
had only one builder active while building nss simply because
everything not dependent on nss had been built already.

The 4-builders, each allowed 4 active processes, apparently
makes it more likely to fail the race condition.

> Here's an excerpt from a log of my failures for the same reason.
> 
> 
> =>> Building security/nss
> build started at Tue Jun 30 01:18:43 UTC 2020
> port directory: /usr/ports/security/nss
> package name: nss-3.54
> building for: FreeBSD src-default-job-02 12.1-STABLE FreeBSD 12.1-STABLE
> 1201518 amd64
>    ︙
> Poudriere version: 3.3.4
> Host OSVERSION: 1201518
> Jail OSVERSION: 1201518
>    ︙
> ../../coreconf/nsinstall/FreeBSD12.1_OPT.OBJ/nsinstall -R -m 444 smime.h
> ../../../dist/public/nss
> ../../coreconf/nsinstall/FreeBSD12.1_OPT.OBJ/nsinstall -R -m 444
> nssckfw.h ../../../dist/public/nss
> ../../coreconf/nsinstall/FreeBSD12.1_OPT.OBJ/nsinstall -R -m 444
> nssckfw.h ../../../dist/public/nss
> ../../coreconf/nsinstall/FreeBSD12.1_OPT.OBJ/nsinstall -R -m 444
> cmsreclist.h ../../../dist/public/nss
> symlink creation race:
> /wrkdirs/usr/ports/security/nss/work/nss-3.54/dist/public/nss/nssckfw.h
> nsinstall: symlink was attempted in working directory
> /wrkdirs/usr/ports/security/nss/work/nss-3.54/nss/lib/ckfw from
> ../../../nss/lib/ckfw/nssckfw.h to /wrkdirs/usr/ports/security/nss/work>
> ../../coreconf/nsinstall/FreeBSD12.1_OPT.OBJ/nsinstall -R -m 444
> nssckfwc.h ../../../dist/public/nss
> : File exists
> ../../coreconf/nsinstall/FreeBSD12.1_OPT.OBJ/nsinstall -R -m 444
> nssckfwt.h ../../../dist/public/nss
> ../../coreconf/nsinstall/FreeBSD12.1_OPT.OBJ/nsinstall -R -m 444
> nssckfwc.h ../../../dist/public/nss
> gmake[4]: Leaving directory
> '/wrkdirs/usr/ports/security/nss/work/nss-3.54/nss/lib/smime'
>    ︙
> gmake[5]: *** [../../coreconf/rules.mk:387:
> ../../../dist/public/nss/nssckfw.h] Abort trap (core dumped)
> gmake[5]: *** Deleting file '../../../dist/public/nss/nssckfw.h'
> gmake[5]: Leaving directory
> '/wrkdirs/usr/ports/security/nss/work/nss-3.54/nss/lib/ckfw'
> gmake[4]: *** [../../coreconf/rules.mk:44: .] Error 2
> gmake[4]: Leaving directory
> '/wrkdirs/usr/ports/security/nss/work/nss-3.54/nss/lib/ckfw'
> gmake[3]: *** [../coreconf/rules.mk:44: ckfw] Error 2
> gmake[3]: Leaving directory
> '/wrkdirs/usr/ports/security/nss/work/nss-3.54/nss/lib'
> gmake[2]: *** [coreconf/rules.mk:44: lib] Error 2
> gmake[2]: Leaving directory
> '/wrkdirs/usr/ports/security/nss/work/nss-3.54/nss'
> gmake[1]: *** [manifest.mn:25: prepare_build] Error 2
> gmake[1]: Leaving directory
> '/wrkdirs/usr/ports/security/nss/work/nss-3.54/nss'
> ===> 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/security/nss
> 
> 
> I don't know why it's trying to run the command twice against nssckfw.h.
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


security/nss build failure under poudriere, "symlink creation race", head -r363590 FreeBSD and head -r543636 ports

2020-07-29 Thread Mark Millard via freebsd-ports
While building ports for a cortexA53 (aarch64) on a cortexA57
system via poudriere-devel use I got:

gmake[5]: Leaving directory 
'/wrkdirs/usr/ports/security/nss/work/nss-3.55/nss/lib/ckfw/builtins'
gmake[4]: *** [../../coreconf/rules.mk:387: 
../../../dist/public/nss/nssckmdt.h] Abort trap (core dumped)
gmake[4]: *** Deleting file '../../../dist/public/nss/nssckmdt.h'

gdb reports that:

Core was generated by `../../coreconf/nsinstall/FreeBSD13.0_OPT.OBJ/nsinstall 
-R -m 444 nssckmdt.h ../.'

(gdb) bt
#0  thr_kill () at thr_kill.S:4
#1  0x404adc70 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x40428a74 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3  0x00212a50 in fail (format=) at pathsub.c:53
#4  0x00212438 in main (argc=, argv=) at 
nsinstall.c:330

(gdb) up 4
#4  0x00212438 in main (argc=, argv=) at 
nsinstall.c:330
330 fail("symlink was attempted in working directory %s 
"
(gdb) list
325 exists = 0;
326 }
327 if (!exists && symlink(name, toname) < 0) {
328 if (errno == EEXIST) {
329 fprintf(stderr, "symlink creation race: %s\n", 
toname);
330 fail("symlink was attempted in working directory %s 
"
331  "from %s to %s.\n", cwd, name, toname);
332 goto retry;
333 }
334 diagnosePath(toname);

(gdb) print cwd
$1 = 0x40a18000 "/wrkdirs/usr/ports/security/nss/work/nss-3.55/nss/lib/ckfw"
(gdb) print name
$2 = 0x40a18800 "../../../nss/lib/ckfw/nssckmdt.h"
(gdb) print toname
$3 = 0x40a1b000 
"/wrkdirs/usr/ports/security/nss/work/nss-3.55/dist/public/nss/nssckmdt.h"

More specifically the code (with more context) is:

retry:
exists = (lstat(toname, ) == 0);
. . .
/* Check for a pre-existing symlink with identical content. */
if (exists &&
(!S_ISLNK(tosb.st_mode) ||
 readlink(toname, buf, sizeof buf) != len ||
 strncmp(buf, name, len) != 0)) {
int rmrv;
rmrv = (S_ISDIR(tosb.st_mode) ? rmdir : unlink)(toname);
if (rmrv < 0) {
fail("destination exists, cannot remove %s", toname);
}
exists = 0;
}
if (!exists && symlink(name, toname) < 0) {
if (errno == EEXIST) {
fprintf(stderr, "symlink creation race: %s\n", toname);
fail("symlink was attempted in working directory %s "
 "from %s to %s.\n", cwd, name, toname);
goto retry;
}
diagnosePath(toname);
fail("cannot make symbolic link %s", toname);
}
. . .

The "goto retry" is odd given the "fail" use and:

void
fail(char *format, ...)
{
. . .
abort();
exit(1);
}



The poudriere bulk is still going, building other things.
So it will be some time before I find out if this repeats
for the next bulk run.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)

2020-07-23 Thread Mark Millard via freebsd-ports



On 2020-Jul-23, at 09:25, Mark Millard  wrote:


> 
> On 2020-Jul-22, at 21:02, Mark Millard  wrote:
> 
>> On 2020-Jul-22, at 17:16, Mark Millard  wrote:
>> 
>>> On 2020-Jul-22, at 14:11, Jan Beich  wrote:
>>> 
 Mark Millard via freebsd-ppc  writes:
 
> ../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function 
> '__sync_add_and_fetch_8'
> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
> ^
> ../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin 
> with type 'long long (volatile long long *, long long, ...)'
> ../src/util/u_atomic.c:38:1: error: definition of builtin function 
> '__sync_add_and_fetch_8'
> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
> ^
> ../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function 
> '__sync_sub_and_fetch_8'
> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
> ^
> ../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin 
> with type 'long long (volatile long long *, long long, ...)'
> ../src/util/u_atomic.c:51:1: error: definition of builtin function 
> '__sync_sub_and_fetch_8'
> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
> ^
> ../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function 
> '__sync_val_compare_and_swap_8'
> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
> newval)
> ^
> ../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a 
> builtin with type 'long long (volatile long long *, long long, long long, 
> ...)'
> ../src/util/u_atomic.c:64:1: error: definition of builtin function 
> '__sync_val_compare_and_swap_8'
> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
> newval)
> ^
> 6 errors generated.
 
 Try replacing files/patch-i386 with 
 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464
 On i386 (clang) one can sometimes avoid -latomic by bumping -march
 (FreeBSD 11.4/12.2/13.0 defaults to i686) but powerpc (gcc) probably
 can't use __sync* with 64-bit types without -latomic, making Meson
 define MISSING_64BIT_ATOMICS to use src/util/u_atomic.c
>>> 
>>> The context was head (so system-clang instead of
>>> gcc 4.2.1). But, looking in the logs, it seems to
>>> have used an odd mix of system-clang and devel/lvm80
>>> materials:
>>> 
>>> . . .
>>> Project name: mesa
>>> Project version: 19.0.8
>>> Using 'CC' from environment with value: 'cc'
>>> Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
>>> -fstack-protector-strong -fno-strict-aliasing '
>>> Using 'LDFLAGS' from environment with value: ' 
>>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>>> Using 'CPPFLAGS' from environment with value: ''
>>> Using 'CXX' from environment with value: 'c++'
>>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
>>> -fstack-protector-strong -fno-strict-aliasing  '
>>> Using 'LDFLAGS' from environment with value: ' 
>>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>>> Using 'CPPFLAGS' from environment with value: ''
>>> Using 'CC' from environment with value: 'cc'
>>> Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
>>> -fstack-protector-strong -fno-strict-aliasing '
>>> Using 'LDFLAGS' from environment with value: ' 
>>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>>> Using 'CPPFLAGS' from environment with value: ''
>>> C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang version 
>>> 10.0.1 (g...@github.com:llvm/llvm-project.git 
>>> llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
>>> C linker for the host machine: cc ld.lld 10.0.1
>>> Using 'CXX' from environment with value: 'c++'
>>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
>>> -fstack-protector-strong -fno-strict-aliasing  '
>>> Using 'LDFLAGS' from environment with value: ' 
>>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>>> Using 'CPPFLAGS' from environment with value: ''
>>> C++ compiler for the host machine: c++ (clang 10.0.1 "FreeBSD clang version 
>>> 10.0.1 (g...@github.com:llvm/llvm-project.git 
>>> llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
>>> C++ linker for the host machine: c++ ld.lld 10.0.1
>>> Host machine cpu family: ppc
>>> Host machine cpu: powerpc
>>> . . .
>>> llvm-config found: YES (/usr/local/bin/llvm-config80) 8.0.1
>>> Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, bitwriter, 
>>> engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.1
>>> . . .
>>> cc . . . -DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 . . . -c 
>>> ../src/util/u_atomic.c
>>> . . .
>>> 
>>> 
>>> The system-clang devel/llvm80 mix seems to be at
>>> least declaring __sync_add_and_fetch_8 ,
>>> __sync_sub_and_fetch_8 , and
>>> __sync_val_compare_and_swap_8 as builtin,
>>> possibly implicitly.
>>> 
>>> At this point I'm unclear if:
>>> 
>>> 

Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)

2020-07-23 Thread Mark Millard via freebsd-ports



On 2020-Jul-22, at 21:02, Mark Millard  wrote:

> On 2020-Jul-22, at 17:16, Mark Millard  wrote:
> 
>> On 2020-Jul-22, at 14:11, Jan Beich  wrote:
>> 
>>> Mark Millard via freebsd-ppc  writes:
>>> 
 ../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function 
 '__sync_add_and_fetch_8'
 __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
 ^
 ../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin 
 with type 'long long (volatile long long *, long long, ...)'
 ../src/util/u_atomic.c:38:1: error: definition of builtin function 
 '__sync_add_and_fetch_8'
 __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
 ^
 ../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function 
 '__sync_sub_and_fetch_8'
 __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
 ^
 ../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin 
 with type 'long long (volatile long long *, long long, ...)'
 ../src/util/u_atomic.c:51:1: error: definition of builtin function 
 '__sync_sub_and_fetch_8'
 __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
 ^
 ../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function 
 '__sync_val_compare_and_swap_8'
 __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
 newval)
 ^
 ../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a 
 builtin with type 'long long (volatile long long *, long long, long long, 
 ...)'
 ../src/util/u_atomic.c:64:1: error: definition of builtin function 
 '__sync_val_compare_and_swap_8'
 __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
 newval)
 ^
 6 errors generated.
>>> 
>>> Try replacing files/patch-i386 with 
>>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464
>>> On i386 (clang) one can sometimes avoid -latomic by bumping -march
>>> (FreeBSD 11.4/12.2/13.0 defaults to i686) but powerpc (gcc) probably
>>> can't use __sync* with 64-bit types without -latomic, making Meson
>>> define MISSING_64BIT_ATOMICS to use src/util/u_atomic.c
>> 
>> The context was head (so system-clang instead of
>> gcc 4.2.1). But, looking in the logs, it seems to
>> have used an odd mix of system-clang and devel/lvm80
>> materials:
>> 
>> . . .
>> Project name: mesa
>> Project version: 19.0.8
>> Using 'CC' from environment with value: 'cc'
>> Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
>> -fstack-protector-strong -fno-strict-aliasing '
>> Using 'LDFLAGS' from environment with value: ' 
>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>> Using 'CPPFLAGS' from environment with value: ''
>> Using 'CXX' from environment with value: 'c++'
>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
>> -fstack-protector-strong -fno-strict-aliasing  '
>> Using 'LDFLAGS' from environment with value: ' 
>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>> Using 'CPPFLAGS' from environment with value: ''
>> Using 'CC' from environment with value: 'cc'
>> Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
>> -fstack-protector-strong -fno-strict-aliasing '
>> Using 'LDFLAGS' from environment with value: ' 
>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>> Using 'CPPFLAGS' from environment with value: ''
>> C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang version 
>> 10.0.1 (g...@github.com:llvm/llvm-project.git 
>> llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
>> C linker for the host machine: cc ld.lld 10.0.1
>> Using 'CXX' from environment with value: 'c++'
>> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
>> -fstack-protector-strong -fno-strict-aliasing  '
>> Using 'LDFLAGS' from environment with value: ' 
>> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
>> Using 'CPPFLAGS' from environment with value: ''
>> C++ compiler for the host machine: c++ (clang 10.0.1 "FreeBSD clang version 
>> 10.0.1 (g...@github.com:llvm/llvm-project.git 
>> llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
>> C++ linker for the host machine: c++ ld.lld 10.0.1
>> Host machine cpu family: ppc
>> Host machine cpu: powerpc
>> . . .
>> llvm-config found: YES (/usr/local/bin/llvm-config80) 8.0.1
>> Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, bitwriter, 
>> engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.1
>> . . .
>> cc . . . -DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 . . . -c 
>> ../src/util/u_atomic.c
>> . . .
>> 
>> 
>> The system-clang devel/llvm80 mix seems to be at
>> least declaring __sync_add_and_fetch_8 ,
>> __sync_sub_and_fetch_8 , and
>> __sync_val_compare_and_swap_8 as builtin,
>> possibly implicitly.
>> 
>> At this point I'm unclear if:
>> 
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464
>> 
>> is relevant. The system-clang and devel/llvm80 mix
>> just does not seem the right kind of thing to be
>> doing in the 

Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)

2020-07-22 Thread Mark Millard via freebsd-ports
On 2020-Jul-22, at 17:16, Mark Millard  wrote:

> On 2020-Jul-22, at 14:11, Jan Beich  wrote:
> 
>> Mark Millard via freebsd-ppc  writes:
>> 
>>> ../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function 
>>> '__sync_add_and_fetch_8'
>>> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
>>> ^
>>> ../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin 
>>> with type 'long long (volatile long long *, long long, ...)'
>>> ../src/util/u_atomic.c:38:1: error: definition of builtin function 
>>> '__sync_add_and_fetch_8'
>>> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
>>> ^
>>> ../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function 
>>> '__sync_sub_and_fetch_8'
>>> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
>>> ^
>>> ../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin 
>>> with type 'long long (volatile long long *, long long, ...)'
>>> ../src/util/u_atomic.c:51:1: error: definition of builtin function 
>>> '__sync_sub_and_fetch_8'
>>> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
>>> ^
>>> ../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function 
>>> '__sync_val_compare_and_swap_8'
>>> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
>>> newval)
>>> ^
>>> ../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a 
>>> builtin with type 'long long (volatile long long *, long long, long long, 
>>> ...)'
>>> ../src/util/u_atomic.c:64:1: error: definition of builtin function 
>>> '__sync_val_compare_and_swap_8'
>>> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
>>> newval)
>>> ^
>>> 6 errors generated.
>> 
>> Try replacing files/patch-i386 with 
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464
>> On i386 (clang) one can sometimes avoid -latomic by bumping -march
>> (FreeBSD 11.4/12.2/13.0 defaults to i686) but powerpc (gcc) probably
>> can't use __sync* with 64-bit types without -latomic, making Meson
>> define MISSING_64BIT_ATOMICS to use src/util/u_atomic.c
> 
> The context was head (so system-clang instead of
> gcc 4.2.1). But, looking in the logs, it seems to
> have used an odd mix of system-clang and devel/lvm80
> materials:
> 
> . . .
> Project name: mesa
> Project version: 19.0.8
> Using 'CC' from environment with value: 'cc'
> Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
> -fstack-protector-strong -fno-strict-aliasing '
> Using 'LDFLAGS' from environment with value: ' 
> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
> Using 'CPPFLAGS' from environment with value: ''
> Using 'CXX' from environment with value: 'c++'
> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
> -fstack-protector-strong -fno-strict-aliasing  '
> Using 'LDFLAGS' from environment with value: ' 
> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
> Using 'CPPFLAGS' from environment with value: ''
> Using 'CC' from environment with value: 'cc'
> Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
> -fstack-protector-strong -fno-strict-aliasing '
> Using 'LDFLAGS' from environment with value: ' 
> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
> Using 'CPPFLAGS' from environment with value: ''
> C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang version 
> 10.0.1 (g...@github.com:llvm/llvm-project.git 
> llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
> C linker for the host machine: cc ld.lld 10.0.1
> Using 'CXX' from environment with value: 'c++'
> Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
> -fstack-protector-strong -fno-strict-aliasing  '
> Using 'LDFLAGS' from environment with value: ' 
> -Wl,-rpath=/usr/local/llvm80/lib -fstack-protector-strong '
> Using 'CPPFLAGS' from environment with value: ''
> C++ compiler for the host machine: c++ (clang 10.0.1 "FreeBSD clang version 
> 10.0.1 (g...@github.com:llvm/llvm-project.git 
> llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
> C++ linker for the host machine: c++ ld.lld 10.0.1
> Host machine cpu family: ppc
> Host machine cpu: powerpc
> . . .
> llvm-config found: YES (/usr/local/bin/llvm-config80) 8.0.1
> Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, bitwriter, 
> engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.1
> . . .
> cc . . . -DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 . . . -c 
> ../src/util/u_atomic.c
> . . .
> 
> 
> The system-clang devel/llvm80 mix seems to be at
> least declaring __sync_add_and_fetch_8 ,
> __sync_sub_and_fetch_8 , and
> __sync_val_compare_and_swap_8 as builtin,
> possibly implicitly.
> 
> At this point I'm unclear if:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464
> 
> is relevant. The system-clang and devel/llvm80 mix
> just does not seem the right kind of thing to be
> doing in the build.
> 

I'm not sure how analogous gecko is but I'll note
that /usr/ports/Mk/bsd.gecko.mk has the related
and additional logic:

BUILD_DEPENDS+= 

Re: 32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)

2020-07-22 Thread Mark Millard via freebsd-ports



On 2020-Jul-22, at 14:11, Jan Beich  wrote:

> Mark Millard via freebsd-ppc  writes:
> 
>> ../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function 
>> '__sync_add_and_fetch_8'
>> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
>> ^
>> ../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin 
>> with type 'long long (volatile long long *, long long, ...)'
>> ../src/util/u_atomic.c:38:1: error: definition of builtin function 
>> '__sync_add_and_fetch_8'
>> __sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
>> ^
>> ../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function 
>> '__sync_sub_and_fetch_8'
>> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
>> ^
>> ../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin 
>> with type 'long long (volatile long long *, long long, ...)'
>> ../src/util/u_atomic.c:51:1: error: definition of builtin function 
>> '__sync_sub_and_fetch_8'
>> __sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
>> ^
>> ../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function 
>> '__sync_val_compare_and_swap_8'
>> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
>> newval)
>> ^
>> ../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a 
>> builtin with type 'long long (volatile long long *, long long, long long, 
>> ...)'
>> ../src/util/u_atomic.c:64:1: error: definition of builtin function 
>> '__sync_val_compare_and_swap_8'
>> __sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t 
>> newval)
>> ^
>> 6 errors generated.
> 
> Try replacing files/patch-i386 with 
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464
> On i386 (clang) one can sometimes avoid -latomic by bumping -march
> (FreeBSD 11.4/12.2/13.0 defaults to i686) but powerpc (gcc) probably
> can't use __sync* with 64-bit types without -latomic, making Meson
> define MISSING_64BIT_ATOMICS to use src/util/u_atomic.c

The context was head (so system-clang instead of
gcc 4.2.1). But, looking in the logs, it seems to
have used an odd mix of system-clang and devel/lvm80
materials:

. . .
Project name: mesa
Project version: 19.0.8
Using 'CC' from environment with value: 'cc'
Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
-fstack-protector-strong -fno-strict-aliasing '
Using 'LDFLAGS' from environment with value: ' -Wl,-rpath=/usr/local/llvm80/lib 
-fstack-protector-strong '
Using 'CPPFLAGS' from environment with value: ''
Using 'CXX' from environment with value: 'c++'
Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
-fstack-protector-strong -fno-strict-aliasing  '
Using 'LDFLAGS' from environment with value: ' -Wl,-rpath=/usr/local/llvm80/lib 
-fstack-protector-strong '
Using 'CPPFLAGS' from environment with value: ''
Using 'CC' from environment with value: 'cc'
Using 'CFLAGS' from environment with value: '-O2 -pipe  -g 
-fstack-protector-strong -fno-strict-aliasing '
Using 'LDFLAGS' from environment with value: ' -Wl,-rpath=/usr/local/llvm80/lib 
-fstack-protector-strong '
Using 'CPPFLAGS' from environment with value: ''
C compiler for the host machine: cc (clang 10.0.1 "FreeBSD clang version 10.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
C linker for the host machine: cc ld.lld 10.0.1
Using 'CXX' from environment with value: 'c++'
Using 'CXXFLAGS' from environment with value: '-O2 -pipe -g 
-fstack-protector-strong -fno-strict-aliasing  '
Using 'LDFLAGS' from environment with value: ' -Wl,-rpath=/usr/local/llvm80/lib 
-fstack-protector-strong '
Using 'CPPFLAGS' from environment with value: ''
C++ compiler for the host machine: c++ (clang 10.0.1 "FreeBSD clang version 
10.0.1 (g...@github.com:llvm/llvm-project.git 
llvmorg-10.0.1-rc2-0-g77d76b71d7d)")
C++ linker for the host machine: c++ ld.lld 10.0.1
Host machine cpu family: ppc
Host machine cpu: powerpc
. . .
llvm-config found: YES (/usr/local/bin/llvm-config80) 8.0.1
Run-time dependency LLVM (modules: amdgpu, asmparser, bitreader, bitwriter, 
engine, ipo, mcdisassembler, mcjit, native) found: YES 8.0.1
. . .
cc . . . -DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 . . . -c 
../src/util/u_atomic.c
. . .


The system-clang devel/llvm80 mix seems to be at
least declaring __sync_add_and_fetch_8 ,
__sync_sub_and_fetch_8 , and
__sync_val_compare_and_swap_8 as builtin,
possibly implicitly.

At this point I'm unclear if:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5464

is relevant. The system-clang and devel/llvm80 mix
just does not seem the right kind of thing to be
doing in the build.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Why lang/gcc9 depends native-binutils ?

2020-07-22 Thread Mark Millard via freebsd-ports
On 2020-Jul-22, at 01:03, Mark Millard  wrote:

> On 2020-Jul-22, at 00:23, KIRIYAMA Kazuhiko  wrote:
> 
>> Hi, Mark
>> 
>> On Tue, 21 Jul 2020 17:51:41 +0900,
>> Mark Millard via freebsd-ports wrote:
>>> 
>>> KIRIYAMA Kazuhiko kiri at truefc.org wrote on
>>> Tue Jul 21 02:33:25 UTC 2020 :
>>> 
>>>> checking for iconv declaration... 
>>>>extern size_t iconv (iconv_t cd, char * *inbuf, size_t 
>>>> *inbytesleft, char * *outbuf, size_t *outbytesleft);
>>>> *** BFD does not support target native-unknown-freebsd13.0.
>>>> *** Look in bfd/config.bfd for supported targets.
>>>> gmake[3]: *** [Makefile:3563: configure-binutils] Error 1
>>>> gmake[3]: Leaving directory 
>>>> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
>>>> gmake[2]: *** [Makefile:851: all] Error 2
>>>> gmake[2]: Leaving directory 
>>>> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
>>>> ===> Compilation failed unexpectedly.
>>>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
>>>> the maintainer.
>>>> *** Error code 1
>>> 
>>> lang/gcc9/Makefile references binutils via:
>>> 
>>> BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils
>>> RUN_DEPENDS+=   ${LOCALBASE}/bin/as:devel/binutils
>>> . . .
>>> USE_BINUTILS=   yes
>>> 
>>> The BUILD_DEPENDS and RUN_DEPENDS references to
>>> binutils are to the assembler that binutils
>>> generates and installs. So gcc9 needs to be able
>>> to use that assembler at both gcc9 build-time and
>>> gcc9 run-time.
>>> 
>>> The notation leaves the FLAVOR implicit/empty and
>>> so should lead to devel/binutils/Makefile using
>>> its line:
>>> 
>>> FLAVOR?=native
>>> 
>>> to assign the "native" for its own internal logic
>>> to use.
>>> 
>>> 
>>> 
>>> Hmm. The "target native-unknown-freebsd13.0" looks
>>> very odd to me. The only lines in the devel/binutils
>>> Makefile to deal with "unknown-" text directly are:
>>> 
>>> # grep -r unknown- /usr/ports/devel/binutils/
>>> /usr/ports/devel/binutils/Makefile:BUTARGET?=   
>>> ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
>>> /usr/ports/devel/binutils/Makefile:BUTARGET=
>>> x86_64-unknown-${OPSYS:tl}${OSREL}
>>> 
>>> (I'll later deal with an indirection where "_" is
>>> replaced by "-".)
>>> 
>>> Only the 1st line of that pair would potentially form
>>> "native-unknown-" text.
>>> 
>>> So looking at the context of the first line I find
>>> (". . ." for omitted lines):
>>> 
>>> FLAVOR?=native
>>> . . .
>>> .if ${FLAVOR} != native
>>> PKGNAMEPREFIX=  ${FLAVOR:C/_/-/g}-
>>> PLIST=  ${PKGDIR}/pkg-plist-${FLAVOR:C/_/-/g}
>>> 
>>> .if ${PKGNAMEPREFIX:M*-*-}
>>> BUTARGET?=  ${PKGNAMEPREFIX}${OPSYS:tl}${OSREL}
>>> .else
>>> BUTARGET?=  ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
>>> .endif
>>> 
>>> . . .
>>> 
>>> CONFIGURE_ARGS+=--disable-shared \
>>>   --target=${BUTARGET}
>>> .endif
>>> 
>>> 
>>> (That is also the only instance of "--target=" in the
>>> Makefile.)
>>> 
>>> The ${FLAVOR} != native test should mean that the code
>>> is not used for FLAVOR being exactly "native".
>>> 
>>> There is a separate code block for:
>>> 
>>> .if ${FLAVOR} == native
>>> BUREMOVE=   coffdump \
>>>   dlltool \
>>>   dllwrap \
>>>   nlmconv \
>>>   srconv \
>>>   sysdump \
>>>   windmc \
>>>   windres
>>> USES+=  localbase
>>> CONFIGURE_ARGS+=--with-system-zlib \
>>>   --with-gmp=${LOCALBASE} \
>>>   --with-mpfr=${LOCALBASE} \
>>>   --enable-targets=all \
>>>   --enable-threads=yes
>>> INFO=   as \
>>>   binutils \
>>>   gprof \
>>>   bfd \
>>>   ld
>>> .endi

Re: Why lang/gcc9 depends native-binutils ?

2020-07-22 Thread Mark Millard via freebsd-ports



On 2020-Jul-22, at 00:23, KIRIYAMA Kazuhiko  wrote:

> Hi, Mark
> 
> On Tue, 21 Jul 2020 17:51:41 +0900,
> Mark Millard via freebsd-ports wrote:
>> 
>> KIRIYAMA Kazuhiko kiri at truefc.org wrote on
>> Tue Jul 21 02:33:25 UTC 2020 :
>> 
>>> checking for iconv declaration... 
>>> extern size_t iconv (iconv_t cd, char * *inbuf, size_t 
>>> *inbytesleft, char * *outbuf, size_t *outbytesleft);
>>> *** BFD does not support target native-unknown-freebsd13.0.
>>> *** Look in bfd/config.bfd for supported targets.
>>> gmake[3]: *** [Makefile:3563: configure-binutils] Error 1
>>> gmake[3]: Leaving directory 
>>> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
>>> gmake[2]: *** [Makefile:851: all] Error 2
>>> gmake[2]: Leaving directory 
>>> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
>>> ===> Compilation failed unexpectedly.
>>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
>>> the maintainer.
>>> *** Error code 1
>> 
>> lang/gcc9/Makefile references binutils via:
>> 
>> BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils
>> RUN_DEPENDS+=   ${LOCALBASE}/bin/as:devel/binutils
>> . . .
>> USE_BINUTILS=   yes
>> 
>> The BUILD_DEPENDS and RUN_DEPENDS references to
>> binutils are to the assembler that binutils
>> generates and installs. So gcc9 needs to be able
>> to use that assembler at both gcc9 build-time and
>> gcc9 run-time.
>> 
>> The notation leaves the FLAVOR implicit/empty and
>> so should lead to devel/binutils/Makefile using
>> its line:
>> 
>> FLAVOR?=native
>> 
>> to assign the "native" for its own internal logic
>> to use.
>> 
>> 
>> 
>> Hmm. The "target native-unknown-freebsd13.0" looks
>> very odd to me. The only lines in the devel/binutils
>> Makefile to deal with "unknown-" text directly are:
>> 
>> # grep -r unknown- /usr/ports/devel/binutils/
>> /usr/ports/devel/binutils/Makefile:BUTARGET?=
>> ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
>> /usr/ports/devel/binutils/Makefile:BUTARGET= 
>> x86_64-unknown-${OPSYS:tl}${OSREL}
>> 
>> (I'll later deal with an indirection where "_" is
>> replaced by "-".)
>> 
>> Only the 1st line of that pair would potentially form
>> "native-unknown-" text.
>> 
>> So looking at the context of the first line I find
>> (". . ." for omitted lines):
>> 
>> FLAVOR?=native
>> . . .
>> .if ${FLAVOR} != native
>> PKGNAMEPREFIX=  ${FLAVOR:C/_/-/g}-
>> PLIST=  ${PKGDIR}/pkg-plist-${FLAVOR:C/_/-/g}
>> 
>> .if ${PKGNAMEPREFIX:M*-*-}
>> BUTARGET?=  ${PKGNAMEPREFIX}${OPSYS:tl}${OSREL}
>> .else
>> BUTARGET?=  ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
>> .endif
>> 
>> . . .
>> 
>> CONFIGURE_ARGS+=--disable-shared \
>>--target=${BUTARGET}
>> .endif
>> 
>> 
>> (That is also the only instance of "--target=" in the
>> Makefile.)
>> 
>> The ${FLAVOR} != native test should mean that the code
>> is not used for FLAVOR being exactly "native".
>> 
>> There is a separate code block for:
>> 
>> .if ${FLAVOR} == native
>> BUREMOVE=   coffdump \
>>dlltool \
>>dllwrap \
>>nlmconv \
>>srconv \
>>sysdump \
>>windmc \
>>windres
>> USES+=  localbase
>> CONFIGURE_ARGS+=--with-system-zlib \
>>--with-gmp=${LOCALBASE} \
>>--with-mpfr=${LOCALBASE} \
>>--enable-targets=all \
>>--enable-threads=yes
>> INFO=   as \
>>binutils \
>>gprof \
>>bfd \
>>ld
>> .endif
>> 
>> But that code does not specify a specific target
>> (instead: "--enable-targets=all").
>> 
>> There is the FLAVOR value "riscv32_unknown_elf" that
>> could produce target "riscv32-unknown-elf-freebsd13.0"
>> but that is not what was reported as involved.
>> 
>> I've ignored CROSS_TOOLCHAIN infrastructure as
>> it was not mentioned as being in use.
>> 
>> I do not see how devel/binutils/Makefi

32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)

2020-07-21 Thread Mark Millard via freebsd-ports
The error report material was:

cc -Isrc/util/ed6d25d@@mesa_util@sta -Isrc/util -I../src/util -Iinclude 
-I../include -Isrc -I../src -Isrc/mapi -I../src/mapi -Isrc/mesa -I../src/mesa 
-I../src/gallium/include -Isrc/gallium/auxiliary -
I../src/gallium/auxiliary -Xclang -fcolor-diagnostics -pipe 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -g -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERS
ION="19.0.8"' 
'-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa;' 
-DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM 
-DGLX_INDIRECT_RENDERING -DGLX_DI
RECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DHAVE_SURFACELESS_PLATFORM 
-DDEBUG -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL
 -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS 
-DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL 
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
 -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC 
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED 
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK 
-DHAVE_FUNC_ATTR
IBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL 
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS 
-DHAVE_FUNC_ATTRIBUTE_NORETURN -D_GNU_SOURCE -DUSE_GCC_ATOM
IC_BUILTINS -DMISSING_64BIT_ATOMICS -DHAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H 
-DHAVE_DLFCN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_POSIX_MEMALIGN 
-DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_STRTOD_L -DHA
VE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD -DHAVE_LIBDRM 
-DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 -DHAVE_WAYLAND_PLATFORM 
-DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-Werror=return-type -fno-math-errno -fno-trapping-math -Qunused-arguments 
-Wno-missing-field-initializers -O2 -g -fstack-protector-stro
ng -fno-strict-aliasing -fPIC -pthread -Werror=pointer-arith -Werror=vla 
-fvisibility=hidden -MD -MQ 'src/util/ed6d25d@@mesa_util@sta/u_atomic.c.o' -MF 
'src/util/ed6d25d@@mesa_util@sta/u_atomic.c.o.d'
 -o 'src/util/ed6d25d@@mesa_util@sta/u_atomic.c.o' -c ../src/util/u_atomic.c
../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function 
'__sync_add_and_fetch_8'
__sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin with 
type 'long long (volatile long long *, long long, ...)'
../src/util/u_atomic.c:38:1: error: definition of builtin function 
'__sync_add_and_fetch_8'
__sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function 
'__sync_sub_and_fetch_8'
__sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin with 
type 'long long (volatile long long *, long long, ...)'
../src/util/u_atomic.c:51:1: error: definition of builtin function 
'__sync_sub_and_fetch_8'
__sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function 
'__sync_val_compare_and_swap_8'
__sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t newval)
^
../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a builtin 
with type 'long long (volatile long long *, long long, long long, ...)'
../src/util/u_atomic.c:64:1: error: definition of builtin function 
'__sync_val_compare_and_swap_8'
__sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t newval)
^
6 errors generated.

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
/usr/obj/DESTDIRs/clang-powerpc-installworld-poud
FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
/usr/obj/DESTDIRs/clang-powerpc64-installworld-poud

FBSDpowerpc was in use on/under:

# uname -apKU
FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #7 r363123M: Sun Jul 12 
03:06:20 PDT 2020 
markmi@FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG
  powerpc powerpc64 1300101 1300101

# svnlite info /usr/ports
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 542111
Node Kind: directory
Schedule: normal
Last Changed Author: vanilla
Last Changed Rev: 542111
Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list

Re: devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

2020-07-21 Thread Mark Millard via freebsd-ports
On 2020-Jul-21, at 01:45, Piotr Kubaj  wrote:

> Please try after r542724.

For 32-bit powerpc: devel/libffi built. Some dependent ports have built. (More 
are building.)

It will be a while before I try powerpc64: There are 130+ 32-bit ports still to 
build. It  takes
a while.

> On 20-07-20 16:33:27, Mark Millard wrote:
>> 
>> 
>> On 2020-Jul-20, at 16:13, Piotr Kubaj  wrote:
>>> 
>>> Thanks for your report. I'm currently testing whether powerpc(64) on
>>> 12.1 and head can build with this patch
>>> https://github.com/libffi/libffi/commit/01a75ed76ea7e57f1b7a5c183e2b1e890e6aa0fd.patch
>> 
>> FYI: I did the powerpc64 bulk build first and it had
>> no problems. As far as libffi goes, __int128 exists for
>> powerpc64. I'm not implying that __int128 should be
>> used for powerpc64.
>> 
>> I'll note that, depending on where/how float128 is
>> used,
>> 
>> typedef char float128[16] __attribute__((aligned(16)));
>> 
>> use as float128 might decay to a pointer in some contexts,
>> unlike what __float128 or __int128 would have done.
>> 
>> 
>>> On 20-07-20 15:27:01, Mark Millard wrote:
 This resulted in: Failed: 1   Skipped: 181
 
 # poudriere jail -l
 JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   
 PATH
 FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
 /usr/obj/DESTDIRs/clang-powerpc-installworld-poud
 FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
 /usr/obj/DESTDIRs/clang-powerpc64-installworld-poud
 
 # svnlite info /usr/ports/
 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: svn://svn.freebsd.org/ports/head
 Relative URL: ^/head
 Repository Root: svn://svn.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 542111
 Node Kind: directory
 Schedule: normal
 Last Changed Author: vanilla
 Last Changed Rev: 542111
 Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)
 
 That gets the errors:
 
 --- src/powerpc/ffi.lo ---
 libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
 -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
 -fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF src/powerpc/.deps/ffi.Tpo 
 -c ../src/powerpc/ffi.c  -fPIC -DPIC -o src/powerpc/.libs/ffi.o
 --- src/powerpc/ffi_sysv.lo ---
 libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
 -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
 -fexceptions -MT src/powerpc/ffi_sysv.lo -MD -MP -MF 
 src/powerpc/.deps/ffi_sysv.Tpo -c ../src/powerpc/ffi_sysv.c  -fPIC -DPIC 
 -o src/powerpc/.libs/ffi_sysv.o
 --- src/powerpc/ffi.lo ---
 In file included from ../src/powerpc/ffi.c:33:
 ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on 
 this target
 typedef __int128 float128;
  ^
 1 error generated.
 --- src/powerpc/ffi_sysv.lo ---
 In file included from ../src/powerpc/ffi_sysv.c:35:
 ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on 
 this target
 typedef __int128 float128;
  ^
 1 error generated.
 --- src/powerpc/sysv.lo ---
 
 For reference:
 
 =>> Building devel/libffi
 build started at Mon Jul 20 14:47:19 PDT 2020
 port directory: /usr/ports/devel/libffi
 package name: libffi-3.3
 building for: FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT powerpc
 maintained by: zeis...@freebsd.org
 Makefile ident:  $FreeBSD: head/devel/libffi/Makefile 541239 
 2020-07-04 22:15:48Z pkubaj $
 Poudriere version: 3.3.99.20200326
 Host OSVERSION: 1300101
 Jail OSVERSION: 1300101
 . . .
  /usr/ports/Mk/Scripts/ports_env.sh 
 _CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 
 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
 Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
 /usr/bin
 _ALTCCVERSION_921dbbb2=none
 _CXXINTERNAL_acaad9ca=FreeBSD clang version 10.0.1 
 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
 Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
 /usr/bin "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" 
 "/libexec/ld-elf.so.1" "--enable-new-dtags" "-m" "elf32ppc_fbsd" "-o" 
 "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" 
 "-L/usr/lib" "/dev/null" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" 
 "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
 "/usr/lib/crtend.o" "/usr/lib/crtn.o"
 . . .
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net  went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list

Re: Why lang/gcc9 depends native-binutils ?

2020-07-21 Thread Mark Millard via freebsd-ports
KIRIYAMA Kazuhiko kiri at truefc.org wrote on
Tue Jul 21 02:33:25 UTC 2020 :

> checking for iconv declaration... 
>  extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, 
> char * *outbuf, size_t *outbytesleft);
> *** BFD does not support target native-unknown-freebsd13.0.
> *** Look in bfd/config.bfd for supported targets.
> gmake[3]: *** [Makefile:3563: configure-binutils] Error 1
> gmake[3]: Leaving directory 
> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
> gmake[2]: *** [Makefile:851: all] Error 2
> gmake[2]: Leaving directory 
> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1

lang/gcc9/Makefile references binutils via:

BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils
RUN_DEPENDS+=   ${LOCALBASE}/bin/as:devel/binutils
. . .
USE_BINUTILS=   yes

The BUILD_DEPENDS and RUN_DEPENDS references to
binutils are to the assembler that binutils
generates and installs. So gcc9 needs to be able
to use that assembler at both gcc9 build-time and
gcc9 run-time.

The notation leaves the FLAVOR implicit/empty and
so should lead to devel/binutils/Makefile using
its line:

FLAVOR?=native

to assign the "native" for its own internal logic
to use.



Hmm. The "target native-unknown-freebsd13.0" looks
very odd to me. The only lines in the devel/binutils
Makefile to deal with "unknown-" text directly are:

# grep -r unknown- /usr/ports/devel/binutils/
/usr/ports/devel/binutils/Makefile:BUTARGET?=   
${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
/usr/ports/devel/binutils/Makefile:BUTARGET=
x86_64-unknown-${OPSYS:tl}${OSREL}

(I'll later deal with an indirection where "_" is
replaced by "-".)

Only the 1st line of that pair would potentially form
"native-unknown-" text.

So looking at the context of the first line I find
(". . ." for omitted lines):

FLAVOR?=native
. . .
.if ${FLAVOR} != native
PKGNAMEPREFIX=  ${FLAVOR:C/_/-/g}-
PLIST=  ${PKGDIR}/pkg-plist-${FLAVOR:C/_/-/g}

.if ${PKGNAMEPREFIX:M*-*-}
BUTARGET?=  ${PKGNAMEPREFIX}${OPSYS:tl}${OSREL}
.else
BUTARGET?=  ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
.endif

. . .

CONFIGURE_ARGS+=--disable-shared \
--target=${BUTARGET}
.endif


(That is also the only instance of "--target=" in the
Makefile.)

The ${FLAVOR} != native test should mean that the code
is not used for FLAVOR being exactly "native".

There is a separate code block for:

.if ${FLAVOR} == native
BUREMOVE=   coffdump \
dlltool \
dllwrap \
nlmconv \
srconv \
sysdump \
windmc \
windres
USES+=  localbase
CONFIGURE_ARGS+=--with-system-zlib \
--with-gmp=${LOCALBASE} \
--with-mpfr=${LOCALBASE} \
--enable-targets=all \
--enable-threads=yes
INFO=   as \
binutils \
gprof \
bfd \
ld
.endif

But that code does not specify a specific target
(instead: "--enable-targets=all").

There is the FLAVOR value "riscv32_unknown_elf" that
could produce target "riscv32-unknown-elf-freebsd13.0"
but that is not what was reported as involved.

I've ignored CROSS_TOOLCHAIN infrastructure as
it was not mentioned as being in use.

I do not see how devel/binutils/Makefile would
generate "native-unknown-freebsd13.0" text on
its own.


Sorry I've not been able to identify anything for
the error.

I'll note that I build ports with poudriere (-devel
variant) and have not had the problem in that
context.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

2020-07-20 Thread Mark Millard via freebsd-ports



On 2020-Jul-20, at 16:13, Piotr Kubaj  wrote:
> 
> Thanks for your report. I'm currently testing whether powerpc(64) on
> 12.1 and head can build with this patch
> https://github.com/libffi/libffi/commit/01a75ed76ea7e57f1b7a5c183e2b1e890e6aa0fd.patch

FYI: I did the powerpc64 bulk build first and it had
no problems. As far as libffi goes, __int128 exists for
powerpc64. I'm not implying that __int128 should be
used for powerpc64.

I'll note that, depending on where/how float128 is
used,

typedef char float128[16] __attribute__((aligned(16)));

use as float128 might decay to a pointer in some contexts,
unlike what __float128 or __int128 would have done.


> On 20-07-20 15:27:01, Mark Millard wrote:
>> This resulted in: Failed: 1   Skipped: 181
>> 
>> # poudriere jail -l
>> JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
>> FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
>> /usr/obj/DESTDIRs/clang-powerpc-installworld-poud
>> FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
>> /usr/obj/DESTDIRs/clang-powerpc64-installworld-poud
>> 
>> # svnlite info /usr/ports/
>> Path: /usr/ports
>> Working Copy Root Path: /usr/ports
>> URL: svn://svn.freebsd.org/ports/head
>> Relative URL: ^/head
>> Repository Root: svn://svn.freebsd.org/ports
>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
>> Revision: 542111
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: vanilla
>> Last Changed Rev: 542111
>> Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)
>> 
>> That gets the errors:
>> 
>> --- src/powerpc/ffi.lo ---
>> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
>> -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
>> -fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF src/powerpc/.deps/ffi.Tpo -c 
>> ../src/powerpc/ffi.c  -fPIC -DPIC -o src/powerpc/.libs/ffi.o
>> --- src/powerpc/ffi_sysv.lo ---
>> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
>> -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
>> -fexceptions -MT src/powerpc/ffi_sysv.lo -MD -MP -MF 
>> src/powerpc/.deps/ffi_sysv.Tpo -c ../src/powerpc/ffi_sysv.c  -fPIC -DPIC -o 
>> src/powerpc/.libs/ffi_sysv.o
>> --- src/powerpc/ffi.lo ---
>> In file included from ../src/powerpc/ffi.c:33:
>> ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
>> target
>> typedef __int128 float128;
>>   ^
>> 1 error generated.
>> --- src/powerpc/ffi_sysv.lo ---
>> In file included from ../src/powerpc/ffi_sysv.c:35:
>> ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
>> target
>> typedef __int128 float128;
>>   ^
>> 1 error generated.
>> --- src/powerpc/sysv.lo ---
>> 
>> For reference:
>> 
>> =>> Building devel/libffi
>> build started at Mon Jul 20 14:47:19 PDT 2020
>> port directory: /usr/ports/devel/libffi
>> package name: libffi-3.3
>> building for: FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT powerpc
>> maintained by: zeis...@freebsd.org
>> Makefile ident:  $FreeBSD: head/devel/libffi/Makefile 541239 2020-07-04 
>> 22:15:48Z pkubaj $
>> Poudriere version: 3.3.99.20200326
>> Host OSVERSION: 1300101
>> Jail OSVERSION: 1300101
>> . . .
>>  /usr/ports/Mk/Scripts/ports_env.sh 
>> _CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 
>> (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
>> Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
>> /usr/bin
>> _ALTCCVERSION_921dbbb2=none
>> _CXXINTERNAL_acaad9ca=FreeBSD clang version 10.0.1 
>> (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
>> Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
>> /usr/bin "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" 
>> "/libexec/ld-elf.so.1" "--enable-new-dtags" "-m" "elf32ppc_fbsd" "-o" 
>> "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" 
>> "-L/usr/lib" "/dev/null" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" 
>> "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
>> "/usr/lib/crtend.o" "/usr/lib/crtn.o"
>> . . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

2020-07-20 Thread Mark Millard via freebsd-ports
This resulted in: Failed: 1   Skipped: 181

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
/usr/obj/DESTDIRs/clang-powerpc-installworld-poud
FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
/usr/obj/DESTDIRs/clang-powerpc64-installworld-poud

# svnlite info /usr/ports/
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 542111
Node Kind: directory
Schedule: normal
Last Changed Author: vanilla
Last Changed Rev: 542111
Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)

That gets the errors:

--- src/powerpc/ffi.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
-I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
-fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF src/powerpc/.deps/ffi.Tpo -c 
../src/powerpc/ffi.c  -fPIC -DPIC -o src/powerpc/.libs/ffi.o
--- src/powerpc/ffi_sysv.lo ---
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
-I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
-fexceptions -MT src/powerpc/ffi_sysv.lo -MD -MP -MF 
src/powerpc/.deps/ffi_sysv.Tpo -c ../src/powerpc/ffi_sysv.c  -fPIC -DPIC -o 
src/powerpc/.libs/ffi_sysv.o
--- src/powerpc/ffi.lo ---
In file included from ../src/powerpc/ffi.c:33:
../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
target
typedef __int128 float128;
^
1 error generated.
--- src/powerpc/ffi_sysv.lo ---
In file included from ../src/powerpc/ffi_sysv.c:35:
../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on this 
target
typedef __int128 float128;
^
1 error generated.
--- src/powerpc/sysv.lo ---

For reference:

=>> Building devel/libffi
build started at Mon Jul 20 14:47:19 PDT 2020
port directory: /usr/ports/devel/libffi
package name: libffi-3.3
building for: FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT powerpc
maintained by: zeis...@freebsd.org
Makefile ident:  $FreeBSD: head/devel/libffi/Makefile 541239 2020-07-04 
22:15:48Z pkubaj $
Poudriere version: 3.3.99.20200326
Host OSVERSION: 1300101
Jail OSVERSION: 1300101
. . .
 /usr/ports/Mk/Scripts/ports_env.sh 
_CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin
_ALTCCVERSION_921dbbb2=none
_CXXINTERNAL_acaad9ca=FreeBSD clang version 10.0.1 
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin 
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" 
"--enable-new-dtags" "-m" "elf32ppc_fbsd" "-o" "a.out" "/usr/lib/crt1.o" 
"/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/dev/null" "-lc++" "-lm" 
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" 
"-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"
. . .

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


armv7: x11-toolkits/qt5-gui still blocked by 'unable to execute command: Executable "as" doesn't exist!' for .obj/qdrawhelper_neon_asm.o and .obj/pixman-arm-neon-asm.o

2020-07-15 Thread Mark Millard via freebsd-ports
In my poudriere-devel based port upgrade's bulk run I got:

--- .obj/qdrawhelper_neon_asm.o ---
cc: error: unable to execute command: Executable "as" doesn't exist!
cc: error: assembler command failed with exit code 1 (use -v to see invocation)
*** [.obj/qdrawhelper_neon_asm.o] Error code 1

make[1]: stopped in 
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.15.0/src/gui
--- .obj/pixman-arm-neon-asm.o ---
cc: error: unable to execute command: Executable "as" doesn't exist!
cc: error: assembler command failed with exit code 1 (use -v to see invocation)
*** [.obj/pixman-arm-neon-asm.o] Error code 1

This was based on head -r363123 of FreeBSD and -r542111 of ports.

The following experiment was sufficient to enable
the x11-toolkits/qt5-gui build to not fail. (I do
not claim it meets all ports-criteria for its
details.)


# svnlite diff /usr/ports/x11-toolkits/qt5-gui/
Index: /usr/ports/x11-toolkits/qt5-gui/Makefile
===
--- /usr/ports/x11-toolkits/qt5-gui/Makefile(revision 542111)
+++ /usr/ports/x11-toolkits/qt5-gui/Makefile(working copy)
@@ -106,4 +106,10 @@
${MAKE_ARGS} ${INSTALL_TARGET}
 .endfor
 
-.include 
+.include 
+
+.if ${ARCH} == "armv6" || ${ARCH} == "armv7"
+BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils
+.endif
+
+.include 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Jumbled dependencies

2020-06-18 Thread Mark Millard via freebsd-ports
Thomas Mueller mueller6722 at twc.com wrote on
Fri Jun 19 01:31:47 UTC 2020 :

> > > I do package builds on one machine on my (small) network, using
> > > portmaster [...]
> [...]
> > > And how do I bandage up the foot I shot myself in?
> 
> > I understand it might be unpopular, but the preferred way to get
> > to stable updates in the ports tree is using poudriere to
> > build the ports and the pkg repo.
> 
> > pi at opsec.eu+49 171 3101372Now what ?
> 
> What is the current status of synth?  I see little or no updating activity, 
> and no update to gcc6.aux while gcc is updated to 10.1.

https://github.com/jrmarino/synth/ seems to have
been touched the last 2 mostly recent times on:

A) 2020-Feb-24 (v2.09)
B) 2019-Jan-30 (v2.08)

So it appears that it is in a fairly stable state for whatever
contexts use it. I've not checked what eversion of ada is in
use wherever synth is in use. (I've not researched where either.
It did not run on the full range of architectures I wanted
back when I experimented with it.)

> Does poudriere install build dependencies by default or when requested? 

The question is really where and when build-dependencies are
built, installed, and removed for poudriere.

Poudriere normally has uses own work area instead of touching the
system/environment that it is invoked from. In this area each port
is built into a package via the steps (quick summary for the point
at hand):

A) install build-dependencies to a local/internal context
   (such dependencies were built earlier if needed).
B) build the package in that context and file away the package
   for later use (including in building more ports).
C) clean out that local/internal context.

So, at build time, during a poudriere bulk operation for a port, the
build dependencies needed are available for the port build to use.

Yes, this does mean that across building many ports in a poudriere
bulk build, various build-dependencies are repeatedly installed
(once per port that depends on the it), instead of being installed
just once and re-used for each port that happens to have the
dependency.

It also means that, during a port build, the only ports installed
locally/internally are the ports that are explicit build dependencies,
no extras (part of being a clean build environment for the port).

After poudriere is done, pkg update; package install can later be
used to install into the system/environment any or all of the ports
that were built into packages, including those there were built just
because they were dependecies of something else that was directly
requested. (Worded for local builds locally installed to the
same machine.)

> I looked through the FreeBSD Handbook and Porters' Handbook online, and 
> couldn't find the answer.
> 
> With synth, I had a difficult time getting everything that was built to 
> install, some packages like bison are needed in building other software.
> 
> How is poudriere in that regard?
> 
> Gentoo Linux with portage has "--with-bdeps=y" which installs build 
> dependencies when desired.
> 
> I found that poudriere uses dialog4ports; I much prefer to save options in a 
> file such as Gentoo Linux does with make.conf and (NetBSD) pkgsrc does with 
> mk.conf .

The files with the information are text and are stored in the file system
and can be created and edited manually.

For example:

# find /usr/local/etc/poudriere.d/ -name options -type f -print
/usr/local/etc/poudriere.d/options/lang_gcc8/options
/usr/local/etc/poudriere.d/options/ports-mgmt_poudriere-devel/options
/usr/local/etc/poudriere.d/options/lang_gcc9/options
/usr/local/etc/poudriere.d/options/devel_llvm80/options
/usr/local/etc/poudriere.d/options/devel_llvm90/options
/usr/local/etc/poudriere.d/options/devel_llvm10/options
/usr/local/etc/poudriere.d/options/lang_gcc10/options
/usr/local/etc/poudriere.d/FBSDFSSDjail-options/lang_gcc8/options
/usr/local/etc/poudriere.d/FBSDFSSDjail-options/ports-mgmt_poudriere-devel/options
/usr/local/etc/poudriere.d/FBSDFSSDjail-options/lang_gcc9/options
/usr/local/etc/poudriere.d/FBSDFSSDjail-options/devel_llvm80/options
/usr/local/etc/poudriere.d/FBSDFSSDjail-options/devel_llvm90/options
/usr/local/etc/poudriere.d/FBSDFSSDjail-options/devel_llvm10/options
/usr/local/etc/poudriere.d/FBSDFSSDjail-options/lang_gcc10/options

The area is separate from FreeBSD's /var/db/ports/*_*/options files.

> I once got a royal mess of circular/jumbled dependencies with dialog4ports; 
> cleaning was a major nuisance, nothing simple like editing /etc/mk.conf or 
> /etc/make.conf .
> 
> I never used pkgsrc with any OS other than NetBSD but have thought about it 
> for FreeBSD and possibly Linux.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Which u-boot for rpi3? u-boot-rpi3-32 or the old one?

2020-06-17 Thread Mark Millard via freebsd-ports
On 2020-Jun-16, at 22:21, bob prohaska  wrote:

> On Tue, Jun 16, 2020 at 09:59:24PM -0700, Mark Millard wrote:
>> 
>> 
>> On 2020-Jun-16, at 21:34, bob prohaska  wrote:
>> 
>>> Just noticed there are now two u-boot ports for the RPi3, one
>>> called u-boot-rpi3-32 and (the presumably original) u-boot-rpi3.
>>> 
>>> The descriptions are equally bland, what's the difference?
>>> The goal is to boot a recent snapshot of -current from USB
>>> using a Pi3b (no +). Now it's suffering from cpu_reset failed.
>> 
>> Looking, the check in history for sysutils/u-boot-rpi3-32
> 
> Could you write a few words about how one checks such history?
> There doesn't seem to be anything in /usr/ports/UPDATING.


Getting there directly:

https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi3-32/?view=log


In steps via exploring:

https://svnweb.freebsd.org

then click on ports/ to get to: https://svnweb.freebsd.org/ports/

then click on head/ to get to: https://svnweb.freebsd.org/ports/head/

then click on sysutils/ to get to: 
https://svnweb.freebsd.org/ports/head/sysutils/

then select Page 2 in the Page popup so that the various u-boot* would
be in range
 This gets one to: 
https://svnweb.freebsd.org/ports/head/sysutils/?dir_pagestart=1000
 (currently)

then click on the number to the right of u-boot-rpi3-32/ (536829 currently)
 This gets one to: 
https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi3-32/?view=log

For the example in use here there is only one log entry
currently.

>> reports for the creation of sysutils/u-boot-rpi3-32 :
>> 
>> Revision 536829 - Directory Listing 
>> Added Fri May 29 01:27:16 2020 UTC (2 weeks, 5 days ago) by brd
>> Add sysutils/u-boot-rpi3-32 to build a 32-bit version of u-boot
>> 
>> This is useful for using the camera hardware, as
>> misc/raspberrypi-userland does not support aarch64.
>> 
>> Approved by: imp, manu
>> Differential Revision:   
>> https://reviews.freebsd.org/D21603
>> 
>> 
>> So:
>> 
>> A) sysutils/u-boot-rpi3 is for use with aarch64 FreeBSD
>> B) sysutils/u-boot-rpi3-32 is for use with armv7 FreeBSD
>> 
>> 
> 
> Mine is case A, but Case B is a little puzzling; will armv7 
> run on a Pi3 ? I thought arm64 was mandatory.

Sure, even Raspberry Pi OS still does not even have an
official 64-bit release for any armv7 or later based
Raspberry Pi that I'm aware of: all armv7 for official
releases for such RPi*'s. (There are earlier stage
64-bit materials these days for the aarch64 capable
RPi*'s, at least for the kernel. But no 64-bit/aarch64
userland that I'm aware of: just armv7.)

I'm unclear on if there are contexts for
which both sysutils/u-boot-rpi2/ and
sysutils/u-boot-rpi3-32/ are possibilities
for use with armv7 FreeBSD. sysutils/u-boot-rpi2/
does have a log entry indicating that it was
tested on both a RPi2 V1.1 and a v1.2, but it is
not explicit about which FreeBSD variant(s) were
involved for either. If there are contexts where
both u-boot's are possibilities, then I do not
know why one would pick one over the other.
May be sysutils/u-boot-rpi2/ can not handle
an RPi3 despite handling a RPi2 V1.2?


FYI: even under aarch64 FreeBSD, one can
install an armv7 world in its own directory
tree and chroot to it and run armv7 software
(world material, ports, etc., not kernel).
And poudriere can use such to do armv7 port
builds on CortexA53/A57/A72 and many more
without qemu being involved (or even
installed).

(There are oddities like Cortex-A32 that is
ARMv8.0-A but 32-bit only and Cortex-A34 that
is ARMv8.0-A but 64-bit only. Qualcomm also
has an ARMv8.1-A that is AArch64 only, not
32-bit. There may be more such oddities.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Which u-boot for rpi3? u-boot-rpi3-32 or the old one?

2020-06-16 Thread Mark Millard via freebsd-ports



On 2020-Jun-16, at 21:34, bob prohaska  wrote:

> Just noticed there are now two u-boot ports for the RPi3, one
> called u-boot-rpi3-32 and (the presumably original) u-boot-rpi3.
> 
> The descriptions are equally bland, what's the difference?
> The goal is to boot a recent snapshot of -current from USB
> using a Pi3b (no +). Now it's suffering from cpu_reset failed.

Looking, the check in history for sysutils/u-boot-rpi3-32
reports for the creation of sysutils/u-boot-rpi3-32 :

Revision 536829 - Directory Listing 
Added Fri May 29 01:27:16 2020 UTC (2 weeks, 5 days ago) by brd
Add sysutils/u-boot-rpi3-32 to build a 32-bit version of u-boot

This is useful for using the camera hardware, as
misc/raspberrypi-userland does not support aarch64.

Approved by:imp, manu
Differential Revision:  
https://reviews.freebsd.org/D21603


So:

A) sysutils/u-boot-rpi3 is for use with aarch64 FreeBSD
B) sysutils/u-boot-rpi3-32 is for use with armv7 FreeBSD


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: 'asm/hwcap.h' file not found building chromium on Pi3

2020-05-31 Thread Mark Millard via freebsd-ports



On 2020-May-31, at 19:22, bob prohaska  wrote:

> Made another attempt to compile www/chromium on a Pi3B, this time using
> a mechanical hard disk for all storage (and boot). It stopped with
> 
> ../../third_party/zlib/cpu_features.c:32:10: fatal error: 'asm/hwcap.h' file 
> not found
> #include 
> ^
> 1 error generated.
> 
> Ports are at Revision: 537041, uname -a reports 12.1-STABLE r361429 
> GENERIC  arm64. All make commands used -DBATCH.

Warning: I did not version match to -r537041
so this is only suggestive unless confirmed.
But I do not keep referencing that status
below.

Not that it solves the problem, but
some context indicates that it is
likely a problem with the port (since
chromium of itself does not support
FreeBSD) . . .

>From the cpu_features.c source:

#if defined(ARMV8_OS_ANDROID)
#include 
#elif defined(ARMV8_OS_LINUX)
#include 
#include 
#elif defined(ARMV8_OS_FUCHSIA)
#include 
#include 
#include 
#elif defined(ARMV8_OS_WINDOWS) || defined(X86_WINDOWS)
#include 
#elif !defined(_MSC_VER)
#include 
#else
#error cpu_features.c CPU feature detection in not defined for your platform
#endif

So your build has ARMV8_OS_LINUX defined and also
tried to build based in part on:

third_party/zlib/cpu_features.c

A grep -r shows all the references to ARMV8_OS_LINUX
are under third_party/zlib/ . ARMV8_OS_LINUX is from
the third_party/zlib/BUILD.gn code:

. . .
if (use_arm_neon_optimizations) {
  config("zlib_arm_crc32_config") {
# Disabled for iPhone, as described in DDI0487C_a_armv8_arm:
#  "All implementations of the ARMv8.1 architecture are required to
#   implement the CRC32* instructions. These are optional in ARMv8.0."
if (!is_ios) {
  defines = [ "CRC32_ARMV8_CRC32" ]
  if (is_android) {
defines += [ "ARMV8_OS_ANDROID" ]
  } else if (is_linux || is_chromeos) {
defines += [ "ARMV8_OS_LINUX" ]
  } else if (is_fuchsia) {
. . .

is_linux seems to in turn be from:

chromium-*/build/config/BUILDCONFIG.gn

and its:

is_linux = current_os == "chromeos" || current_os == "linux" || current_os == 
"freebsd"

The freebsd reference here (and elsewhere in that file)
are from the port's patching activity.

chromium does not seem to support FreeBSD of itself
so it seems the problem would be considered to be
in the port instead.

I've no clue what a proper alternative would be for
third_party/zlib/cpu_features.c to use in a FreeBSD
context.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Missing /dev/io on rpi3 running 12-stable

2020-05-23 Thread Mark Millard via freebsd-ports



On 2020-May-20, at 11:16, bob prohaska  wrote:

> On Wed, May 20, 2020 at 07:09:11PM +0200, Mika??l Urankar wrote:
>> Le mer. 20 mai 2020 ?? 18:46, bob prohaska  a ??crit :
>>> 
>>> Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
>>> Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
>>> a report of "failed to open /dev/io". There is indeed no /dev/io,
>>> but there's also no /dev/io on a pi2 running 12-stable.
>>> 
>>> Nor does there seem to be  a kernel module with matching name
>>> 
>>> Thanks for reading!
>>> 
>>> bob prohaska
>> 
>> I haven't looked closely but it seems the error is in
>> x11-servers/xorg-server/files/configure.ac, AC_DEFINE(USE_DEV_IO)
>> 
> 
> Alas, the remedy does not suggest itself, at least not to me
> 
> Can somebody offer a hint?

Only partially . . .

I've got a RPi3 going and:

A) It has the xf86EnableIO routine that would try
   the open and call xf86Msg to report the issue.

B) Setting a breakpoint on xf86EnableIO and running
   never triggers the breakpoint in my context.

So having USE_DEV_IO defined is not sufficient to see
the problem.

You have one context that gets the problem and another
that does not (changing users).

Overall suggests that there is some login-specific
configuration is controlling which way it works at
runtime.

A possibility here is:

QUOTE
20200220:
  AFFECTS: users of x11-servers/xorg-server
  AUTHOR: zeis...@freebsd.org

  x11-servers/xorg-server has been updated to 1.20.7.

  With this update, xorg-server has switched from using the devd backend to
  the udev backend for device configuration on FreeBSD 12 and 13.  If you have
  issues with input devices, please see the install message for details.

  The HAL backend option has been completely removed, as it was deprecated.

  If you have problems with input devices, ensure that both x11/libinput and
  x11-drivers/xf86-input-libinput are installed.  They are installed in the
  default configuration, but if you have a custom configuration, they might not
  be.
END QUOTE

Are you using udev in both user contexts? devd? A mix across the contexts?
I'm consistently using udev.

This does seem to match up with what you have reported in that the
context that worked had the below message (for example) but the
failing one did not:

[253234.564] (II) The server relies on udev to provide the list of input 
devices.
   If no devices become available, reconfigure udev or disable 
AutoAddDevices.

The message was before reporting the "Module ABI versions" information.

So your failing context is either devd based or still has the environment
configured for HAL or is otherwise messed up such that udev is not in
use.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Missing /dev/io on rpi3 running 12-stable

2020-05-20 Thread Mark Millard via freebsd-ports



On 2020-May-20, at 19:25, bob prohaska  wrote:
> 
> Which list is the appropriate forum, -ports, -arm or something else?
> If there is a better problem description I'll use it.  ISTR xorg 
> compiling and running without a hitch on -current previously, ~ 
> a year ago.

Does not look like I can match the RPi3 context
as a cross check. (I tried.) At best a RPi4.

I do not normally use a display but I normally do
build lumina and what it requires as part of checking
the build environment. (head -r360311 contexts
currently.)

I tried to see what I could do on the RPi3 and RPi4. The
surprise: RPi4 output worked fine at all stages and the
RPI3 got no video output at all at any time, not even the
RPi3's own early-stage test-output. (Same HDMI display
used for both.)

Both the RPi3 and RPi4 do report the following
when the display is connected:

EFI framebuffer information:
addr, size 0x3e513000, 0x6d8c00
dimensions 1824 x 984
stride 1824
masks  0x00ff, 0xff00, 0x00ff, 0xff00
. . .
VT(efifb): resolution 1824x984

Without the HDMI connection the RPi3 shows:

EFI framebuffer information:
addr, size 0x3eaf7000, 0x103000
dimensions 592 x 448
stride 592
masks  0x00ff, 0xff00, 0x00ff, 0xff00
. . .
VT(efifb): resolution 592x448

Back to with the HDMI connection . . .

Both RPi*'s show:

fb0:  on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 1824x984(1824x984@0,0) 32bpp
fb0: fbswap: 1, pitch 7296, base 0x3e513000, screen_size 7237632

It leaves me wondering if the RPi3 has a hardware
problem. (No display output even before u-boot is
involved, unlike normal.)


As for the RPi4: I do not see any attempt at a
/dev/io reference or any additional kernel modules
loaded. It does:

. . .
[   137.989] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
. . .
[   138.129] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
. . .
[   138.136] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
. . .
[   138.141] (II) Loading /usr/local/lib/xorg/modules/libshadow.so
. . .
[   138.144] (II) Loading /usr/local/lib/xorg/modules/libfb.so
. . .
[   140.068] (II) Loading /usr/local/lib/xorg/modules/input/libinput_drv.so
. . .

and kldstat shows:

# kldstat
Id Refs AddressSize Name
 16 0x  112dbf8 kernel
 21 0x0112e000257c8 umodem.ko
 32 0x0115400028658 ucom.ko

My ports builds are based on ports head -r533162 . I
explicitly build the following related to lumina
for the aarch64 contexts:

x11-drivers/xf86-video-scfb
x11/lumina
x11/xorg-minimal
x11/xterm

These, of course, lead to much more building. I built
with default options for them all.

No mouse or usb keyboard input to use lumina with on
the RPi4 so I can not claim anything about past its
initial display.

In my context, startx is tied to:

# more ~/.xinitrc 
exec start-lumina-desktop

# ls -laT /etc/X11/
total 8
drwxr-xr-x   2 root  wheel   512 Mar 30 05:23:44 2020 .
drwxr-xr-x  27 root  wheel  2560 Apr 29 13:52:48 2020 ..

(Yep: empty.)

That is all I have. I'm not so sure any of it will
happen to help.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Conflict on very first port (xorg) on rpi3

2020-05-15 Thread Mark Millard via freebsd-ports



On 2020-May-15, at 13:03, bob prohaska  wrote:

> On Fri, May 15, 2020 at 12:33:02PM -0700, Mark Millard wrote:
>> [Gack: devel/cmake needs devel/py-sphinx by default
>> and devel/llvm80 needs both devel/cmake and
>> devel/py-pshinx18 by default.]
>> 
>> On 2020-May-15, at 11:59, Mark Millard  wrote:
>>> 
>>> On 2020-May-15, at 11:05, bob prohaska  wrote:
>>> 
>>>> On Fri, May 15, 2020 at 01:49:21PM -0300, Danilo G. Baio wrote:
>>>>> On Fri, May 15, 2020 at 08:19:22AM -0700, bob prohaska wrote:
>>>>>> On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports 
>>>>>> wrote:
>>>>>>> 
>>>>>>> Some building and isntalling had to occur prior to the
>>>>>>> textproc/py-sphinx18 build attempt, possibly from
>>>>>>> prior session(s) of building and installing.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> In this case x11/xorg was the first port attempted in a new
>>>>>> ports tree. The only "prior sessions" would have been within
>>>>>> the dependencies of x11/xorg. Is that resolvable by poudriere?
>>>>>> 
>>>>>>> textproc/py-sphinx18 is new as of 2020-May-11.
>>>>>>> The devel/llvm[16789]0 ports require textproc/py-sphinx18 .
>>>>>>> Only about 26 ports require textproc/py-sphinx18 but
>>>>>>> I'll not list the others.
>>>>>>> 
>>>>>>> textproc/py-sphinx has been around longer and has
>>>>>>> 142 ports that require it. I'll not list them.
>>>>>>> 
>>>>>>> 
>>>>>>> textproc/py-sphinx18/Makefile lists:
>>>>>>> 
>>>>>>> CONFLICTS_INSTALL=  py*-sphinx
>>>>>>> 
>>>>>>> textproc/py-sphinx/Makefile lists:
>>>>>>> 
>>>>>>> CONFLICTS_INSTALL=  py*-sphinx18
>>>>>>> 
>>>>>>> 
>>>>>>> So, for example, indirectly the devel/llvm[16789]0
>>>>>>> ports conflict with at least 142 other ports because
>>>>>>> of the textproc/py-sphinx* difference in requirements.
>>>>>>> 
>>>>>>> 
>>>>>>> The conflict is real and limits what combinations
>>>>>>> of ports you may have installed at the same time.
>>>>>> 
>>>>>> I'll try deinstalling the conflicting port and hope
>>>>>> it won't be required later
>>>>> 
>>>>> It seems that just devel/llvm80 is pulling sphinx18 when building
>>>>> x11/xorg.
>>>>> 
>>>>> Try disabling DOCS option on devel/llvm80 for now.
>>>>> 
>>>>> I've opened a PR to track this issue:
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246487
>>>>> 
>>>> 
>>>> Wish I'd known it was only the DOCS option! Too late now,
>>>> sphinx18 is deinstalled and llvm80 is building.
>>> 
>>> What? llvm80 requires textproc/py-sphinx18 (when
>>> the options cause such), not textproc/py-sphinx .
>>> Deleting textproc/py-sphinx18 and building
>>> devel/llvm80 will try to rebuild/install
>>> textproc/py-sphinx18 unless the options are
>>> set to avoid needing textproc/py-sphinx18 .
>>> 
>>> To build devel/llvm80 it would be
>>> textproc/py-sphinx that would be deinstalled first
>>> so that textproc/py-sphinx18 could be built and
>>> installed during the build.
> 
> Sorry, I mis-wrote. What you're describing is what I did.

Ahh.

>>> 
>>> After devel/llvm80 is installed, textproc/py-sphinx18
>>> would be uninstalled so that textproc/py-sphinx could
>>> be built/installed when xorg is re-tried with llvm80
>>> already installed.
>> 
>> I did not trace down other dependencies but now
>> looking a little (leaving options at defaults):
>> 
>> devel/cmake needs devel/py-sphinx by default
>> and devel/llvm80 needs both devel/cmake and
>> devel/py-pshinx18 by default. (xorg need not
>> bein involved: just building devel/llvm[16789]0
>> has the issue.)
>> 
>> Thus the sequence for default options may need
>> to be something like:
>> 
>> *) Starting without textproc/py-sphinx18
>>   installed
&

Re: Conflict on very first port (xorg) on rpi3

2020-05-15 Thread Mark Millard via freebsd-ports
[Gack: devel/cmake needs devel/py-sphinx by default
and devel/llvm80 needs both devel/cmake and
devel/py-pshinx18 by default.]

On 2020-May-15, at 11:59, Mark Millard  wrote:
> 
> On 2020-May-15, at 11:05, bob prohaska  wrote:
> 
>> On Fri, May 15, 2020 at 01:49:21PM -0300, Danilo G. Baio wrote:
>>> On Fri, May 15, 2020 at 08:19:22AM -0700, bob prohaska wrote:
>>>> On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports 
>>>> wrote:
>>>>> 
>>>>> Some building and isntalling had to occur prior to the
>>>>> textproc/py-sphinx18 build attempt, possibly from
>>>>> prior session(s) of building and installing.
>>>>> 
>>>>> 
>>>> 
>>>> In this case x11/xorg was the first port attempted in a new
>>>> ports tree. The only "prior sessions" would have been within
>>>> the dependencies of x11/xorg. Is that resolvable by poudriere?
>>>> 
>>>>> textproc/py-sphinx18 is new as of 2020-May-11.
>>>>> The devel/llvm[16789]0 ports require textproc/py-sphinx18 .
>>>>> Only about 26 ports require textproc/py-sphinx18 but
>>>>> I'll not list the others.
>>>>> 
>>>>> textproc/py-sphinx has been around longer and has
>>>>> 142 ports that require it. I'll not list them.
>>>>> 
>>>>> 
>>>>> textproc/py-sphinx18/Makefile lists:
>>>>> 
>>>>> CONFLICTS_INSTALL=  py*-sphinx
>>>>> 
>>>>> textproc/py-sphinx/Makefile lists:
>>>>> 
>>>>> CONFLICTS_INSTALL=  py*-sphinx18
>>>>> 
>>>>> 
>>>>> So, for example, indirectly the devel/llvm[16789]0
>>>>> ports conflict with at least 142 other ports because
>>>>> of the textproc/py-sphinx* difference in requirements.
>>>>> 
>>>>> 
>>>>> The conflict is real and limits what combinations
>>>>> of ports you may have installed at the same time.
>>>> 
>>>> I'll try deinstalling the conflicting port and hope
>>>> it won't be required later
>>> 
>>> It seems that just devel/llvm80 is pulling sphinx18 when building
>>> x11/xorg.
>>> 
>>> Try disabling DOCS option on devel/llvm80 for now.
>>> 
>>> I've opened a PR to track this issue:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246487
>>> 
>> 
>> Wish I'd known it was only the DOCS option! Too late now,
>> sphinx18 is deinstalled and llvm80 is building.
> 
> What? llvm80 requires textproc/py-sphinx18 (when
> the options cause such), not textproc/py-sphinx .
> Deleting textproc/py-sphinx18 and building
> devel/llvm80 will try to rebuild/install
> textproc/py-sphinx18 unless the options are
> set to avoid needing textproc/py-sphinx18 .
> 
> To build devel/llvm80 it would be
> textproc/py-sphinx that would be deinstalled first
> so that textproc/py-sphinx18 could be built and
> installed during the build.
> 
> After devel/llvm80 is installed, textproc/py-sphinx18
> would be uninstalled so that textproc/py-sphinx could
> be built/installed when xorg is re-tried with llvm80
> already installed.

I did not trace down other dependencies but now
looking a little (leaving options at defaults):

devel/cmake needs devel/py-sphinx by default
and devel/llvm80 needs both devel/cmake and
devel/py-pshinx18 by default. (xorg need not
bein involved: just building devel/llvm[16789]0
has the issue.)

Thus the sequence for default options may need
to be something like:

*) Starting without textproc/py-sphinx18
   installed

A) build textproc/py-sphinx and devel/cmake
   and install devel/cmake ( py-sphinx can
   be via indirection through devel/cmake )
   (cmake does not have a run-time dependency
   on textproc/py-sphinx as far as I can tell.)

B) uninstall textproc/py-sphinx so that
   textproc/py-sphinx18 can be built and
   installed

C) build textproc/py-shpyinx18 and devel/llvm80
   and install devel/llvm80 ( py-sphinx18 can
   be via indirection through devel/llvm80 )

D) uninstall textproc/py-sphinx18 so that
   either textproc/py-sphinx* can be installed
   if needed

E) build xorg.

(Since I use devel/poudriere-develto build
packages and then install just packages for
things that I run, I do not have to do such
explicit conflict management for build-time
conflicts.)

Of course, figuring out options to change
the status of also may avoid having some
of the dependencies and so avoid some
conflicts.

>> This is probably a dumb question, but is there some way
>

Re: Conflict on very first port (xorg) on rpi3

2020-05-15 Thread Mark Millard via freebsd-ports
On 2020-May-15, at 11:05, bob prohaska  wrote:

> On Fri, May 15, 2020 at 01:49:21PM -0300, Danilo G. Baio wrote:
>> On Fri, May 15, 2020 at 08:19:22AM -0700, bob prohaska wrote:
>>> On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports 
>>> wrote:
>>>> 
>>>> Some building and isntalling had to occur prior to the
>>>> textproc/py-sphinx18 build attempt, possibly from
>>>> prior session(s) of building and installing.
>>>> 
>>>> 
>>> 
>>> In this case x11/xorg was the first port attempted in a new
>>> ports tree. The only "prior sessions" would have been within
>>> the dependencies of x11/xorg. Is that resolvable by poudriere?
>>> 
>>>> textproc/py-sphinx18 is new as of 2020-May-11.
>>>> The devel/llvm[16789]0 ports require textproc/py-sphinx18 .
>>>> Only about 26 ports require textproc/py-sphinx18 but
>>>> I'll not list the others.
>>>> 
>>>> textproc/py-sphinx has been around longer and has
>>>> 142 ports that require it. I'll not list them.
>>>> 
>>>> 
>>>> textproc/py-sphinx18/Makefile lists:
>>>> 
>>>> CONFLICTS_INSTALL=  py*-sphinx
>>>> 
>>>> textproc/py-sphinx/Makefile lists:
>>>> 
>>>> CONFLICTS_INSTALL=  py*-sphinx18
>>>> 
>>>> 
>>>> So, for example, indirectly the devel/llvm[16789]0
>>>> ports conflict with at least 142 other ports because
>>>> of the textproc/py-sphinx* difference in requirements.
>>>> 
>>>> 
>>>> The conflict is real and limits what combinations
>>>> of ports you may have installed at the same time.
>>> 
>>> I'll try deinstalling the conflicting port and hope
>>> it won't be required later
>> 
>> It seems that just devel/llvm80 is pulling sphinx18 when building
>> x11/xorg.
>> 
>> Try disabling DOCS option on devel/llvm80 for now.
>> 
>> I've opened a PR to track this issue:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246487
>> 
> 
> Wish I'd known it was only the DOCS option! Too late now,
> sphinx18 is deinstalled and llvm80 is building.

What? llvm80 requires textproc/py-sphinx18 (when
the options cause such), not textproc/py-sphinx .
Deleting textproc/py-sphinx18 and building
devel/llvm80 will try to rebuild/install
textproc/py-sphinx18 unless the options are
set to avoid needing textproc/py-sphinx18 .

To build devel/llvm80 it would be
textproc/py-sphinx that would be deinstalled first
so that textproc/py-sphinx18 could be built and
installed during the build.

After devel/llvm80 is installed, textproc/py-sphinx18
would be uninstalled so that textproc/py-sphinx could
be built/installed when xorg is re-tried with llvm80
already installed.

> This is probably a dumb question, but is there some way
> to learn at the outset what conflicts need to be worked
> around? Something like a "make conflicts" target? Seemingly 
> it could be done by hand, but that promises to be tedious. 

Not that will tell you what combinations of
options lead to what combinations of required
build or run prerequisites: That could be
a lot of combinations to cover. It is also
dependent on poudriere-like-building vs. not
for build prerequisites having conflicts
involved or not.

If one is familiar enough to see potential
conflicts in lists of dependencies there are
the makefile targets:

 run-depends-list, build-depends-list
  Print a list of all the compile and run
  dependencies, and dependencies of those
  dependencies, by port directory.

 all-depends-list Print a list of all dependencies for the port.

 pretty-print-run-depends-list, pretty-print-build-depends-list
  Print a list of all the compile and run
  dependencies, and dependencies of those
  dependencies, by port name and version.

(but no "all" variant for pretty-print-* ?).
What is listed would depend on the options
specified.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Conflict on very first port (xorg) on rpi3

2020-05-15 Thread Mark Millard via freebsd-ports



On 2020-May-15, at 08:19, bob prohaska  wrote:

> On Fri, May 15, 2020 at 12:33:10AM -0700, Mark Millard via freebsd-ports 
> wrote:
>> 
>> Some building and isntalling had to occur prior to the
>> textproc/py-sphinx18 build attempt, possibly from
>> prior session(s) of building and installing.
>> 
>> 
> 
> In this case x11/xorg was the first port attempted in a new
> ports tree. The only "prior sessions" would have been within
> the dependencies of x11/xorg. Is that resolvable by poudriere?

poudriere builds packages. The pkg install for system use is a
separate operation. During a poudriere package build, the jail
involved only has the packages (internally!) installed that are
needed for the particular build. No build conflict with unneeded
ports (unneeded from the specific build's viewpoint). (That
presumes not doing something odd in configuring poudriere.)

poudriere does spend more time doing pkg installs and later
clean-outs in order to avoid having unnecessary stuff installed
during each package's build (that might conflict).

After the builds, using pkg install still can not install
two ports that have a conflicting "for run" requirements
status. poudriere just avoids the build-time conflicts with
ports not needed for the build.

poudriere can not solve building a port that indicates it
needs conflicting ports to run in order to build. It just
avoids conflicts from ports/packages that are not needed
for the build.

> In compiling poudriere I tried to use the qemu option, since
> this is on and for a non-x86 architecture. It failed, as arm64
> is apparently not supported. Is it required?

I use poudriere on: armv7, aarch64, 32-bit powerpc, powerpc64,
and amd64. I do have amd64 set up for also experimenting with
cross builds to aarch64 and armv7. (Targeting armv7 does not
work so well last I tried.)

The only context were I have qemu involved is amd64 --and only
because of the jails for cross-build experiments. Targeting
amd64 (self targeting) does not use qemu on amd64.

>> textproc/py-sphinx18 is new as of 2020-May-11.
>> The devel/llvm[16789]0 ports require textproc/py-sphinx18 .
>> Only about 26 ports require textproc/py-sphinx18 but
>> I'll not list the others.
>> 
>> textproc/py-sphinx has been around longer and has
>> 142 ports that require it. I'll not list them.
>> 
>> 
>> textproc/py-sphinx18/Makefile lists:
>> 
>> CONFLICTS_INSTALL=  py*-sphinx
>> 
>> textproc/py-sphinx/Makefile lists:
>> 
>> CONFLICTS_INSTALL=  py*-sphinx18
>> 
>> 
>> So, for example, indirectly the devel/llvm[16789]0
>> ports conflict with at least 142 other ports because
>> of the textproc/py-sphinx* difference in requirements.
>> 
>> 
>> The conflict is real and limits what combinations
>> of ports you may have installed at the same time.
> 
> I'll try deinstalling the conflicting port and hope
> it won't be required later


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Conflict on very first port (xorg) on rpi3

2020-05-15 Thread Mark Millard via freebsd-ports



On 2020-May-15, at 00:33, Mark Millard  wrote:

> bob prohaska fbsd at www.zefox.net wrote on
> Fri May 15 04:30:07 UTC 2020 :
> 
>> An attempt to compile x11/xorg on a new installation of 12.1 on a Pi3B 
>> resulted in a
>> conflict:
>> 
>> ===>  Installing for py37-sphinx18-1.8.5_1,1
>> ===>  Checking if py37-sphinx18 is already installed
>> ===>   Registering installation for py37-sphinx18-1.8.5_1,1 as automatic
>> Installing py37-sphinx18-1.8.5_1,1...
>> pkg-static: py37-sphinx18-1.8.5_1,1 conflicts with py37-sphinx-3.0.2,1 
>> (installs files into the same place).  Problematic file: 
>> /usr/local/bin/sphinx-apidoc-3.7
>> *** Error code 70
>> 
>> Had this been the umpteenth port compiled, I'd understand somewhat. 
>> 
>> As the _very_ first port compiled, I'm confounded..
>> Uname -a reports
>> FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361020 GENERIC  
>> arm64
>> Svnlite info /usr/ports reports:
>> Path: /usr/ports
>> Working Copy Root Path: /usr/ports
>> URL: 
>> svn://svn.freebsd.org/ports/head
>> 
>> Relative URL: ^/head
>> Repository Root: 
>> svn://svn.freebsd.org/ports
>> 
>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
>> Revision: 535263
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: jkim
>> Last Changed Rev: 535263
>> Last Changed Date: 2020-05-14 20:52:33 -0700 (Thu, 14 May 2020)
> 
> Both textproc/py-sphinx18 and textproc/py-sphinx require
> the following to have been built and installed already
> in order to build:
> 
> lang/python37
> devel/py-setuptools@py37
> 
> textproc/py-sphinx18 requires 3 more ports as well:
> 
> devel/py-Jinja2@py37
> textproc/py-docutils@py37
> devel/py-six@py37
> 
> Some building and isntalling had to occur prior to the
> textproc/py-sphinx18 build attempt, possibly from
> prior session(s) of building and installing.
> 
> 
> textproc/py-sphinx18 is new as of 2020-May-11.
> The devel/llvm[16789]0 ports require textproc/py-sphinx18 .
> Only about 26 ports require textproc/py-sphinx18 but
> I'll not list the others.
> 
> textproc/py-sphinx has been around longer and has
> 142 ports that require it. I'll not list them.
> 
> 
> textproc/py-sphinx18/Makefile lists:
> 
> CONFLICTS_INSTALL=  py*-sphinx
> 
> textproc/py-sphinx/Makefile lists:
> 
> CONFLICTS_INSTALL=  py*-sphinx18
> 
> 
> So, for example, indirectly the devel/llvm[16789]0
> ports conflict with at least 142 other ports because
> of the textproc/py-sphinx* difference in requirements.
> 
> 
> The conflict is real and limits what combinations
> of ports you may have installed at the same time.


Note: I only counted "required for build", not
"required for run" in my counts of "Require" status.
(I also ignored deleted ports.)

I'll note that devel/poudriere style building of
ports should allow building without having the
conflict (separate jails for each build, each
with its own, local /usr/local/ like area).

But Makefile use, portmaster use, and the like
probably see the conflict because of installing
everything built someplace under (typically)
the system's /usr/local/ and leaving the
installation there.

Only 4 ports require textproc/py-sphinx18 "for
run". 20 ports require textproc/py-sphinx "for
run". devel/llvm[16789]0 do not require either
"for run", just "for build". But that still
leaves the conflict to manage unless a tool with
poudriere-like properties is used to build them.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Conflict on very first port (xorg) on rpi3

2020-05-15 Thread Mark Millard via freebsd-ports
bob prohaska fbsd at www.zefox.net wrote on
Fri May 15 04:30:07 UTC 2020 :

> An attempt to compile x11/xorg on a new installation of 12.1 on a Pi3B 
> resulted in a
> conflict:
> 
> ===>  Installing for py37-sphinx18-1.8.5_1,1
> ===>  Checking if py37-sphinx18 is already installed
> ===>   Registering installation for py37-sphinx18-1.8.5_1,1 as automatic
> Installing py37-sphinx18-1.8.5_1,1...
> pkg-static: py37-sphinx18-1.8.5_1,1 conflicts with py37-sphinx-3.0.2,1 
> (installs files into the same place).  Problematic file: 
> /usr/local/bin/sphinx-apidoc-3.7
> *** Error code 70
> 
> Had this been the umpteenth port compiled, I'd understand somewhat. 
> 
> As the _very_ first port compiled, I'm confounded..
> Uname -a reports
> FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361020 GENERIC  
> arm64
> Svnlite info /usr/ports reports:
> Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: 
> svn://svn.freebsd.org/ports/head
> 
> Relative URL: ^/head
> Repository Root: 
> svn://svn.freebsd.org/ports
> 
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 535263
> Node Kind: directory
> Schedule: normal
> Last Changed Author: jkim
> Last Changed Rev: 535263
> Last Changed Date: 2020-05-14 20:52:33 -0700 (Thu, 14 May 2020)

Both textproc/py-sphinx18 and textproc/py-sphinx require
the following to have been built and installed already
in order to build:

lang/python37
devel/py-setuptools@py37

textproc/py-sphinx18 requires 3 more ports as well:

devel/py-Jinja2@py37
textproc/py-docutils@py37
devel/py-six@py37

Some building and isntalling had to occur prior to the
textproc/py-sphinx18 build attempt, possibly from
prior session(s) of building and installing.


textproc/py-sphinx18 is new as of 2020-May-11.
The devel/llvm[16789]0 ports require textproc/py-sphinx18 .
Only about 26 ports require textproc/py-sphinx18 but
I'll not list the others.

textproc/py-sphinx has been around longer and has
142 ports that require it. I'll not list them.


textproc/py-sphinx18/Makefile lists:

CONFLICTS_INSTALL=  py*-sphinx

textproc/py-sphinx/Makefile lists:

CONFLICTS_INSTALL=  py*-sphinx18


So, for example, indirectly the devel/llvm[16789]0
ports conflict with at least 142 other ports because
of the textproc/py-sphinx* difference in requirements.


The conflict is real and limits what combinations
of ports you may have installed at the same time.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


Re: Poudriere - Compile ALL Ports

2020-05-11 Thread Mark Millard via freebsd-ports
On 2020-May-11, at 11:34, Patrick M. Hausen  wrote:

> I’m confused by this thread. isn’t the point of Poudriere
> bulk builds to

When I listed:

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDFSSDjail  13.0-CURRENT amd64 null   2018-11-09 08:58:53 
/usr/obj/DESTDIRs/clang-amd64-installworld-poud

I probably should have explicitly pointed out the use of "METHOD"
"null" as the type of context I was covering.

Poudiere has many options. One of them for "poudriere jail" is:

 -m methodSpecifies which method to use to create the jail.  
(default:http)
. . .
  null

 This option can be used to import an existing
 directory that already contains an installed
 system.  The path must be specified with -M
 path.  It is expected that this directory be
 installed to with the following:

   /usr/src# make installworld DESTDIR=PATH 
DB_FROM_SRC=1
   /usr/src# make distrib-dirs DESTDIR=PATH 
DB_FROM_SRC=1
   /usr/src# make distribution DESTDIR=PATH 
DB_FROM_SRC=1

 The path will be null-mounted during builds.
 It will not be copied at the time of running
 jail.  Deleting the jail will attempt to re-
 vert any files changed by poudriere.
. . .

This is one way of testing development contexts that
might not exist in svn yet (or ever). There is also
src=PATH and tar=PATH and the like.

Part of my guess was that such a "not from scratch"
context might be in use. The guess could be wrong
for all I know.

The rest of the below is tied the the "-m null" sort
of jail context: It is not covering all poudriere jail
methods.

> - start with a clean jail

If one manually makes the jail unclean by doing chroot and
things like installing ports, poudriere does not clean out
what one did: it takes the jail (mostly) as-is and uses it
to make the reference jail for the run. (That in turn is
used to make the jails for jobs.)

So it is the poudriere user's responsibility to have the
jail's content clean before starting poudriere. (Remember:
-m null as a poudriere jail context is the context being
covered.)

If started clean, poudriere will keep it clean. If started
dirty, poudriere will keep it dirty.

> - build the first port in the list and all dependencies

The order is dependencies have their packages built first
and dependencies are later used by being temporarily
installed in the job's jail before building what was
dependent. After the dependent package is packaged, the
temporary material is eliminated before the next port is
built in that jail.

> - store the packages for later incorporation into the pkg repo

Previously built packages are also used to install
what a dependent port's build depends on, even in the
same overall bulk run.

> - clean out the jail completely

There are multiple jails involved, especially for
parallel jobs.

poudriere makes a reference jail off the original user
jail (off of /usr/obj/DESTDIRs/clang-amd64-installworld-poud
in my example). It then makes jails for the parallel
jobs off the reference jail as I understand. These are what
get poudriere's equivalent of what a "clean out" would be
(between jobs that reuse the specific temporary jail).

For the most part poudriere leaves the likes of
/usr/obj/DESTDIRs/clang-amd64-installworld-poud alone and
works with its temporary reference and job jails.

> - start with the next port in the list

With parallel jobs and complicated dependencies,
the concept of "next" is itself somewhat complicated
but respects the dependency structure by not starting
anything too early for what all it depends on to be
available to be temporarily installed in job's
jail.

> - …
> 
> How can there ever be a build conflict unless there is a bug
> like port A depends on B and ImageMagick 7, while B is
> lagging somewhat behind and depends on ImageMagick 6?

If one has poudriere create the build's reference jail from
a user jail that already has ports installed, then the
reference and job jails will also already have those ports
installed. That in turn can lead to conflicts.

> But if ImageMagick 6 and 7 are not dependencies but intended
> target packages, doesn’t Poudriere build each of them in a shiny
> new empty environment?

The new environment is only empty if the original user jail
was already empty. (Again: the -m null poudriere jail context
is the intended coverage of the statements.)

> At least that’s what I thought our Poudriere was doing all day
> and night and we never had a build conflict like this. Bugs like
> the aforementioned aside.

I do not think that the original report listed 

Re: Poudriere - Compile ALL Ports

2020-05-11 Thread Mark Millard via freebsd-ports
Leander Schaefer info at NetOcean.de wrote on
Tue May 5 20:38:49 UTC 2020 :

> I have been dealing with Poudriere for quite a while and one of the most 
> issues I have is, that I have ports which won't compile along with 
> another. Reason is mostly something like:
> 
> pkg-static: ImageMagick7-7.0.10.6 conflicts with ImageMagick6-6.9.11.6,1 
> (installs files into the same place). Problematic file: 
> /usr/local/bin/Magick++-config
> 
> So in other words a newer version is going to place its binaries etc. 
> into the same place as the previous version. I have read and used 
> something like:
> 
> # Build several PHP versions parallel on the same server:
> # 
> https://github.com/freebsd/poudriere/issues/602
> 
> PHP_ALT=php56 php70 php71 php72 php73
> .for port in ${PHP_ALT}
> .if ${.CURDIR:M*/ports*/*/${port}*}
> DISABLE_CONFLICTS=YES
> PREFIX=/usr/local/${port}
> PHPBASE=/usr/local/${port}
> LOCALBASE=/usr/local
> CONFIGURE_ARGS+=--datadir=/usr/local/${port}/share
> CONFIGURE_ARGS+=--bindir=/usr/local/${port}/bin
> CONFIGURE_ARGS+=--with-config-file-scan-dir=/usr/local/${port}/etc/php
> #CONFIGURE_ARGS+=--with-php-config=/usr/local/${port}/bin/php.conf
> #CONFIGURE_ARGS+=--with-iconv=/usr/local
> #CONFIGURE_ARGS+=--with-pcre-dir=/usr/local
> .endif
> .endfor
> 
> But I was wondering: How is the FreeBSD Team dealing with this, when 
> they compile their packages for the public repository? Because we only 
> use one official repository and all packages are there ... some even 
> with differet options enabled. So how to deal with this? How can I 
> compile the entire ports tree without issues and build a repository of 
> it and some packages even with different options? Lets say one OpenLDAP 
> with SASL and another one with SASL? The only way I was able to do this 
> was building it in separate repositories.

The following is based on a guess about what might be
going on.

In my context, for example, I have:

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDFSSDjail  13.0-CURRENT amd64 null   2018-11-09 08:58:53 
/usr/obj/DESTDIRs/clang-amd64-installworld-poud

I do not chroot into /usr/obj/DESTDIRs/clang-amd64-installworld-poud and
install any ports there. Why? Because the installed port could conflict
with whatever port(s) poudriere bulk might want to install temporarily.
My /usr/obj/DESTDIRs/clang-amd64-installworld-poud/ is only for poudriere's
use.

Having installed ports in /usr/obj/DESTDIRs/clang-amd64-installworld-poud
would also lead to poudriere using the installed port over instead
installing ports that it is building. This can lead t using the wrong
version of such an installed port.

Also, I have:

# ls -laT /usr/obj/DESTDIRs/clang-amd64-installworld-poud/usr/local/
total 8
drwxr-xr-x   2 root  wheel  512 Mar 29 23:31:30 2020 .
drwxr-xr-x  14 root  wheel  512 Apr 29 11:57:28 2020 ..

I do not make that a mount point for making /usr/local
visible for chrooting into clang-amd64-installworld-poud.
This is for the same reason as above: poudriere activity
there could end up conflicting with any pre-existing
content that as made visible in
/usr/obj/DESTDIRs/clang-amd64-installworld-poud/usr/local/ .

I do sometimes create other directory trees for use with
chroot (but not as the PATH for a poudiere jail). In
these I freely install ports.

These notes apply to more than just "bulk -a" builds:
smaller subsets built can have the same problems with
having pre-existing material in an equivalent of my
/usr/obj/DESTDIRs/clang-amd64-installworld-poud/usr/local/
area.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


  1   2   3   4   >