Solved security/libsecret

daeron

daeron

Has anyone successfully built 0.21.7
If anyone has any suggestions, for example does anyone know if it builds successfully if the old version is deleted first?

Code: 
===>  Building for libsecret-0.21.7_1
[ 20% 2/5] valac -C --pkg gio-2.0 --pkg glib-2.0 --pkg gio-unix-2.0 --pkg gio-2.0 --target-glib 2.44 --pkg glib-2.0 --color=never --directory libsecret/test-vala-lang.p --basedir ../libsecret libsecret/libsecret-1.vapi libsecret/mock-service-0.vapi ../libsecret/test-vala-lang.vala
FAILED: libsecret/test-vala-lang.p/test-vala-lang.c
valac -C --pkg gio-2.0 --pkg glib-2.0 --pkg gio-unix-2.0 --pkg gio-2.0 --target-glib 2.44 --pkg glib-2.0 --color=never --directory libsecret/test-vala-lang.p --basedir ../libsecret libsecret/libsecret-1.vapi libsecret/mock-service-0.vapi ../libsecret/test-vala-lang.vala
../libsecret/test-vala-lang.vala:22.18-22.43: error: `Secret.attributes_validate' is not available in libsecret-1 0.20.5. Use libsecret-1 >= 0.21.2
   22 |     bool valid = Secret.attributes_validate (schema, attributes);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~                     
Compilation failed: 1 error(s), 0 warning(s)
[ 40% 2/5] cc -Ilibsecret/test-vala-unstable.p -Ilibsecret -I../libsecret -I. -I.. -I/usr/ports/security/libsecret/work/libsecret-0.21.7/libsecret -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/gio-unix-2.0 -fdiagnostics-color=never -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -DHAVE_CMSGCRED -pthread -DSECRET_COMPILATION '-DSRCDIR="/usr/ports/security/libsecret/work/libsecret-0.21.7"' -DSECRET_WITH_UNSTABLE -DSECRET_API_SUBJECT_TO_CHANGE -MD -MQ libsecret/test-vala-unstable.p/meson-generated_test-vala-unstable.c.o -MF libsecret/test-vala-unstable.p/meson-generated_test-vala-unstable.c.o.d -o libsecret/test-vala-unstable.p/meson-generated_test-vala-unstable.c.o -c libsecret/test-vala-unstable.p/test-vala-unstable.c
ninja: build stopped: subcommand failed.
===> 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/libsecret
 
cy@ said:
Probably. It may be building using headers in /usr/local/include (from the previous version).
Click to expand...
So deinstalling it first and building/installing help for bare-metal environment?

If so, UPDATING should have an entry for it, as it requires "unusual" procedure.

Note that poudriere builds succeeded with it.
 
Yep, deleting the port first works. Probably should have included an UPDATING note for it, hopefully this thread's easy enough for others to find.
 
T-Aoki said:
So deinstalling it first and building/installing help for bare-metal environment?
Click to expand...

Bare metal servers has nothing to do with whether a port builds or not. This would be a problem for virtual machines and jails as well if the software was already previously installed.

T-Aoki said:
If so, UPDATING should have an entry for it, as it requires "unusual" procedure.
Click to expand...

There are too many ports that have dysfunctional builds. And not the port themselves but the upstream makefiles. They should code their Makefiles to search for headers in the current directory before /usr/local/include or /usr/include.

T-Aoki said:
Note that poudriere builds succeeded with it.
Click to expand...
Of course it does. The old version isn't installed in the jail. This is why we use poudriere. Back in the old days building ports from source would fail for poorly written upstream makefiles. Blame the upstream for that.

I suppose the porter could virtually rewrite the upstream makefiles (with a huge patch), but is it worth it now that we have poudriere?

My recommendation is that people should use the FreeBSD package repo as much as possible.
 
I cannot recommend poudriere to everybody, especially users that has SSD only. After started using poudriere, nvmecontrol logpage -p 2 nvme0 shows me significant increases in Data units written.

To recommend poudriere to everyone who builds ports locally, poudriere needs to be far minimalistic for rebuilds of dependents (I mean anything depends upon updated ports) and __FreeBSD_version (which affects OSVERSION) bumps. I think least 2 digits should be ignored by default and let each ports that need to be aware of handle it.
 
You must log in or register to reply here.
Back
Top