Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

schrieb FreeBSD User: >> >>> Hello, >> >>> >> >>> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> >> >>> 1.21.0 on CURRENT >> >>> and 14-STABLE, I can't update several ports: >> >&

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am Tue, 9 Apr 2024 17:10:52 +0200 Rainer Hurling schrieb: > Am 09.04.24 um 09:20 schrieb Baptiste Daroussin: > > On Sat 06 Apr 09:23, Rainer Hurling wrote: > >> Am 06.04.24 um 09:05 schrieb FreeBSD User: > >>> Hello, > >>> > >>> afte

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am 09.04.24 um 09:20 schrieb Baptiste Daroussin: On Sat 06 Apr 09:23, Rainer Hurling wrote: Am 06.04.24 um 09:05 schrieb FreeBSD User: Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports: www/apach

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am 06.04.24 um 09:56 schrieb FreeBSD User: Am Sat, 6 Apr 2024 09:23:30 +0200 Rainer Hurling schrieb: Am 06.04.24 um 09:05 schrieb FreeBSD User: Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports:

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

On Sat 06 Apr 09:23, Rainer Hurling wrote: > Am 06.04.24 um 09:05 schrieb FreeBSD User: > > Hello, > > > > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> > > 1.21.0 on CURRENT and > > 14-STABLE, I can't update several ports: >

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

On Sat 06 Apr 09:05, FreeBSD User wrote: > Hello, > > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 > on CURRENT and > 14-STABLE, I can't update several ports: > > www/apache24 > databases/redis > > pkg core dumps while

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg-static core dumps on some ports

Am Sat, 6 Apr 2024 09:05:00 +0200 FreeBSD User schrieb: > Hello, > > after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 > on CURRENT and > 14-STABLE, I can't update several ports: > > www/apache24 > databases/redis > > pkg core du

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Am 06.04.24 um 09:05 schrieb FreeBSD User: Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports: www/apache24 databases/redis pkg core dumps while performing installation. apache24 and redis are port

pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

Hello, after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 on CURRENT and 14-STABLE, I can't update several ports: www/apache24 databases/redis pkg core dumps while performing installation. apache24 and redis are ports I realized this misbehaviour on ALL 14-STA

Re: git repo ports issues?

Yuri wrote: > Hi Jamie, > > > This was a faulty script where 2023 wasn't changed to 2024. > > Thanks for the notice. Ahh, ok, I did think it was probably a bit more than coincidence that it was exactly 1 year to the day! Cheers for the quick reply, Jamie

Re: The ports quarterly tree 2023Q4 is borked for www/firefox

/show_bug.cgi?id=275814 Should be fixed by: https://cgit.freebsd.org/ports/commit/?h=2023Q4=ec15ee20bdd912ca31982b1be0062da5fb783ac7 -Dimitry awesome ! we have liftoff once again : hydra# hydra# poudriere ports -l 2023Q4git+ssh 2023-12-18 12:29:26 /usr/local/poudriere/ports/2023Q4 hydra

Re: The ports quarterly tree 2023Q4 is borked for www/firefox

ug.cgi?id=275814 Should be fixed by: https://cgit.freebsd.org/ports/commit/?h=2023Q4=ec15ee20bdd912ca31982b1be0062da5fb783ac7 -Dimitry

The ports quarterly tree 2023Q4 is borked for www/firefox

I do not know where else to post this. Seems that a bug report about the problem does not mean much : Bug 275814 - www/firefox has the wrong version in the Makefile https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 This issue is pretty clear. This morning I flushed out my ports tree

Re: something magic about the size of a ports tree

On 2023-10-03 12:24, Dag-Erling Smørgrav wrote: Matthias Apitz writes: I have on my poudriere build host a ports tree and wanted to move it to the host where the resulting packages are installed: root@jet:/usr/local/poudriere/ports # du -sh ports20230806 397Mports20230806 root@jet:/usr

Re: something magic about the size of a ports tree

Warner Losh writes: > Do we support any compression on top of that? Has support for > poudriere been added for it? Yes (zstd) and no. DES -- Dag-Erling Smørgrav - d...@freebsd.org

Re: something magic about the size of a ports tree

On Tue, Oct 3, 2023, 10:24 AM Dag-Erling Smørgrav wrote: > Matthias Apitz writes: > > I have on my poudriere build host a ports tree and wanted to move it to > > the host where the resulting packages are installed: > > > > root@jet:/usr/local/poudriere/ports # du

