py38-salt-3003.1_1 is not picked up by system with pkg upgrade
Hello all, i saw that py-salt has been updated to 3003.1_1
https://www.freshports.org/sysutils/py-salt/
On my system i have installed py38-salt-3002.6
But if i do a pkg upgrade it will not update py-salt, it updates other
packages but not salt.
If i force a pkg install of py38-salt it tells me that i am using the
latest version.
root@jhost001:/usr/src # pkg install py38-salt
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The most recent versions of packages are already installed
My /etc/pkg/FreeBSD.conf file is set to use the latest repository
FreeBSD: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest";,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
There is no pkg dir in /usr/local/etc/ that could override the base pkg
config.
This is on FreeBSD 13.0-STABLE
Am i missing something?
Re: py38-salt-3003.1_1 is not picked up by system with pkg upgrade
Hi Johan,
As you can see from the freshports page, packages for 3003.1_1 have
not been built yet. It usually takes a few days for the port build
cluster to catch up with changes to the ports tree.
Yours,
Robert Clausecker
Am Fri, Jun 25, 2021 at 11:10:54AM +0200 schrieb Johan Hendriks:
> Hello all, i saw that py-salt has been updated to 3003.1_1
> https://www.freshports.org/sysutils/py-salt/
>
> On my system i have installed py38-salt-3002.6
> But if i do a pkg upgrade it will not update py-salt, it updates other
> packages but not salt.
>
> If i force a pkg install of py38-salt it tells me that i am using the
> latest version.
>
> root@jhost001:/usr/src # pkg install py38-salt
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> Checking integrity... done (0 conflicting)
> The most recent versions of packages are already installed
>
> My /etc/pkg/FreeBSD.conf file is set to use the latest repository
>
> FreeBSD: {
> url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest";,
> mirror_type: "srv",
> signature_type: "fingerprints",
> fingerprints: "/usr/share/keys/pkg",
> enabled: yes
> }
>
> There is no pkg dir in /usr/local/etc/ that could override the base pkg
> config.
>
> This is on FreeBSD 13.0-STABLE
>
> Am i missing something?
>
>
>
--
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments
polkit 0.119 CVE-2021-3560
Could anyone commit this update? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256405 I'm not seeing any reason for it to be held back.
Re: llvm10 build failure on Rpi3
On 2021-Jun-24, at 17:54, Mark Millard wrote: > On 2021-Jun-24, at 17:16, bob prohaska wrote: > >> On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote: >> [huge snip] >>> >>> So: Even going back to June 9 may messed up nfs >>> use. (I've no clue what services you depend on >>> or in what contexts.) You might need to disable >>> nfs even trying to start at the next boot before >>> booting into such an older kernel. >> >> No NFS involved. Right now the machine is running >> FreeBSD 13.0-CURRENT #5 main-c255664-g4d64c7243d26: Sat Jan 9 11:27:58 PST >> 2021 >> >> b...@www.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCAM >> arm64 > > I'll note that the output of -apKU fpr uname: > > # uname -apKU > FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #3 > stable/13-n246090-6e2623c012c3-dirty: Thu Jun 24 13:59:44 PDT 2021 > root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300509 1300509 > > has some extra text at the end that would indicate > when the world is mismatched with the kernel: the > last 2 numbers end up not equal and the prefix 13 > vs. 14 would indicate crossing a major version. > (Kernel newer, world older can be valid/supported.) > >> and repeating the previous attempt to build devel/llvm10 with no other >> intentional changes. >> >>> Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got >>> #define __FreeBSD_version 140 back on Jan-22. >>> >>> Running newer worlds on older kernels is not supported. >>> Generally folks to not track the KBI changes vs. the >>> consequences of not having the right KBI. This makes >>> interpreting results difficult even when it appears to >>> work. There can be mixes like NFS not working but other >>> things working. There could be corruptions but such >>> may not be likely. Do you have what you consider >>> sufficient backups it case things get messed up? (That >>> might be the status of being okay with starting over >>> if something really bad happens.) >>> >> No backups, but I'm not averse to starting from scratch on >> this particular machine. >> >> As it happens, the poudriere session ended much as before: >> >> FAILED: >> lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o >> >> /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS >> -D__STDC_LIMIT_MACROS -Ilib/Target/AArch64 >> -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64 >> -Iinclude -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -O2 >> -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include >> -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include -fPIC >> -fvisibility-inlines-hidden -Werror=date-time >> -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter >> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic >> -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default >> -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor >> -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections >> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include >> -fno-strict-aliasing -DNDEBUG -isystem /usr/local/include >> -fvisibility=hidden -fno-exceptions -std=c++14 -MD -MT >> lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o >> -MF >> lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o.d >> -o >> lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o >> -c >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AArch64InstructionSelector.cpp >> In file included from >> /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AArch64InstructionSelector.cpp:312: >> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:41: error: expected >> expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, >> /*RC*//*AArch64::FPR64RegClassID: @0*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:99: error: expected >> expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, >> /*RC*//*AArch64::FPR64RegClassID: @0*/, >> >>^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:39: error: expected >> expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, >> /*RC*//*AArch64::FPR64RegClassID: @0*/, >> ^ >> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:97: error: expected >> expression >> /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, >> /*RC*//*AArch64::FPR64RegClassID: @0*/, >> >> ^ >> 4 errors generated. >> [ 25% 1396/5364] >
Re: llvm10 build failure on Rpi3
On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote: [huge snip, hope the quotes are still correct] > > So I'm going to suggest using an official kernel build > > as built by the ci.freebsd.org systems, one that is not > > GENERIC-MMCCAM. In: > > World and kernel are updating now to -current as of yesterday. I'll replace GENERIC-MMCCAM with GENERIC for simplicity. > > > > I gather that no RPi4B is available to move the media > > to? (Having more RAM but being able to force much of > > it to be ignored can be handy as a test environment > > for this kind of context.) > > It's still patiently chewing away at www/chromium single-threaded. My mistake, but best to finish what's started.. Now that how to use the packages created is known they can be tested. > > So: no warning about being mis-tuned vs. the 1 GiByte of > used RAM. (I do not know about your context for this.) > My Pi3 does report too much swap. But I remain uncertain about the practical significance of the warning. I gather the issue is that a certain amount memory is set aside to "index", for lack of a better word, the data stored in swap. If there's too much swap relative to index, not all swap can be used. That seems not much different than running out of swap. > All the ports that devel/llvm10 needs are already in place > for poudriere's use for this experiment. > > Another point is: > > # more /usr/local/etc/poudriere.d/options/devel_llvm10/options > # This file is auto-generated by 'make config'. > # Options for llvm10-10.0.1_3 > _OPTIONS_READ=llvm10-10.0.1_3 > _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK > OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD > OPTIONS_FILE_SET+=BE_AMDGPU > OPTIONS_FILE_SET+=CLANG > OPTIONS_FILE_SET+=DOCS > OPTIONS_FILE_SET+=EXTRAS > OPTIONS_FILE_SET+=LIT > OPTIONS_FILE_SET+=LLD > OPTIONS_FILE_SET+=LLDB > OPTIONS_FILE_SET+=LLD_LINK > OPTIONS_FILE_SET+=OPENMP > OPTIONS_FILE_UNSET+=PYCLANG > OPTIONS_FILE_UNSET+=BE_FREEBSD > OPTIONS_FILE_SET+=BE_NATIVE > OPTIONS_FILE_UNSET+=BE_STANDARD > > (So I normally build less than BE_STANDARD or > BE_FREEBSD would build.) I'm my own worst enemy when it comes to customization. The less changed the better 8-) > We will see if this is enough common context to > replicate the general type of build problem. > (Your details very from one attempt to the next > so an exact match need not be expected, even if > if this does also fail.) > If you replicate the problem I'll be very pleased. And just slightly relieved. My suspcions still center around things I might have done to corrupt /usr/local/poudriere. That leaves me wondering how to proceed after world, kernel and ports are updated. Delete /usr/local/poudriere (which would toss the packages created so far), delete only the jail (not sure if that'll delete existing packages library) or something more selective that I don't know about? The Pi3B is purely experimental, but I'd rather not throw away usable progress given the extreme slowness of that progress. Thank you! bob prohaska
Re: llvm10 build failure on Rpi3
On 2021-Jun-25, at 20:52, bob prohaska wrote: > On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote: > [huge snip, hope the quotes are still correct] >>> So I'm going to suggest using an official kernel build >>> as built by the ci.freebsd.org systems, one that is not >>> GENERIC-MMCCAM. In: >>> > > World and kernel are updating now to -current as of yesterday. > I'll replace GENERIC-MMCCAM with GENERIC for simplicity. I still strongly recommend doing some testing of official builds instead of your personal builds. That includes kernel and world, if possible. Until an official build shows the problem, you are not as likely to get the problem worked on. (And, so far, you have the only known context for getting the problem.) >>> >>> I gather that no RPi4B is available to move the media >>> to? (Having more RAM but being able to force much of >>> it to be ignored can be handy as a test environment >>> for this kind of context.) >>> > > It's still patiently chewing away at www/chromium single-threaded. Note that system-clang just got updates for stable/11 stable/12 stable/13 and main for a defect that prevents building www/chromium with a clang that has assertions enabled (a form of debug build contribution): The branch main has been updated by dim: URL: https://cgit.FreeBSD.org/src/commit/?id=e7e517981a6591c79fb49cd8810361b0f3ad5983 commit e7e517981a6591c79fb49cd8810361b0f3ad5983 Author: Dimitry Andric AuthorDate: 2021-06-21 18:46:34 + Commit: Dimitry Andric CommitDate: 2021-06-21 18:48:37 + Fix clang assertion while building recent www/chromium Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): [clang] Don't assert in EmitAggregateCopy on trivial_abi types Fixes PR42961. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D97872 PR: 256721, 255570 Reported by:jbeich MFC after: 3 days --- contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp index 60ea1b2af037..f3ab91559d30 100644 --- a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp +++ b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp @@ -2056,7 +2056,7 @@ void CodeGenFunction::EmitAggregateCopy(LValue Dest, LValue Src, QualType Ty, Record->hasTrivialCopyAssignment() || Record->hasTrivialMoveConstructor() || Record->hasTrivialMoveAssignment() || - Record->isUnion()) && + Record->hasAttr() || Record->isUnion()) && "Trying to aggregate-copy a type without a trivial copy/move " "constructor or assignment operator"); // Ignore empty classes in C++. > My mistake, but best to finish what's started.. Now that how to > use the packages created is known they can be tested. > >> >> So: no warning about being mis-tuned vs. the 1 GiByte of >> used RAM. (I do not know about your context for this.) >> > > My Pi3 does report too much swap. But I remain uncertain about > the practical significance of the warning. I gather the issue > is that a certain amount memory is set aside to "index", for > lack of a better word, the data stored in swap. If there's too > much swap relative to index, not all swap can be used. That > seems not much different than running out of swap. You are having problems that are hard to issolate and are also effectively asserting this warning does not indicate an issue that is contributing. If it were me, I'd be trying to find out if the failure can be reproduced when the FreeBSD test involved classifies that no warning is appropriate. >> All the ports that devel/llvm10 needs are already in place >> for poudriere's use for this experiment. I should have mentioned that I have not added any junk:??? controls. And my building in a releng/13 context means that 0xA5A5A5A5u would not be happening on allocation. Stronger: the build context uses my typical forced MALLOC_PRODUCTION style of build. >> Another point is: >> >> # more /usr/local/etc/poudriere.d/options/devel_llvm10/options >> # This file is auto-generated by 'make config'. >> # Options for llvm10-10.0.1_3 >> _OPTIONS_READ=llvm10-10.0.1_3 >> _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB >> LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD >> OPTIONS_FILE_SET+=BE_AMDGPU >> OPTIONS_FILE_SET+=CLANG >> OPTIONS_FILE_SET+=DOCS >> OPTIONS_FILE_SET+=EXTRAS >> OPTIONS_FILE_SET+=LIT >> OPTIONS_FILE_SET+=LLD >> OPTIONS_FILE_SET+=LLDB >> OPTIONS_FILE_SET+=LLD_LINK >> OPTIONS_FILE_SET+=OPENMP >> OPTIONS_FILE_UNSET+=PYCLANG >> OPTIONS_FILE_UNSET+=BE_FREEBSD >> OPTIONS_FILE_SET+=BE_NATIVE >> OPTIONS_FILE_UNSET+=BE_STANDARD >> >> (So I normally build less than BE_STANDARD or >> BE_FREEBSD would build.) > > I'm my ow
Re: llvm10 build failure on Rpi3
On 2021-Jun-25, at 20:52, bob prohaska wrote: > If you replicate the problem I'll be very pleased. > And just slightly relieved. No luck on the 1st try: [ 28% 1315/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/ lib/Target/AArch64 -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.s rc/lib/Target/AArch64/AArch64.td --write-if-changed -o lib/Target/AArch64/AArch64GenGlobalISel.inc -d lib/Target/AArch64/AArch64GenGlobalISel.inc.d . . . [ 28% 1326/4575] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && /wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen -gen-global-isel -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMDGPUGISel.td --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d Both finished just fine, indicating that the prior file generations were okay. I'll put the options to be like you are using and try again. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
