Hello!
Thanks for explanation and commit links. I will update my src next days, so
actual build error will be go away.
Cheers!
Tomoaki AOKI escreveu (domingo, 27/07/2025 à(s)
12:27):
> On Sun, 27 Jul 2025 11:51:28 +0100
> Nuno Teixeira wrote:
>
> > Hello,
> >
> > I
t;= kva_layout.dmap_low && va < kva_layout.dmap_high)
| ^
2 errors generated.
```
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Hello,
I did some work on 3.3. It builds ok.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288467
Cheers,
Chris escreveu (sexta, 25/07/2025 à(s) 00:13):
> On 2025-07-24 11:28, Nuno Teixeira wrote:
> > Hello,
> >
> > 3.3 branch means devel branch and upstream have rel
_SITELIBDIR}/wx/__init__.py
+
# Set _WX_SHVER_comp_ver to 0 and _WX_FILE_comp_ver for libs appropriately.
# Set _WX_DEPTYPE_comp_ver for "python" to "run", and others to "lib".
Cheers,
Chris escreveu (quinta, 24/07/2025 à(s) 16:33):
> On 2025-07-23 12:37, Nuno
as it can be coinstalled with wx30/wx32 ports i see no reason why
> not
> to add and use wx33 port for software that requires it.
>
> Cheers,
> Max
>
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
are welcome,
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
e branches...
Please take a look at:
https://github.com/aardappel/treesheets/issues/1064#issuecomment-3106748619
At this point, treesheets will be in stale status and I don't know what to
do:
add wx 3.3 port or deprecate treesheets...
Any hints are welcome,
Thanks,
--
Nuno Teixeira
FreeBS
Hello,
Thanks for PR link.
Cheers
Vincent Miller escreveu (segunda, 7/07/2025 à(s)
17:23):
> See https://github.com/freebsd/poudriere/pull/1228 for prospective patch
>
> On Mon, Jul 7, 2025 at 6:21 AM Nuno Teixeira wrote:
>
>> Hello,
>>
>> On 14.3R jail poudrie
repository.
[00:00:31] Checking packages for incremental rebuild needs
```
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
it is correct to follow
https://cgit.freebsd.org/ports/commit/?id=aa1da009b4081b25bb162b0c4177e872ca0b81a3
to fix it.
Thanks!
Baptiste Daroussin escreveu (quarta, 12/03/2025 à(s)
15:02):
>
>
> 12 mars 2025 à 16:01 "Nuno Teixeira" >
> a écrit:
>
>
> This is expec
Hello David,
Thanks. I've missed it on @current list and I following it now.
Cheers.
David Wolfskill escreveu (sábado, 31/05/2025 à(s)
12:00):
> On Sat, May 31, 2025 at 11:43:30AM +0100, Nuno Teixeira wrote:
> > Hello,
> >
> > After updating from main 2025051
Hello,
The port lang/julia expired because it depends on security/mbedtls2. The
> first thing would be to check if it can support security/mbedtls3.
https://github.com/JuliaLang/julia/pull/56708 shows that they moved from
mbedtls to openssl.
Cheers,
--
Nuno Teixeira
FreeBSD UNIX:
y unusable because the ports tree do
> not
> provide a 32bit version of libX11.so.6.
Adding NO_SHLIB_REQUIRES_GLOB=* to x11/nvidia-driver/Makefile solves the
issue.
Should danfe@ be CCed to be in touch with this issues?
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
that I see. go* and llvm* are OK.
Thanks,
Nuno Teixeira escreveu (quarta, 26/02/2025 à(s)
08:31):
> Same with pkg-2.0.99.5 and poudriere-devel-3.4.99.20250209:
>
> > testport 2 times on net/speedtest-go
>
> [00:00:06] [01] [00:00:00] Inspecting ports-mgmt/pkg-devel | pkg-2
:32
Building devel/llvm19@default | llvm19-19.1.7: missed shlib PORTREVISION
chase
Guido Falsi escreveu (quinta, 13/02/2025 à(s) 07:18):
>
>
> On 11/02/25 21:53, Nuno Teixeira wrote:
> > (...)
> >
> > pkg 2.0.6 doesn't solve issue with go:
> >
> > test
this to upstream.
Thanks,
Dag-Erling Smørgrav escreveu (quarta, 11/12/2024 à(s)
09:37):
> Nuno Teixeira writes:
> > I'm trying to find why there is no /etc/localtime in poudriere jails
> > and I need to create manually a symlink for some R-cran tests inside
> > inter
(...)
MAKE_ENV+= LC_ALL=C.UTF-8
OK
MAKE_ENV+= LC_ALL=C
FAIL
Nuno Teixeira escreveu (quinta, 13/02/2025 à(s)
18:50):
> Hello,
>
> Just tested OK:
>
> +MAKE_ENV+= LC_ALL=C.UTF-8
>
> As you are suspecting that LC_ALL is affecting tests, you can now test
> with ot
skipped).
> > I changed the command in cran.mk to '/bin/sh /root/test.sh' - the test
> fails
> > (as in github issue)!
> >
> > Do you have any idea why fails with ports framework and how can fix it?
> >
> > Thanks,
> > Zsolt
> >
> > [1] https://github.com/r-lib/sessioninfo/issues/111
> > [2] https://cgit.freebsd.org/ports/tree/Mk/Uses/cran.mk#n39
> >
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Maybe we can open a go PR demonstrating this results and a link to
https://github.com/freebsd/poudriere/pull/1204
Maybe go team understand the problem?
Cheers
Guido Falsi escreveu (quinta, 13/02/2025 à(s) 07:18):
>
>
> On 11/02/25 21:53, Nuno Teixeira wrote:
> > (...)
&g
] [01] [00:00:00] Warning: go121-1.21.13_1 will be rebuilt as it
misses libc.so.6:32
[00:00:03] [01] [00:00:00] Building lang/go121 | go121-1.21.13_1: missed
shlib PORTREVISION chase
Nuno Teixeira escreveu (segunda, 10/02/2025 à(s)
07:59):
>
> poudriere-devel-3.4.99.20250209 main
>>
> poudriere-devel-3.4.99.20250209 main
>
> Using bulk on *existing* repo it loops on both go121 and 123 and also
> nvidia.
> Repeat process and same.
>
> Since that repo was build *without* PKG_NO_VERSION_FOR_DEPS=yes, I cleaned
> (pkgclean -A) it and I'm building it from scratch at the moment.
> W
On Fri 31 Jan 19:13, Baptiste Daroussin wrote:
> >>>>> On Fri 31 Jan 18:18, Guido Falsi wrote:
> >>>>>> On 27/01/25 10:56, Nuno Teixeira wrote:
> >>>>>>> Hello Rainer,
> >>>>>>>
> >>>>>>>
ged the command in cran.mk to '/bin/sh /root/test.sh' - the test
> fails
> (as in github issue)!
>
> Do you have any idea why fails with ports framework and how can fix it?
>
> Thanks,
> Zsolt
>
> [1] https://github.com/r-lib/sessioninfo/issues/111
> [2] https://cgit.freebsd.org/ports/tree/Mk/Uses/cran.mk#n39
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
piler/outputs/xml/__pycache__
> > extra:
> >
> usr/local/lib/python3.11/site-packages/blueprintcompiler/outputs/__pycache__
> > extra:
> usr/local/lib/python3.11/site-packages/blueprintcompiler/__pycache__
> > extra:
> >
> usr/local/lib/python3.11/site-packages/blueprintcompiler/language/__pycache__
> > =>> Cleaning up wrkdir
> >
> > https://github.com/nxjosephofficial/flare-ports
> >
> > Best regards,
> >
> > Yusuf.
> >
>
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
ing distinfo.
>
> Regards
>
> John
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Hello Mark!
Note: I do not know why, but aarch64 does not get MULTILIB to
> also span armv7 (aarch32). So aarch64 might not have this
> problem being visible as stands.
I confirm that aarch64 doesn't have this problem.
main-n275011-dbedcc169f70
poudriere-devel
PKG_NO_VERSION_FOR_DEPS=yes
`pkg
lla/show_bug.cgi?id=284445
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
Found a good PR that might address this issue:
www/webkit2-gtk3: certain webpages the browser shows a blank page (Cannot
create EGL window surface)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229491
Nuno Teixeira escreveu (segunda, 27/01/2025 à(s)
18:22):
> Hello all,
>
&
.
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
6.01.25 um 19:12 schrieb Nuno Teixeira:
> > I've got same pkg issue like yours.
> >
> > My case is happening with poudriere builds on llvm19 since I have it
> > default.
> > So, every pkg that depends on it, I'll get a rebuild of llvm19.
> >
> > L
FREEBSD_HOST=https://download.FreeBSD.org
59c59
< USE_TMPFS=yes
---
> USE_TMPFS=no
192c192
< # PARALLEL_JOBS=1
---
> PARALLEL_JOBS=2
226c226
< # ALLOW_MAKE_JOBS=yes
---
> ALLOW_MAKE_JOBS=yes
Cheers,
Nuno Teixeira escreveu (domingo, 26/01/2025 à(s)
21:25):
> I use poudrier
hat poudriere-devel *without* PKG_NO_VERSION_FOR_DEPS=yes in
poudriere.conf solves this issue.
Again I use this option for some months without problems until now.
See also:
https://forums.freebsd.org/threads/poudriere-determining-shlib-requirements.94794/
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
ulog.0 => /lib/libulog.so.0
> 7:-lipt.0 => /lib/libipt.so.0
>
> Here, we will take a break for the time being :)
>
> Regards.
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
using poudriere.conf PKG_NO_VERSION_FOR_DEPS=yes to
avoid that rebuilds.
I'm doing test without that option and poudriere is rebuilding everything
again :)
Hope I don't get bad dreams tonite...
Cheers,
Guido Falsi escreveu (domingo, 26/01/2025 à(s) 19:53):
> On 26
(...)
Same after a portrevision bump on llvm19:
[00:00:15] [01] [00:00:00] Warning: llvm19-19.1.7_1 will be rebuilt as it
misses libc++.so.1:32
[00:00:15] [01] [00:00:00] Building devel/llvm19@default |
llvm19-19.1.7_1: missed shlib PORTREVISION chase
:(
Nuno Teixeira escreveu (domingo, 26
Something say to me that it is something wrong with pkg 2.x and I will try
a bump to see what happens like:
https://cgit.freebsd.org/ports/commit/?id=345307cb539e2e81ddc70cd22f85ea34b4fac043
Cheers,
Rainer Hurling escreveu (domingo, 26/01/2025 à(s) 16:51):
> Am 26.01.25 um 16:36 schrieb
(...)
poudriere-devel-3.4.99.20250115
poudriere.conf:
+ PKG_NO_VERSION_FOR_DEPS=yes
EDIT: pkg 2.0.4 doesn't fixed issue
Nuno Teixeira escreveu (domingo, 26/01/2025 à(s)
15:21):
> Ok, I can reproduce this on a new jail:
>
> # cd /usr/src
> # make buildworld-jobs buildkernel-j
E_NATIVE
OPTIONS_FILE_UNSET+=BE_STANDARD
OPTIONS_FILE_UNSET+=MLIR
.endif
DEFAULT_VERSIONS+=llvm=19
--
Thanks,
Nuno Teixeira escreveu (domingo, 26/01/2025 à(s)
12:38):
> (...)
>
> Also I delete all pkg in new jail everytime I upgrade:
>
> > # make buildworld-jobs buildkerne
(...)
Also I delete all pkg in new jail everytime I upgrade:
> # make buildworld-jobs buildkernel-jobs
> # ./tools/build/beinstall.sh
> # reboot
# poudriere pkgclean -A -j 15amd64 -p main
> # poudriere jail -u -j 15amd64
# poudriere bulk -j 15amd64 -p main -f /path/to/list.ports
N
upgrade it?
Dimitry Andric escreveu (domingo, 26/01/2025 à(s) 12:23):
> Does your jail have /usr/lib32/libc++.so.1?
>
> -Dimitry
>
> > On 26 Jan 2025, at 13:18, Nuno Teixeira wrote:
> >
> >
> > As usual everytime I upgrade:
> >
> > # make buil
issed shlib
> PORTREVISION chase
> >
> > It repeats this loop every time I run a testport.
> >
> > Any clues?
>
> Is it looking for the 32-bit version of libc++.so.1? How did you setup
> your jail?
>
> -Dimitry
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
ls -l /lib/libc++*
-r--r--r-- 1 root wheel 1010848 Jan 25 23:40 /lib/libc++.so.1
Nuno Teixeira escreveu (domingo, 26/01/2025 à(s)
11:45):
> (...)
>
> ll /usr/lib/libc++*
> -r--r--r-- 1 root wheel 9389840 Jan 25 23:40 /usr/lib/libc++.a
> -r--r--r-- 1 root wheel
(...)
ll /usr/lib/libc++*
-r--r--r-- 1 root wheel 9389840 Jan 25 23:40 /usr/lib/libc++.a
-r--r--r-- 1 root wheel 48 Aug 22 2023 /usr/lib/libc++.so
-r--r--r-- 1 root wheel 948 Jan 25 23:40 /usr/lib/libc++experimental.a
Why is libc++.so.1 missing?
Nuno Teixeira escreveu (domingo, 26
?
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
should exist to connect all indidual PRs.
With an updated pep517 wiki this will be easier to execute.
Thoughts?
Thanks,
Charlie Li escreveu (quinta, 9/01/2025 à(s) 05:41):
> Nuno Teixeira wrote:
> > Hello all,
> >
> > How is the status of switching from deprecated distutils
eel@${PY_FLAVOR}
Or ${PY_SETUPTOOLS} should be replaced with ?
${PYTHON_PKGNAMEPREFIX}setuptools>0:devel/py-setuptools@${PY_FLAVOR}
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Dag-Erling Smørgrav escreveu (quarta, 11/12/2024 à(s)
09:37):
> Nuno Teixeira writes:
> > I'm trying to find why there is no /etc/localtime in poudriere jails
> > and I need to create manually a symlink for some R-cran tests inside
> > interactive jail.
>
> Thi
ill search "my" r-cran ports for a good canditate example and post it
here.
As I remember almost all tests complains about /etc/localtime symlink ist't
configured correctly, some tests were fixed already upstream.
Cheers,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
ore I open a poudriere pr.
Thanks in advance,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
https://github.com/joncampbell123/dosbox-x/issues/5259
Nuno Teixeira escreveu (domingo, 27/10/2024 à(s)
13:54):
> Hello,
>
> Getting similar results on emulators/dosbox-x:
> ###
> usr/include/c++/v1/string:2861:5: error: implicit instantiation of
> undefined template 'st
| ^
> > 1 error generated.
> >
> > .. which appears to be similar to the issue with devel/poco and fixed
> > in commit c55157301f317ab8166349340d4cc0765deaac12,
>
> FYI, I filed PR282347 with the fix.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282347
>
> Jung-uk Kim
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Hello all,
How can I use a [word] that links to a url in bugzilla?
e.g.:
278921 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278921>
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
time I do it in a
updated poudriere jail, I will use this change only on my ports collection
by using a custom poudriere.d/15amd64-make.conf and leave releases with
default values for ports testing. This way I don't get false results for
port committing.
It will be fun!
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
reduce builds dependency to just one llvm
instead of two: 15 and 17 happening on my ports list build.
Well, as we see, I really need some enlightment in this subject :)
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
My logs on amd64 main, 141, 140 and 133 are fine without errors.
Thanks,
Nuno Teixeira escreveu (domingo, 14/07/2024 à(s)
13:15):
> Hello Xavier,
>
> I'm running duplicity on amd64 main with no problems (backup and checked
> --version).
>
> I don't have ac
> sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper
> name='/usr/ports/sysutils/duplicity/work/stage/usr/local/lib/python3.11/site-packages/duplicity-3.0.0.dist-info/RECORD'
>
> mode='r' encoding='utf-8'>
>
> =
>
> Should I report upstream ?
>
> Regards,
>
> Xavier
>
> --
> Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Engineer
> https://www.amdh.fr
>
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
tter idiot-proof programs, and the universe trying to
> produce bigger and better idiots. So far, the universe is winning." --
> Rich Cook
>
>
>
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
commit 108de784513d87bbe850e7b003a73e26b5b54caa
Author: Val Packett
Date: Fri May 31 08:45:02 2024 -0600
Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME
Nuno Teixeira escreveu (sábado, 1/06/2024 à(s) 09:01):
> Hello all,
>
> Anyone seeing this erro
^
./src/intel/common/xe/intel_gem.c:66:9: note: previous case defined here
66 |case CLOCK_MONOTONIC:
| ^
/usr/include/sys/_clock_id.h:56:26: note: expanded from macro
'CLOCK_MONOTONIC'
56 | #define CLOCK_MONOTONIC 4
| ^
1 error generated.
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
aarch64fbsd
aarch64fbsdb
aarch64haiku
aarch64linux
aarch64linux32
aarch64linux32b
aarch64linuxb
aarch64pe
```
Any clues about "elf_aarch64" and "aarch64elf" mismatch?
Thanks,
Nuno Teixeira escreveu (domingo, 5/05/2024 à(s)
09:57):
> Hello all,
>
ot;
Does devel/binutils should be used to fix that? And how?
Full log:
https://pkg-status.freebsd.org/ampere2/data/main-arm64-default/pb78025a96ed9_s3c1be0b2615/logs/slurm-wlm-23.11.6.log
Thanks in advance,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
ng if a dynamic control could exist to put ports on
TMPFS_BLACKLIST when a limit is reached?
What are your thoughts?
Cheers,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
(...)
If anyone wants to test, I've included patch in commit:
https://cgit.freebsd.org/ports/commit/?id=89e4a1f2c1d1997b8414e2e648c7b4b7c829b63e
Nuno Teixeira escreveu (sexta, 19/04/2024 à(s) 08:29):
> Hello all,
>
> I'm testing a fix for tests on a R port (math/R-cran-Rcpp
bit supported systems?
Upstream are sugesting using OS agnostic check to fix test, so, any better
approach or sugestion is welcome.
Thanks :)
--
Nuno Teixeira
FreeBSD Committer (ports)
hard Froehlich escreveu (quinta, 18/04/2024 à(s)
12:35):
> On Wed, 17 Apr 2024 09:24:52 +0200 *Nuno Teixeira
> >* wrote ---
>
> Hello all,
>
> multimedia/webcamd port and upstream is unmaintained and I'm looking for
> similar programs but at same time worried about
Hello all,
multimedia/webcamd port and upstream is unmaintained and I'm looking for
similar programs but at same time worried about the future of webcamd.
Any help on this matter?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hello Einer,
Thanks for waiting and nice that you joined
https://reviews.freebsd.org/D44592 .
Hope that this week we get all R ports on tree.
Cheers,
Einar Bjarni Halldórsson escreveu (terça, 19/03/2024 à(s)
13:20):
>
> > On 19 Mar 2024, at 12:41, Nuno Teixeira wrote:
> >
t; changes went in, along with
> the updated dependencies.
>
> Should I attempt to revert the changes and update the diff again, or is there
> another simple way to just revert
> last changes?
>
> .einar
--
Nuno Teixeira
FreeBSD Committer (ports)
Ok, I'll commit it.
There's a missing dependency that needs to be added to fix build.
You should have received an e-mail from review.
Cheers
Einar Bjarni Halldórsson escreveu (terça, 19/03/2024
à(s) 10:54):
>
>
> > On 19 Mar 2024, at 10:49, Nuno Teixeira wr
y in R ports.
Cheers,
Einar Bjarni Halldórsson escreveu (terça, 19/03/2024
à(s) 08:41):
>
> Hi Nuno,
>
> > On 19 Mar 2024, at 08:14, Nuno Teixeira wrote:
> >
> > I'm ready to test ports.
> > Just to organize myself, which ones are the three primary ports?
&g
(...)
D44074 is ready to commit.
I will start from there.
Nuno Teixeira escreveu (terça, 19/03/2024 à(s) 08:14):
>
> Hello,
>
> I'm ready to test ports.
> Just to organize myself, which ones are the three primary ports?
>
> @Gleb Popov could you join review a
QLITE than is in ports, I have another PR about updating
> it.
>
> The two PR:
> - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277715
> - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277716
>
> The two diffs in review:
> - https://reviews.freebsd.org/D43735
> -
default options in the past because I was
concerned about it affects testports.
But, I need to give it a go, because build times are impressive.
Thanks!
--
Nuno Teixeira
FreeBSD Committer (ports)
Really nice!
I will wait until it gets added to tree to try it out.
Cheers,
Hubert Tournier escreveu (domingo,
3/03/2024 à(s) 11:48):
>
> Le 03/03/2024 à 09:22, Nuno Teixeira a écrit :
>
> Is there plans to add it to our ports tree?
> Seems that we don't have PNU deps porte
(with a possible Denial of Service risk, should a file
> system be saturated!).
>
> If there's another simpler way, I would be happy to know about it.
>
> Best regards,
>
> Hubert
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
):
>
>
> > On 24 Feb 2024, at 06:24, Einar Bjarni Halldórsson wrote:
> >
> >> On 22 Feb 2024, at 11:43, Nuno Teixeira wrote:
> >>
> >> I did take a look at review and noticed that TEST_DEPENDS are not used
> >> and that could means that test target wor
evision on our Phabricator.
> >>
> > Thanks. I created a revision in Phabricator for all the ports. We’ll see
> > how it goes. If needed, I can chop it up into multiple revisions.
> >
> > .einar
> >
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
equest??
>
> 276735 – multimedia/plexmediaserver-plexpass: Update to 1.400.7775
> (freebsd.org)
>
> Thank you,
>
> Ben Shertenlieb
> Port Maintainer
--
Nuno Teixeira
FreeBSD Committer (ports)
NSGIF_OK'?
101 | if (code != GIF_OK) {
| ^~
| NSGIF_OK
I will see if lib have some kind of compability with old version and
if not I will disable this port option and put it as broken.
Moin Rahman escreveu (sábado, 17/02/2024 à(s) 08:46):
>
&
.. In that case, consumers should change to support it.
Cheers,
Moin Rahman escreveu (sábado, 17/02/2024 à(s) 08:11):
>
>
>
> > On Feb 17, 2024, at 9:08 AM, Nuno Teixeira wrote:
> >
> > Hello all,
> >
> > I'm facing a build error causes from graph
~~~
1 error generated.
While I'm looking from upstream recomendation on fix, how do I quick fix it?
Is it possible to rename libnsgif.h -> nsgif.h in source code?
Also googling about this issue didn't get results since most img pkgs
do not have this lib default on.
Thanks,
--
Nun
à(s) 09:49):
>
> On 14/02/24 10:38, Nuno Teixeira wrote:
> > Is there any clues why I have it running ok on amd64 and not on aarch64?
> > Both running 15 with couple days diff.
>
> This is strange, but it could have to do with some other port having
> been updated or n
Is there any clues why I have it running ok on amd64 and not on aarch64?
Both running 15 with couple days diff.
Stefan Ehmann escreveu (terça, 13/02/2024 à(s) 21:42):
>
> On Tuesday, February 13, 2024 9:58:54 PM CET Guido Falsi wrote:
> > On 13/02/24 15:23, Nuno Teixeira wrote:
>
ig/rules.mk:541:
libnssckbi.so] Error 1
Same error on 15-CURRENT.
Logs:
https://people.freebsd.org/~eduardo/logs/firefox/LTO/15amd64_firefox-123.0_1%2C2.log
https://people.freebsd.org/~eduardo/logs/firefox/LTO/140amd64_firefox-123.0_1%2C2.log
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
Hello!
I've e-mailed upstream about it and this is getting interesting.
I will paste complete reply here.
##
Hello Nuno,
Nuno Teixeira wrote:
> I'm about to maintain Zutils FreeBSD port (
> https://www.freshports.org/archivers/zutils/ ) and I'm dealing with
> conf
STALL= gzip # bin/zcat bin/zcmp bin/zdiff bin/zgrep
man/man1/ztest.1.gz
and
2- ZFS ztest
What's your opinion to introduce this change?
Cheers,
Tomoaki AOKI escreveu (quinta, 1/02/2024 à(s)
14:05):
> On Thu, 1 Feb 2024 13:06:15 +
> Nuno Teixeira wrote:
>
> > Hel
(...)
This conversation related to "compiler:c++11-lang" on lang/gcc14-devel
Nuno Teixeira escreveu (quinta, 8/02/2024 à(s) 10:00):
> Ok, let's try other way:
>
> Suppose that port compiles with c++17. Do you need to set
> "compiler:c++17-lang' capabilit
ated? It's essential to figure out the compiler type and version, if
> you need that in a port Makefile!
>
> How are you going to do that otherwise? If you don't set USES=compiler, at
> the least, COMPILER_TYPE and _VERSION aren't even defined...
>
> -Dim
&& __u2)
> END QUOTE
>
> is because C++11 did not have pair constructors being constexpr.
> C++14 (and later) does. Yet lang/gcc14-devel 's Makefile says:
>
> USES= compiler:c++11-lang cpe gmake iconv libtool makeinfo perl5
> tar:xz
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>
--
Nuno Teixeira
FreeBSD Committer (ports)
Hello all,
archivers/ztools shares binary ztest and manual ztest.1 with base ZFS.
Is there a policy to deal with it?
If someone knows a port that shares same issue, please let me know.
/usr/bin/ztest
/usr/share/man/man1/ztest.1.gz
PREFIX/bin/ztest
PREFIX/man/man1/ztest.1.gz
Thanks,
--
Nuno
On Mon, 29 Jan 2024 09:27:02 +
> Nuno Teixeira wrote:
>
> > Hello all!
> >
> > I was updating games/exult-devel and I found that build failed with:
> >
> > ld: error: undefined symbol: pthread_create
> > >>> referenced by LowLevelMidi
d to a upstream change about threading support from C++11...
Using LDFLAGS= -pthread fixed build and it is present in lot of ports.
My question is if upstream could do anything to avoid this LDFLAGS addition.
This is being discussed at https://github.com/exult/exult/issues/436
Any sugestions are
> The ports I'm interested in should have GNU_CONFIGURE=yes kno
Just a doubt:
For ports like:
GNU_CONFIGURE= yes
PLIST_FILES= man/man1/portname.1.gz
Should we wait for Mk changes or use GNU_CONFIGURE_MANPREFIX=
${PREFIX}/share now?
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
:
> Sorry for offtopic: I maintain my own webkit port:
> https://github.com/shamazmazum/freebsd-ports/tree/master/www
>
> Do you know if the patch mentioned there is actually needed for new
> versions?
>
> вс, 24 дек. 2023 г. в 15:29, Nuno Teixeira :
>
>> Hello all,
>&g
Hello all,
I'm working on webkit-gtk port and looking for sugestions on how this
update/flavorize should be.
Any help is welcome at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275914
Thanks!
--
Nuno Teixeira
FreeBSD Committer (ports)
I remember this happening in other ports...
Any tips are welcome.
Thanks,
--
Nuno Teixeira
FreeBSD Committer (ports)
las.iastate.edu/CRAN/%SUBDIR%/ \
https://cran.ma.imperial.ac.uk/%SUBDIR%/ \
https://cran.ism.ac.jp/%SUBDIR%/
.endif
.if !defined(IGNORE_MASTER_SITE_CRAN_ARCHIVE)
MASTER_SITE_CRAN_ARCHIVE+= ${MASTER_SITE_CRAN:S,$,Archive/${PORTNAME}/,}
.endif
###
Any tips of a better logic for this?
Thanks
Hello Jan,
I can confirm that it worked fine :)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274405
Thanks!
Nuno Teixeira escreveu no dia segunda, 27/11/2023
à(s) 12:55:
> Hello Jan,
>
> I'm waiting on 9b214a66ea8788a6da299139decf506a4b4f5ff1 commit to be MFHed
> so I
o dia domingo, 26/11/2023 à(s)
20:29:
> Nuno Teixeira writes:
>
> > Hello,
> >
> > What is the correct way of bumping consumers in quarterly?
> >
> > 1. cherry-pick port update
> > 2. bump portrevision consumers on quarterly directly?
>
> Cherry-pick b
t/?id=03eac77c103b637b316d6a73df7cae01986402cf
Now I'm in doubt how should I commit it to quarterly.
Thanks,
Mathieu Arnold escreveu no dia domingo, 26/11/2023 à(s)
09:19:
> On Thu, Nov 23, 2023 at 11:30:21AM +, Nuno Teixeira wrote:
> > Hello,
> >
> > What is the correct way of bumping co
1 - 100 of 304 matches
Mail list logo