Re: something magic about the size of a ports tree

1400094? >> > > Yes, on jet it is ZFS: > > root@jet:/usr/local/poudriere/ports # mount | grep ports2023 > poudriere/poudriere/ports/ports20230806 on > /usr/local/poudriere/ports/ports20230806 (zfs, local, noatime, nfsv4acls) > > on c720-1400094 it is only plain UFS. >

Re: something magic about the size of a ports tree

With ZFS, you might be using transparent compression. "du -sh" will show you a file's compressed size. But "ls -lh" will show you the logical size. That's probably why the tarball looked so much bigger than the ports tree on the first system. If you do "du -sh" on

Re: something magic about the size of a ports tree

El día martes, octubre 03, 2023 a las 06:14:23p. m. +0200, Olivier Certner escribió: > Hi Matthias, > > Some ZFS dataset with zstd compression on jet, and no compression on > c720-1400094? > Yes, on jet it is ZFS: root@jet:/usr/local/poudriere/ports # mount | grep port

Re: something magic about the size of a ports tree

Matthias Apitz writes: > I have on my poudriere build host a ports tree and wanted to move it to > the host where the resulting packages are installed: > > root@jet:/usr/local/poudriere/ports # du -sh ports20230806 > 397Mports20230806 > root@jet:/usr/local/poudriere/po

Re: something magic about the size of a ports tree

Hi Matthias, Some ZFS dataset with zstd compression on jet, and no compression on c720-1400094? -- Olivier Certner

something magic about the size of a ports tree

I have on my poudriere build host a ports tree and wanted to move it to the host where the resulting packages are installed: root@jet:/usr/local/poudriere/ports # du -sh ports20230806 397Mports20230806 root@jet:/usr/local/poudriere/ports # tar cf p.tar ports20230806 root@jet:/usr/local

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

://git.freebsd.org/ports.git` work for you? (currently it's not working from where I am). Maybe related. Best Michael Today, yes. Sorry for not replying sooner, Gmail sent your 2nd September email to spam. % pwd /tmp % time git clone https://git.freebsd.org/ports.git && rm -r ports

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On Sat, 2 Sep 2023 09:53:38 +0100 Graham Perrin wrote: > Some inspections are extraordinarily time-consuming. Others complete > very quickly, as they should. > > One recent inspection took more than half an hour. > > Anyone else? > Does `git clone https://git.freebsd.org/ports.git` work

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 9/2/23, Graham Perrin wrote: > On 02/09/2023 10:17, Mateusz Guzik wrote: >> On 9/2/23, Graham Perrin wrote: >>> Some inspections are extraordinarily time-consuming. Others complete >>> very quickly, as they should. >>> >>> One recent inspection took more than half an hour. >>> >>> Anyone

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 02.09.2023 09:32, Graham Perrin wrote: On 02/09/2023 10:17, Mateusz Guzik wrote: get a flamegraph with dtrace https://github.com/brendangregg/FlameGraph See for a PDF of a reply that probably did not reach the list. Graham,

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 02/09/2023 10:17, Mateusz Guzik wrote: On 9/2/23, Graham Perrin wrote: Some inspections are extraordinarily time-consuming. Others complete very quickly, as they should. One recent inspection took more than half an hour. Anyone else? A screenshot: % pkg

Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 9/2/23, Graham Perrin wrote: > Some inspections are extraordinarily time-consuming. Others complete > very quickly, as they should. > > One recent inspection took more than half an hour. > > Anyone else? > > A screenshot: > > % pkg iinfo poudriere-devel >

kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

Some inspections are extraordinarily time-consuming. Others complete very quickly, as they should. One recent inspection took more than half an hour. Anyone else? A screenshot: % pkg iinfo poudriere-devel poudriere-devel-3.3.99.20220831 % uname -aKU FreeBSD

Re: ports-mgmt/portconf – not src.conf(5) – to specify multiple flavours of a port for buildkernel purposes

, rocks with laughter at innumerable warnings, cancels, … make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5393: warning: duplicate script for target "sumo" ignored make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using previous script for "sumo"

ports-mgmt/portconf – not src.conf(5) – to specify multiple flavours of a port for buildkernel purposes

