Hello Baptiste,
I've spoted that net/gitup is suffering same issue for at least 2 weeks:
[00:00:35] [01] [00:00:00] Inspecting net/gitup | gitup-1.0: determining
shlib requirements
[00:00:35] [01] [00:00:00] Building net/gitup | gitup-1.0: missed shlib
PORTREVISION chase
Thinking if it is corr
12 mars 2025 à 16:01 "Nuno Teixeira" mailto:edua...@freebsd.org?to=%22Nuno%20Teixeira%22%20%3Ceduardo%40freebsd.org%3E
> a écrit:
>
> >
> > This is expected, the nvidia-driver is shipping some 32bit library which are
> > linked to an hypothetical libx11.so.6:32, so either use the same trick as
> This is expected, the nvidia-driver is shipping some 32bit library which
> are
> linked to an hypothetical libx11.so.6:32, so either use the same trick as
> the
> one I use with golang and make pkg ignore this libx11.so.6:32 lib or stop
> shipping a binary which will be anyway unusable because th
(...)
pkg-2.0.6 + poudriere-devel-3.4.99.20250209 + ports main 20250312
poudriere bulk x11/nvidia-driver (default options):
Warning: nvidia-driver-550.127.05.1500034 will be rebuilt as it misses
libX11.so.6:32
In my ports collection of about 800 ports, the above "loop" is the only
that I see. go
On Wed 12 Mar 14:23, Nuno Teixeira wrote:
> (...)
>
> pkg-2.0.6 + poudriere-devel-3.4.99.20250209 + ports main 20250312
>
> poudriere bulk x11/nvidia-driver (default options):
> Warning: nvidia-driver-550.127.05.1500034 will be rebuilt as it misses
> libX11.so.6:32
This is expected, the nvidia-d
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.0.99.5:
determining shlib requirements
[00:00:06] [01] [00:00:00] Inspecting lang/go121 | go121-1.21.13_1:
determining shlib requir
On Thu, Feb 13, 2025 at 5:07 PM Baptiste Daroussin wrote:
>
> 32bit version of libx11 which the ports tree will
> never be able to provide
I just recently added the @i386 flavor for devel/epoll-shim. It might
be arguable if FLAVORS are an appropriate mechanism for this, but
anyways it is pretty s
On Thu 13 Feb 13:55, Nuno Teixeira wrote:
> 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
No, I do understand the issue, for nvidia-driver, this is the port that provides
a
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:
> > (...)
> >
> > pkg 2.0.6 doesn't
On 11/02/25 21:53, Nuno Teixeira wrote:
(...)
pkg 2.0.6 doesn't solve issue with go:
testport 2 times on net/speedtest-go
[00:00:03] [01] [00:00:00] Inspecting ports-mgmt/pkg | pkg-2.0.6:
determining shlib requirements
[00:00:03] [01] [00:00:00] Inspecting lang/go121 | go121-1.21.13_1:
de
(...)
pkg 2.0.6 doesn't solve issue with go:
testport 2 times on net/speedtest-go
[00:00:03] [01] [00:00:00] Inspecting ports-mgmt/pkg | pkg-2.0.6:
determining shlib requirements
[00:00:03] [01] [00:00:00] Inspecting lang/go121 | go121-1.21.13_1:
determining shlib requirements
[00:00:03] [01] [0
> 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
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.
When it's ready,
On 02/02/25 09:02, Baptiste Daroussin wrote:
Le 1 février 2025 23:36:12 GMT+01:00, Guido Falsi a écrit :
On 01/02/25 22:56, Baptiste Daroussin wrote:
On Sat 01 Feb 22:40, Baptiste Daroussin wrote:
On Fri 31 Jan 19:13, Baptiste Daroussin wrote:
On Fri 31 Jan 18:18, Guido Falsi wrote:
On 27/0
Le 1 février 2025 23:36:12 GMT+01:00, Guido Falsi a écrit :
>On 01/02/25 22:56, Baptiste Daroussin wrote:
>> On Sat 01 Feb 22:40, Baptiste Daroussin wrote:
>>> 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:
Guido Falsi wrote on
Date: Sat, 01 Feb 2025 22:36:12 UTC :
> On 01/02/25 22:56, Baptiste Daroussin wrote:
> > . . .
>>> 32bits libs, they are actually needed. for reported ports, I think the
>>> PKG_NO_VERSION_FOR_DEPS=yes does not work yet with newer pkg version.
> > And I was wrong about the
On 01/02/25 22:56, Baptiste Daroussin wrote:
On Sat 01 Feb 22:40, Baptiste Daroussin wrote:
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,
> Wouldn't this be the right time to get Bapt@ involved?
On Sat 01 Feb 22:40, Baptiste Daroussin wrote:
> 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,
> > > >
> > > > > Wouldn't this be the right time to get Bapt@ involved? After all, he
>
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,
> > >
> > > > Wouldn't this be the right time to get Bapt@ involved? After all, he
> > > has
> > > > worked intensively on the pkg updates.
>
On Feb 1, 2025, at 07:52, Guido Falsi wrote:
> On 01/02/25 16:24, Mark Millard wrote:
>> On Feb 1, 2025, at 03:04, Nuno Teixeira wrote:
>>> 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
On 01/02/25 16:24, Mark Millard wrote:
On Feb 1, 2025, at 03:04, Nuno Teixeira wrote:
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
On Feb 1, 2025, at 03:04, Nuno Teixeira wrote:
> 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.
This suggests the
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
Guido Falsi wrote on
Date: Fri, 31 Jan 2025 21:04:20 UTC :
> On 31/01/25 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,
> >>>
> >>> > Wouldn't this be the right time to get Bapt@ involved? After all, h
On 31/01/25 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,
> Wouldn't this be the right time to get Bapt@ involved? After all, he has
> worked intensively on the pkg updates.
Yes it is. I'm CC'ing bapt@.
Sin
On Fri 31 Jan 18:18, Guido Falsi wrote:
> On 27/01/25 10:56, Nuno Teixeira wrote:
> > Hello Rainer,
> >
> > > Wouldn't this be the right time to get Bapt@ involved? After all, he has
> > > worked intensively on the pkg updates.
> >
> > Yes it is. I'm CC'ing bapt@.
>
> Since this issue was pest
On 27/01/25 10:56, Nuno Teixeira wrote:
Hello Rainer,
> Wouldn't this be the right time to get Bapt@ involved? After all, he has
> worked intensively on the pkg updates.
Yes it is. I'm CC'ing bapt@.
Since this issue was pestering me while testing multiple ports with
unnecessarily lengthy r
Hello Rainer,
> Wouldn't this be the right time to get Bapt@ involved? After all, he has
> worked intensively on the pkg updates.
Yes it is. I'm CC'ing bapt@.
Resuming on how to reproduce:
--
# cd /usr/src
# make buildworld-jobs buildkernel-jobs
# poudriere jail -c -j 15amd64 -m src=/usr/src
# p
Am 26.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.
Later on I will try to bump llvm19 portrevision and thus be the hacker
(...)
For the next days I will start using a poudriere.conf with minimal diff to
.sample so it may be easier for future debug.
In my case, its simple as:
$ diff poudriere.conf.sample poudriere.conf
< #ZPOOL=zroot
---
> ZPOOL=zroot
30c30
< FREEBSD_HOST=_PROTO_://_CHANGE_THIS_
---
> FREEBSD_HOST=
>
> I use poudriere-devel and some time ago, me and other people "complaint"
> about so much rust rebuilds because of curl dependency.
> In that time, we start using poudriere.conf PKG_NO_VERSION_FOR_DEPS=yes to
> avoid that rebuilds.
>
I can confirm that poudriere-devel *without* PKG_NO_VERSION_F
So something happened since tomorrow that breaks this?
Do you have a fix in mind?
Thanks,
Tatsuki Makino escreveu (domingo, 26/01/2025
à(s) 20:39):
> Hello.
>
> My environment is that :), but I have llvm19 installed, so I will write
> about what I did a little research.
>
> In llvm19, a file t
Hello.
My environment is that :), but I have llvm19 installed, so I will write about
what I did a little research.
In llvm19, a file that seems to have 32-bit libc++ linked.
The command looks like this.
find /usr/local/ -exec sh -c 'readelf -d -- ${1} 2> /dev/null | grep -e
libc++\\.so\\.1' a
I'm building and rebuilding llvm19 since morning... Now I'm feeling less
stressed by knowing that more people get to it.
I use poudriere-devel and some time ago, me and other people "complaint"
about so much rust rebuilds because of curl dependency.
In that time, we start using poudriere.conf PKG_
On 26/01/25 20:33, Nuno Teixeira wrote:
(...)
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
(...)
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/0
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.
Later on I will try to bump llvm19 portrevision and thus be the hacker of
year is by this it is solved :)
Something sa
Am 26.01.25 um 16:36 schrieb Nuno Teixeira:
(...)
poudriere-devel-3.4.99.20250115
poudriere.conf:
+ PKG_NO_VERSION_FOR_DEPS=yes
EDIT: pkg 2.0.4 doesn't fixed issue
Hmm. Maybe it's because of pkg, which was recently updated to 2.x?
On my box, outside of Poudriere, I've been getting missing l
(...)
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-jobs
> # poudriere
Ok, I can reproduce this on a new jail:
# cd /usr/src
# make buildworld-jobs buildkernel-jobs
# poudriere jail -c -j 15amd64_newjail -m src=/usr/src
# poudriere testport -j 15amd64_newjail -p main games/rocksndiamonds
repeat testport command:
# Warning: llvm19-19.1.7 will be rebuilt as it misses
(...)
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
Nuno Teixeira
% doas poudriere jail -s -j 15amd64 -p main
% doas jexec 15amd64-main
# ls -l /usr/lib32/libc++.so.1
-r--r--r-- 1 root wheel 957764 Jan 25 23:50 /usr/lib32/libc++.so.1
(My rolled BE is Jan 11 and somehow inside jail is showing Jan 25)
Should I try delete jail and install a new one instead of upg
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 buildworld-jobs buildkernel-jobs
> # ./tools/build/beinstall.sh
> # reboot
>
> # poudriere jail -u -j 15amd64
>
> # poudriere jail -l
> JAILNA
As usual everytime I upgrade:
# make buildworld-jobs buildkernel-jobs
# ./tools/build/beinstall.sh
# reboot
# poudriere jail -u -j 15amd64
# poudriere jail -l
JAILNAME VERSION OSVERSION ARCH METHOD TIMESTAMP
PATH
134amd64 13.4-RELEASE-p2 1304000 amd64 http
On 26 Jan 2025, at 12:41, Nuno Teixeira wrote:
>
> Got this loop on:
>
> main-n275036-faa845aab611
> poudriere jail is same version
>
> Warning: llvm19-19.1.7 will be rebuilt as it misses libc++.so.1:32
> Building devel/llvm19@default | llvm19-19.1.7: missed shlib PORTREVISION
> chase
>
> I
(...)
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 48 Aug 22 2023 /usr
(...)
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/
47 matches
Mail list logo