No manual entry for ports.conf % apropos ports.conf apropos: nothing appropriate % rg -i -e 'ports\.conf' /usr/doc/website/content/en % rg -i -e 'ports\.conf' /usr/doc/documentation/content/en % – and so on. As far as I can tell, it's not documented in the usual places. Eventually, Google helped

Re: OpenSSL 3 ports fallout

Gleb Popov wrote on Date: Sun, 13 Aug 2023 20:30:48 UTC : > Some of the ports I'm using are failing to build after OpenSSL 3 > import due to the following problem. OpenSSL headers that are shipped > in base contain declarations of various deprecated functions for which > libcrypt

OpenSSL 3 ports fallout

Some of the ports I'm using are failing to build after OpenSSL 3 import due to the following problem. OpenSSL headers that are shipped in base contain declarations of various deprecated functions for which libcrypto.so doesn't contain definitions. Some of them are RSA_generate_key and ERR_* family

CURRENT with ZFS not bootable when built with LLVM from ports

Building -CURRENT (2023-07-17 be4c7f273508) without system compiler (with LLVM16 from ports) results in unbootable system:Preloaded elf kernel "/boot/kernel/kernel" at 0x82328000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0x82329090. Preloaded boot_

Re: Problem compiling py-* ports

bsd and al > py-* ports fail with the following message.sincerelyFilippo > > FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6 > main-n261981-63b113af5706: Tue Apr  4 16:57:47 CEST 2023 > filippo@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 > > you are on a zfs commit wi

Re: Problem compiling py-* ports

On 4/18/23, Filippo Moretti wrote: > Good morning, I run this versione of Frrebsd and al > py-* ports fail with the following message.sincerelyFilippo > > FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6 > main-n261981-63b113af5706: Tue Apr 4 16:57:47 CEST

Re: Problem compiling py-* ports

After following the instructions provided I get the following:==>>> All >> py39-pygments-2.14.0 (1/9) ===>  Building for py39-pygments-2.15.0 /usr/local/bin/python3.9: No module named build *** Error code 1 Stop. make: stopped in /usr/ports/textproc/py-pygments ===>

Re: Problem compiling py-* ports

fected > hosts with dependent software is not the best solution. Depending on your situation, it might or might not be faster than trying to identify the exact offending files and just removing them ;) -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee) --

Re: Problem compiling py-* ports

> On 18 Apr 2023, at 11:12, Filippo Moretti wrote: > > Good morning, >I run this versione of Frrebsd and al py-* ports fail > with the following message. > sincerely > Filippo Maybe this helps: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269545#c6

Re: Problem compiling py-* ports

W dniu 18.04.2023 o 10:46, Felix Palmen pisze: * Filippo Moretti [20230418 08:12]:   File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 31, in     if isinstance(ob, importlib_metadata.MetadataPathFinder) AttributeError: module 'importlib_metadata' has no attribute

Re: Problem compiling py-* ports

d then do a rebuild. You can avoid this class of issues using poudriere btw... -- Felix Palmen {private} fe...@palmen-it.de -- ports committer (mentee) --{web} http://palmen-it.de {pgp public key} http://palmen-it.de/pub.txt {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC

Problem compiling py-* ports

Good morning,   I run this versione of Frrebsd and al py-* ports fail with the following message.sincerelyFilippo FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n261981-63b113af5706: Tue Apr  4 16:57:47 CEST 2023 filippo@STING:/usr/obj/usr/src/amd64.amd64/sys

Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem report on freebsd-ports?)

s happening. Is this just happening to me? It > > >> appears that the ZFS code has been updated recently, and I'm wondering > > >> whether a regression has crept in. [Or it could just be my hardware?] > > > > > > > > > https://lists.freebsd.org

Re: Unusual errors on recent stable/13 22-Dec-2022 (a related problem report on freebsd-ports?)

; whether a regression has crept in. [Or it could just be my hardware?] > > > > > > https://lists.freebsd.org/archives/freebsd-ports/2022-December/003153.html > > > > indicates a problem with tmpfs use such that using USE_TMPFS=no > > avoids a problem for poudrie

Re: Has anyone tried to build QEMU from ports lately?

On 10/11/22 04:20, Dennis Clarke wrote: On 10/10/22 17:53, Warner Losh wrote: On Mon, Oct 10, 2022 at 10:56 AM Warner Losh wrote: I know what's causing this problem. I'll resolve. tl/dr: _pv_entry.h depends on sys/param.h being included before its use. https://reviews.freebsd.org/D36927

Re: Has anyone tried to build QEMU from ports lately?

can't find '/boot/entropy' Using DTB provided by EFI at 0x87efb000. Kernel entry at 0xf680002e... Kernel args: (null) ---<>--- GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2022 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1

Re: Has anyone tried to build QEMU from ports lately?

-user_signal.c.o >> FAILED: libqemu-arm-bsd-user.fa.p/bsd-user_signal.c.o >> cc -m64 -mcx16 -Ilibqemu-arm-bsd-user.fa.p -I. -I.. -Itarget/arm >> -I../target/arm -I../common-user/host/x86_64 -I../bsd-user/include >> -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-use

Re: Has anyone tried to build QEMU from ports lately?

6_64 -I../bsd-user/include > -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 > -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui > -Iui/shader -I/usr/local/include/capstone > -I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165e

Has anyone tried to build QEMU from ports lately?

/host/x86_64 -I../bsd-user/include -Ibsd-user/freebsd -I../bsd-user/freebsd -I../bsd-user/host/x86_64 -Ibsd-user -I../bsd-user -I../bsd-user/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/capstone -I/usr/ports/emulators/qemu-devel/work/qemu-09ed077d7fae5f825e18ff9a2004dcdd1b165edb -I

Re: Header symbols that shouldn't be visible to ports?

On 7 Sep 2022, at 15:55, Cy Schubert wrote: > > This is exactly what happened with DMD D. When 64-bit statfs was introduced > all DMD D compiled programs failed to run and recompiling didn't help. The > DMD upstream failed to understand the problem. Eventually the port had to > be removed.

Re: Header symbols that shouldn't be visible to ports?

leases won't run correctly on newer ones. Would it > > > > make sense to guard these symbols so they can't be used by programs in > > > > the ports tree? There is some precedent for that, for example > > > > _WANT_SOCKET and _WANT_MNTOPTNAMES. > > > _WANT_S

Re: Header symbols that shouldn't be visible to ports?

utilities in the base system like ps and ifconfig, but aren't > > > stable across major releases. Since they aren't stable, utilities > > > built for older releases won't run correctly on newer ones. Would it > > > make sense to guard these symbols so they can't be use

Re: Header symbols that shouldn't be visible to ports?

t of symbols that are used by > >> > > > critical utilities in the base system like ps and ifconfig, but > >> > > > aren't > >> > > > stable across major releases. Since they aren't stable, utilities > >> > > > built for older rele

Re: Header symbols that shouldn't be visible to ports?

gt; > > stable across major releases. Since they aren't stable, utilities >> > > > built for older releases won't run correctly on newer ones. Would it >> > > > make sense to guard these symbols so they can't be used by programs in >> > > >

Re: Header symbols that shouldn't be visible to ports?

releases won't run correctly on newer ones. Would it > > > > make sense to guard these symbols so they can't be used by programs > in > > > > the ports tree? There is some precedent for that, for example > > > > _WANT_SOCKET and _WANT_MNTOPTNAMES. > > &

Re: Header symbols that shouldn't be visible to ports?

by > > > critical utilities in the base system like ps and ifconfig, but aren't > > > stable across major releases. Since they aren't stable, utilities > > > built for older releases won't run correctly on newer ones. Would it > > > make sense to guard these sy

Re: Header symbols that shouldn't be visible to ports?

er releases won't run correctly on newer ones. Would it > > > > make sense to guard these symbols so they can't be used by programs in > > > > the ports tree? There is some precedent for that, for example > > > > _WANT_SOCKET and _WANT_MNTOPTNAMES. > > &

Re: Header symbols that shouldn't be visible to ports?

by > > > critical utilities in the base system like ps and ifconfig, but aren't > > > stable across major releases. Since they aren't stable, utilities > > > built for older releases won't run correctly on newer ones. Would it > > > make sense to guard these sy

Re: Header symbols that shouldn't be visible to ports?

> stable across major releases. Since they aren't stable, utilities > > built for older releases won't run correctly on newer ones. Would it > > make sense to guard these symbols so they can't be used by programs in > > the ports tree? There is some precedent for that, for exam

Re: Header symbols that shouldn't be visible to ports?

der releases won't run correctly on newer ones. Would it > make sense to guard these symbols so they can't be used by programs in > the ports tree? There is some precedent for that, for example > _WANT_SOCKET and _WANT_MNTOPTNAMES. _WANT_SOCKET is clearly about exposing parts of t

Header symbols that shouldn't be visible to ports?

these symbols so they can't be used by programs in the ports tree? There is some precedent for that, for example _WANT_SOCKET and _WANT_MNTOPTNAMES. I'm particular, I'm thinking about symbols like the following: MINCORE_SUPER TDF_* PRI_MAX* PRI_MIN* PI_*, PRIBIO, PVFS, etc IFCAP_* RLIM_NLIMITS IFF_

Re: MegaCLI port is ports-only -- how would you deploy it?

er. I've heard they are changing for their next controller that would require new tools and driver. In a few months I might have a machine with one to play with. | In the mean time, since the system that I'm testing this on is one of | the dayjob's console servers, and we still want to be able to ru

Re: MegaCLI port is ports-only -- how would you deploy it?

On Tue, Aug 16, 2022 at 11:58:40AM -0600, Warner Losh wrote: |On Tue, Aug 16, 2022 at 11:40 AM Ed Maste <[1]ema...@freebsd.org> |wrote: | | On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko | <[2]ambri...@ambrisko.com> wrote: | > | > | > I'd have to put in -current first then

Re: MegaCLI port is ports-only -- how would you deploy it?

On Tue, Aug 16, 2022 at 11:40 AM Ed Maste wrote: > On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko wrote: > > | > | > I'd have to put in -current first then look at MFC later on. If > looks > > | > | > good for you then I'll put it up for review. I just don't use > this > > | > | > stuff day to

Re: MegaCLI port is ports-only -- how would you deploy it?

On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko wrote: > | > | > I'd have to put in -current first then look at MFC later on. If looks > | > | > good for you then I'll put it up for review. I just don't use this > | > | > stuff day to day anymore. I think it would be good to put this into review,

Re: MegaCLI port is ports-only -- how would you deploy it?

ney" : | > | > | > | > | Hey there all, | > | > | > | > | At the dayjob we have a fleet of Dell Poweredge servers that can use | > | > | > | > | either mptsas or mrsas -- if you use mptsas, you use mptutil (in | > | > | > | > | base) to

ASAN world in chroot tree, ports built previously, variable results finding /usr/local/lib/*.so* files

libc.so.7 => /lib/libc.so.7 (0x803d98000) Note that both libintl.so.8 and libintl.so.8 were found, as expected. (wget and git both run just fine as well.) It is the same /usr/local/ file system, used from the two contexts (mounted into the chroot trees). It appears that lots of ports fr

Re: Problem compiling ports

ndling like BE_AMDGPU for it. > > Building with BE_STANDARD just for this would be a pain for some users. > > > > (CC'ing freebsd-ports ML.) > > > > > > On Tue, 30 Nov 2021 17:45:30 + > > Brooks Davis wrote: > > > > > In the config for devel/

Re: Problem compiling ports

Yeah, I've got this in progress. -- Brooks On Wed, Dec 01, 2021 at 06:57:56AM +0900, Tomoaki AOKI wrote: > It would be better making new special handling like BE_AMDGPU for it. > Building with BE_STANDARD just for this would be a pain for some users. > > (CC'ing free

Re: Problem compiling ports

It would be better making new special handling like BE_AMDGPU for it. Building with BE_STANDARD just for this would be a pain for some users. (CC'ing freebsd-ports ML.) On Tue, 30 Nov 2021 17:45:30 + Brooks Davis wrote: > In the config for devel/llvm11, is BE_STANDARD enab

Re: Problem compiling ports

m32-unknown-wasi"' > 1 error generated. > gmake[3]: *** [Makefile:380: > /usr/ports/devel/wasi-libc/work/wasi-libc-ad5133410f66b93a2381db5b542aad5e0964db96/build/dlmalloc/src/dlmalloc.o] > Error 1 > error: unable to create target: 'No available targets are compatible with >

Problem compiling ports

error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-wasi"' 1 error generated. gmake[3]: *** [Makefile:380: /usr/ports/devel/wasi-libc/work/wasi-libc-ad5133410f66b93a2381db5b542aad5e0964db96/build/dlmalloc/src/dlmalloc.o] Error 1 err

Re: git: "overlay" of own remote-branch on official freebsd-ports repo

t here. > > > > Im quite new to git, so apologizes for any inconvenience reading my > > question. > > > > Using poudriere on 14-CURRENT to create a selection of packages also > > includes updating > > the ports tree on a regular basis. I maintain some &

Re: git: "overlay" of own remote-branch on official freebsd-ports repo

gt; please be so kind and refer to it. Any advice is welcome. > > If you only want to add extra ports, I'd recommend maintaining a > separate repo for use with the ports collection's under-documented > overlay feature. This avoids the need to rebase or merge your trees. > &

Re: git: "overlay" of own remote-branch on official freebsd-ports repo

f you only want to add extra ports, I'd recommend maintaining a separate repo for use with the ports collection's under-documented overlay feature. This avoids the need to rebase or merge your trees. You create the overlay in poudriere with something like: poudriere ports -c -p cheri-ports-ov

Re: git: "overlay" of own remote-branch on official freebsd-ports repo

* Warner Losh [20211012 10:01]: > tl;dr: branches are cheap and well supported in git. You just make a branch > for your > local changes, and update that however you see fit. > > For ports I have like that, I've just created a branch in git. I rebase the > branch forward &g

Re: git: "overlay" of own remote-branch on official freebsd-ports repo

g my > question. > > Using poudriere on 14-CURRENT to create a selection of packages also > includes updating > the ports tree on a regular basis. I maintain some "special" ports not > official part of > the FreeBSD ports tree and some other ports are part of those I

git: "overlay" of own remote-branch on official freebsd-ports repo

also includes updating the ports tree on a regular basis. I maintain some "special" ports not official part of the FreeBSD ports tree and some other ports are part of those I'm supposed to maintain. I keep personally track of the changes in a git repo of my own. Now I'd like t

Re: FreeBSD base pkg (packaging) and critical ports build alongside

of synchronisation with our poudriere packaging builders, that is especially true for critical ports with kernel modules, like i915 drm, virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources and probably the API changes more rapidly than those of the appropriate builder

Re: FreeBSD base pkg (packaging) and critical ports build alongside

an existing source tree. > - If there are kernel changes, install the packages on the package > builder and reboot. > - Poudriere bulk in the new jail to build the new package set. > > Note: You can *normally* skip the second step (drm ports, for example, > will be built against

Re: FreeBSD base pkg (packaging) and critical ports build alongside

, install the packages on the package builder and reboot. - Poudriere bulk in the new jail to build the new package set. Note: You can *normally* skip the second step (drm ports, for example, will be built against the new kernel sources in the jail, though they might not be loadable on the host

Re: FreeBSD base pkg (packaging) and critical ports build alongside

rom most recent 13-STABLE sources, > are often oit of synchronisation with our poudriere packaging builders, that > is > especially true for critical ports with kernel modules, like i915 drm, > virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources > and

FreeBSD base pkg (packaging) and critical ports build alongside

packaging builders, that is especially true for critical ports with kernel modules, like i915 drm, virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources and probably the API changes more rapidly than those of the appropriate builder hosts for poudriere and since it takes a bunch

"ahci0: AHCI v1.30 with 6 6Gbps ports" while only 2 of those are SATA3

That is on somewhat older Supermicro X9DRI-LN4F+ board: ahci0: port 0x9050-0x9057,0x9040-0x9043,0x9030-0x9037,0x9020-0x9023,0x9000-0x901f mem 0xdfa21000-0xdfa217ff irq 18 at device 31.2 numa-domain 0 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported and then I

Re: Build of some ports hang up on recent 14-CURRENT amd64

From: Yasuhiro Kimura Subject: Re: Build of some ports hang up on recent 14-CURRENT amd64 Date: Sat, 10 Apr 2021 06:30:22 +0900 (JST) > From: Michael Butler via freebsd-current > Subject: Re: Build of some ports hang up on recent 14-CURRENT amd64 > Date: Fri, 9 Apr 2021 17:20

Re: Build of some ports hang up on recent 14-CURRENT amd64

From: Michael Butler via freebsd-current Subject: Re: Build of some ports hang up on recent 14-CURRENT amd64 Date: Fri, 9 Apr 2021 17:20:44 -0400 > This is likely fixed as of ~30 mins ago on commit > e8b9c508b7ae5be618ada089103468c400e465cd > > The cause appears to have

Re: Build of some ports hang up on recent 14-CURRENT amd64

14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n245912-f2400e6e832: Sat Apr 10 01:42:33 JST 2021 ro...@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 After the update from 36d6e65722e to f2400e6e832 I noticed build of some ports hang up in the middle

Build of some ports hang up on recent 14-CURRENT amd64

36d6e65722e to f2400e6e832 I noticed build of some ports hang up in the middle of it on my 14-CURRENT amd64 host. One of such examples is security/py-cryptography. -- root@rolling-vm-freebsd1[1008]# make ===> License APACH

Re: On 14-CURRENT: no ports options anymore?

On 3/13/21 12:58 PM, Guido Falsi via freebsd-current wrote: On 13/03/21 20:17, Hartmann, O. wrote: Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to set options via "make config" or via poudriere accordingly. I always get "===> Options unchanged" (when options has

Re: On 14-CURRENT: no ports options anymore?

uot;make config" or via poudriere accordingly. I always get >> > >>> "===> Options >> > >>> unchanged" (when options has been already set and I'd expect a dialog >> > >>> menu). >> > >>> This misbehaviour

Re: On 14-CURRENT: no ports options anymore?

t; >>> unchanged" (when options has been already set and I'd expect a dialog > > >>> menu). > > >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is > > >>> at FreeBSD > > >>> 14.0-CURRENT #49 main-n245

Re: On 14-CURRENT: no ports options anymore?

If this isn’t at least in /usr/ports/UPDATING it sure should be. -Dan > On Mar 13, 2021, at 12:58 PM, Guido Falsi via freebsd-ports > wrote: > > On 13/03/21 20:17, Hartmann, O. wrote: >> Since I moved on to 14-CURRENT, I face a very strange behaviour when trying >&g

Re: On 14-CURRENT: no ports options anymore?

test? Anyway, more on topic, it seems that if one is on -CURRENT (or possibly -STABLE), you’re building from source, and should be expected to read UPDATING. That much is on the site. (But that would be /usr/src, not /usr/ports). Did this happen mid-line in a stable? That…shouldn’t. -Dan &g

Re: On 14-CURRENT: no ports options anymore?

I have same problem days ago when dialog4ports crashed. just reinstall/install ports-mgmt/dialog4ports/ Hartmann, O. escreveu no dia sábado, 13/03/2021 à(s) 19:17: > Since I moved on to 14-CURRENT, I face a very strange behaviour when > trying to set > options via "make

Re: On 14-CURRENT: no ports options anymore?

On Sat, Mar 13, 2021 at 2:51 PM Dan Mahoney (Ports) wrote: > If this isn’t at least in /usr/ports/UPDATING it sure should be. > > -Dan > Ditto! While it did not take me long to discover that the ncurses shareable had bumped the version, I wasted a lot of time rebuilding port

Re: On 14-CURRENT: no ports options anymore?

3-STABLE, 12-STABLE, 12.2-RELENG. > >>> > >>> How to fix this? What happened? > >> > >> Hi Oliver, > >> > >> please check your TERM setting and test with a trivial setting > >> if it is not one of xterm, vt100 or vt320 (for example).

Re: On 14-CURRENT: no ports options anymore?

On 13/03/21 20:17, Hartmann, O. wrote: Since I moved on to 14-CURRENT, I face a very strange behaviour when trying to set options via "make config" or via poudriere accordingly. I always get "===> Options unchanged" (when options has been already set and I'd expect a dialog menu). This

Re: On 14-CURRENT: no ports options anymore?

> Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,for me too Thank youFilippo On Saturday, March 13, 2021, 9:13:46 PM GMT+1, Michael Butler via freebsd-current wrote: On 3/13/21 3:00 PM, Hartmann, O. wrote: > On Sat, 13 Mar 2021 19:52:47 + (UTC) > Filipp

Re: On 14-CURRENT: no ports options anymore?

with a trivial setting if it is not one of xterm, vt100 or vt320 (for example). I had this problem when my TERM variable was xterm-color, which used to be supported but apparently no longer is. Regards, STefan [...] on one of the hosts (non-X11), loged in via ssh, the settings are: # echo $TERM xterm cd

Re: On 14-CURRENT: no ports options anymore?

supported but apparently no longer is. > > Regards, STefan [...] on one of the hosts (non-X11), loged in via ssh, the settings are: # echo $TERM xterm cd /usr/ports/www/apache24 make config ===> Options unchanged (no menu popping up) pgpXNgfVCDPYU.pgp Description: OpenPGP digital signature

  1   2   3   4   5   6   7   8   9   10   >