devel/sope: make (stage-qa) now fails with DEVELOPER=yes complaining about iconv dependency

Bump

Can someone please confirm if they can reproduce on their ports tree.

Post by Euan Thoms
I'm the maintainer of devel/sope2 (required for www/sogo2).
Upon updating the port for an upstream version increment, I now get an error running "make" when DEVELOPER=yes is set in /etc/make.conf. The upstream project is in maintainence so I'm almost certain there's no changes in the upstream source requiring new dependencies. Especially not to do with iconv.
It does NOT help if I add USES+=iconv to the Makefile.
I will continue to submit the ports update patches, since I use things like "make check-plist" and "portlint -AC" always. I suspect it may fail in poudriere though.
gmake[2]: Leaving directory '/usr/ports/devel/sope2/work/SOPE'
====> Compressing man pages (compress-man)
===> Installing ldconfig configuration file
====> Running Q/A tests (stage-qa)
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it is not declared as a dependency
Warning: you need USES+=iconv
- With an updated port tree cd to /usr/ports/deve/sope2
- Add DEVELOPER=yes to /etc/make.conf
- Run "make" command
--
Regards, Euan Thoms
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-ports

--
Regards, Euan Thoms

Walter Schwarzenfeld

2016-07-14 17:02:11 UTC

I can confirm. I got
Running Q/A tests (stage-qa)
Error:
/usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is
linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it
is not declared as a dependency
Warning: you need USES+=iconv
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libssl.so.38 from security/libressl but it
is not declared as a dependency
Warning: you need USES=ssl
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but
it is not declared as a dependency
Warning: you need USES=ssl

In the past this statements were only warnings. Now they appears as errors.
I see it in more than one port. Last I saw similar errors in
rubygem-passenger.

Euan Thoms

2016-07-14 17:09:19 UTC

Post by Walter Schwarzenfeld
I can confirm. I got
Running Q/A tests (stage-qa)
/usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is
linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it
is not declared as a dependency
Warning: you need USES+=iconv
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libssl.so.38 from security/libressl but it
is not declared as a dependency
Warning: you need USES=ssl
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but
it is not declared as a dependency
Warning: you need USES=ssl
In the past this statements were only warnings. Now they appears as errors.
I see it in more than one port. Last I saw similar errors in
rubygem-passenger.

Thanks for confirming.

--
Regards, Euan Thoms

Walter Schwarzenfeld

2016-07-14 17:11:08 UTC

I think this statements should be only warnings. Cause not all of these
statements are right and each maintianer should decide which "USES" or
"LIB_DEPENDS" are necessairely and which not.

mokhi

2016-07-14 20:12:49 UTC

Maybe it's off topic.
But AFAIK there's also an issue about sope3 port, when MySQL57 is installed.

in brief it's:
"
# make install
...
gmake[4]: Leaving directory '/usr/ports/devel/sope3/work/SOPE/sope-ldap/NGLdap'
gmake[3]: Leaving directory '/usr/ports/devel/sope3/work/SOPE/sope-ldap'
gmake[2]: Leaving directory '/usr/ports/devel/sope3/work/SOPE'
====> Compressing man pages (compress-man)
===> Installing ldconfig configuration file
===> Installing for sope3-3.0.2
===> Checking if sope3 already installed
===> Registering installation for sope3-3.0.2
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/MySQL:
No such file or directory
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/Resources/Info-gnustep.plist:
No such file or directory
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/Resources/Version:
No such file or directory
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/stamp.make:
No such file or directory
*** Error code 74
"

Regards, Mokhi.

Euan Thoms

2016-07-14 21:24:08 UTC

Post by mokhi
Maybe it's off topic.
But AFAIK there's also an issue about sope3 port, when MySQL57 is installed.
"
# make install
...
gmake[4]: Leaving directory '/usr/ports/devel/sope3/work/SOPE/sope-ldap/NGLdap'
gmake[3]: Leaving directory '/usr/ports/devel/sope3/work/SOPE/sope-ldap'
gmake[2]: Leaving directory '/usr/ports/devel/sope3/work/SOPE'
====> Compressing man pages (compress-man)
===> Installing ldconfig configuration file
===> Installing for sope3-3.0.2
===> Checking if sope3 already installed
===> Registering installation for sope3-3.0.2
pkg-static: Unable to access file
No such file or directory
pkg-static: Unable to access file
No such file or directory
pkg-static: Unable to access file
No such file or directory
pkg-static: Unable to access file
No such file or directory
*** Error code 74

I'll look into this as soon as I can.

I did not make the v3 port initially. Someone else forked my v2 port and I asked for the maintainership back. I do run v3 in production (just for testing) alongside v2 (which I use daily). But I use postgresql. So I never even tested the mysql option. I assumed the person that made the v3 port did that, perhaps not.

--
Regards, Euan Thoms

Euan Thoms

2016-07-14 21:29:33 UTC

Post by Walter Schwarzenfeld
I think this statements should be only warnings. Cause not all of these
statements are right and each maintianer should decide which "USES" or
"LIB_DEPENDS" are necessairely and which not.

Well, I don't know enough to comment about whether it should be classed as a warning or an error. But there's definetely a bug in the ports Mk system, since adding USES+=iconv does not remove the error. I don't think I even need iconv as a dependency, it should be included lower down in the dependency tree.

--
Regards, Euan Thoms

mokhi

2016-07-15 06:27:21 UTC

Post by Euan Thoms
I'll look into this as soon as I can

Okay :) thanks
As I'm maintainer of mysql57, someone mailed me logs of that problem,
AFAIK There's no problem for mysql56 but it happens when 57 is found
instead of 56

Thanks and regards, Mokhi.

Martin Waschbüsch

2016-07-15 07:17:09 UTC

I am not sure about this. At the very least, sope-core does use iconv in its NGExtensions (e.g. NSString+Encoding.m).
Can we really assume some lower dependency package already pulls iconv in?

Kubilay Kocak

2016-07-15 07:26:57 UTC

On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld

Post by Walter Schwarzenfeld
I think this statements should be only warnings. Cause not all
of these statements are right and each maintianer should decide
which "USES" or "LIB_DEPENDS" are necessairely and which not.

Well, I don't know enough to comment about whether it should be
classed as a warning or an error. But there's definetely a bug in
the ports Mk system, since adding USES+=iconv does not remove the
error. I don't think I even need iconv as a dependency, it should
be included lower down in the dependency tree.

I am not sure about this. At the very least, sope-core does use iconv
in its NGExtensions (e.g. NSString+Encoding.m). Can we really assume
some lower dependency package already pulls iconv in?

If something in a port links to libiconv (or anything else), then
the dependency should be registered in that port

Walter Schwarzenfeld

2016-07-15 08:37:43 UTC

It is a bug the statement is wrong.
The error message disappiear if you add to LIB_DEPENDS
libiconv.so:converters/libiconv.

Btw.
it says
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libssl.so.38 from security/libressl but it
is not declared as a dependency
Warning: you need USES=ssl
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but
it is not declared as a dependency
Warning: you need USES=ssl

if I add ssl to USES
it states
you may not need USES+=ssl.

I am not happy with the "new" stage-qa messages.

Walter Schwarzenfeld

2016-07-15 08:43:42 UTC

Also there are some ports who had USES=readline and stage-qa states You
have to add USES+=readline.
Here is also the statement wrong.

Walter Schwarzenfeld

2016-07-15 08:57:09 UTC

=> you may not need USES+=ssl.

And this message disappeared if I set USES? ssl:libressl.

This should not needed if I had DEFAULT_VERSIONS=ssl=libressl in /etc/make.conf.
(I think only USES=ssl should be enough).

Walter Schwarzenfeld

2016-07-15 09:02:23 UTC

USES? ssl:libressl

the question mark is a typo, should be
USES= ssl:libressl

Matthew Seaman

2016-07-15 09:27:22 UTC

Post by Walter Schwarzenfeld
It is a bug the statement is wrong.
The error message disappiear if you add to LIB_DEPENDS
libiconv.so:converters/libiconv.
Btw.
it says
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libssl.so.38 from security/libressl but it
is not declared as a dependency
Warning: you need USES=ssl
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but
it is not declared as a dependency
Warning: you need USES=ssl
if I add ssl to USES
it states
you may not need USES+=ssl.
I am not happy with the "new" stage-qa messages.

I agree that this is annoying, and I wish there was some way to tell
stage-qa that the library dependencies are in fact OK.

The problem here is the heuristic used to determine whether there are
any missing library dependencies. This simply uses readelf(1) to find
out what's required by the dynamic loader for all of the binaries
included in the port. If it finds that an application 'foo' requires a
shared library libbar it will tell you 'you need USES+=bar' Much of the
time this is correct, and a handy sanity check.

However, what seems to happen fairly often is that foo only has a direct
dependency on libbaz and libbaz is what links against libbar. foo
doesn't know anything about functions and objects provided by libbar or
use any of them itself, except through the interface provided by libbaz,
so foo's dependency on libbar is entirely indirect.

In this situation I can't see why the port foo should list an explicit
dependency on libbar; the one it inherits through libbaz seems to me to
express the linkage between foo and libbar in an entirely satisfactory way.

You should only get the 'you may not need USES+=foo' message when you've
added the dependency in the ports Makefile, but none of the resulting
binaries link against libfoo. I don't see how you are getting the
results you describe there.

Cheers,

Matthew

Euan Thoms

2016-07-15 15:22:30 UTC

Post by Kubilay Kocak

On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld

Post by Walter Schwarzenfeld
I think this statements should be only warnings. Cause not all
of these statements are right and each maintianer should decide
which "USES" or "LIB_DEPENDS" are necessairely and which not.

Well, I don't know enough to comment about whether it should be
classed as a warning or an error. But there's definetely a bug in
the ports Mk system, since adding USES+=iconv does not remove the
error. I don't think I even need iconv as a dependency, it should
be included lower down in the dependency tree.

I am not sure about this. At the very least, sope-core does use iconv
in its NGExtensions (e.g. NSString+Encoding.m). Can we really assume
some lower dependency package already pulls iconv in?

If something in a port links to libiconv (or anything else), then
the dependency should be registered in that port

OK, thanks guys. I will add libiconv as a LIB_DEPENDS. But I still think there may be a bug. The make error tells me to use USES+=iconv and it doesn't work, I still get the same error about libiconv not being specified as a dependancy.

--
Regards, Euan Thoms

Euan Thoms

2016-07-15 15:32:23 UTC

Post by Walter Schwarzenfeld
Also there are some ports who had USES=readline and stage-qa states You
have to add USES+=readline.
Here is also the statement wrong.

That's interesting. When I said I did add USES+=iconv, actually I just added iconv to the existing USES= declaration. I will try USES+=iconv next time I work on the port.

--
Regards, Euan Thoms

Walter Schwarzenfeld

2016-07-15 16:20:29 UTC

No, that what a missunderstood.

There are some ports have USES=readline in the Makefile.

But the warning "

/You have to add USES+=readline" appears. (the warning uses the "+", but
that was not what I meant)./

Euan Thoms

2016-07-15 22:44:27 UTC

On Friday, July 15, 2016 16:43 SGT, Walter Schwarzenfeld

Post by Walter Schwarzenfeld
Also there are some ports who had USES=readline and stage-qa states
You have to add USES+=readline.
Here is also the statement wrong.

That's interesting. When I said I did add USES+=iconv, actually I just
added iconv to the existing USES= declaration. I will try USES+=iconv
next time I work on the port.

They should be equivalent.

Yes, but should and is are not the same thing.

--
Regards, Euan Thoms

Euan Thoms

2016-07-15 22:55:44 UTC

Post by Kubilay Kocak

On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld

Post by Walter Schwarzenfeld
I think this statements should be only warnings. Cause not all
of these statements are right and each maintianer should decide
which "USES" or "LIB_DEPENDS" are necessairely and which not.

Well, I don't know enough to comment about whether it should be
classed as a warning or an error. But there's definetely a bug in
the ports Mk system, since adding USES+=iconv does not remove the
error. I don't think I even need iconv as a dependency, it should
be included lower down in the dependency tree.

I am not sure about this. At the very least, sope-core does use
iconv in its NGExtensions (e.g. NSString+Encoding.m). Can we really
assume some lower dependency package already pulls iconv in?

If something in a port links to libiconv (or anything else), then
the dependency should be registered in that port

OK, thanks guys. I will add libiconv as a LIB_DEPENDS. But I still
think there may be a bug. The make error tells me to use USES+=iconv
and it doesn't work, I still get the same error about libiconv not
being specified as a dependancy.

It looks like USES=iconv doesn't add the dependency on newer FreeBSD
versions that have basic iconv support in the base system. If you set
USES=iconv:wchar_t or USES=iconv:translit, then it will unconditionally
add the dependency.
If you don't use the WCHAR_T or //TRANSLIT extensions, it may not be
necessary to link with -liconv, but it is possible that the port does
this automatically if it finds that libiconv is installed by another
dependency.

Aha, in that case perhaps ignore my last email. This starts to make more sense now. although the stage-qa error message is misleading.

Is this case, would I not be better adding a LIB_DEPENDS instead of USES=iconv.wchar_t or USES=iconv:translit? I don't even know where to find out which one I need.

A bit off tpic, but personally I prefer to just use the LIB_DEPENDS for a straight dependency. Keeping track of which macros to use can be more difficult than the time they save. I've only been porting for about a year, yet the ports system seems to be going through a lot of changes in this time. All good changes I'm sure. As a user I do find installing and upgrading easier than I did when I strated using ports about 5 years ago.

I'm just about to start working on the port again now.

--
Regards, Euan Thoms

Euan Thoms

2016-07-15 23:13:44 UTC

Post by mokhi

Post by Euan Thoms
I'll look into this as soon as I can

Okay :) thanks
As I'm maintainer of mysql57, someone mailed me logs of that problem,
AFAIK There's no problem for mysql56 but it happens when 57 is found
instead of 56
Thanks and regards, Mokhi.

Now that's interesting. I'm glad you mentioned that, it could save me a lot of time. Coincidentally, just going through my emails, I read a headline for BSD Magazine article about problems with MySQL 5.7 on FreeBSD, Since I still haven't got round to subscribing I can't read the article yet. I am not up on the issue, is there anywhere I can read up on the issue?

--
Regards, Euan Thoms

Euan Thoms

2016-07-16 00:40:01 UTC

Post by mokhi

Post by Euan Thoms
I'll look into this as soon as I can

Okay :) thanks
As I'm maintainer of mysql57, someone mailed me logs of that problem,
AFAIK There's no problem for mysql56 but it happens when 57 is found
instead of 56
Thanks and regards, Mokhi.

Mokhi, a bit off topic but I'm just installing the mysql57-client port and the mysql-boost tarball fails on the first few mirrors, and even when one works (below) it's very slow download. Hard to believe a project like MySQL has such slow mirrors. This server is located in Singapore, but the speeds should not be explained by distance or route.

ftp://ftp.fi.muni.cz/pub/mysql/Downloads/MySQL-5.7/mysql-boost-5.7.13.tar.gz

--
Regards, Euan Thoms

r***@gmail.com

2016-10-27 16:58:02 UTC

Post by mokhi

Post by Euan Thoms
I'll look into this as soon as I can

Okay :) thanks
As I'm maintainer of mysql57, someone mailed me logs of that problem,
AFAIK There's no problem for mysql56 but it happens when 57 is found
instead of 56
Thanks and regards, Mokhi.

Mokhi, a bit off topic but I'm just installing the mysql57-client port and the mysql-boost tarball fails on the first few mirrors, and even when one works (below) it's very slow download. Hard to believe a project like MySQL has such slow mirrors. This server is located in Singapore, but the speeds should not be explained by distance or route.
ftp://ftp.fi.muni.cz/pub/mysql/Downloads/MySQL-5.7/mysql-boost-5.7.13.tar.gz
--
Regards, Euan Thoms
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-ports

For mysql 5.6 I`ve got the error:

optional library not found: mysqlclient

when i debug configure process, i saw the empty variable LOCALBASE in checkLinking procedure fro mysqlclient library check.

I changed patch-configure file for direct write /usr/local instead ${LOCALBASE} and it`s work fine.

Euan Thoms

2016-07-16 01:56:01 UTC

Post by Kubilay Kocak

On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld

Post by Walter Schwarzenfeld
I think this statements should be only warnings. Cause not all
of these statements are right and each maintianer should decide
which "USES" or "LIB_DEPENDS" are necessairely and which not.

Well, I don't know enough to comment about whether it should be
classed as a warning or an error. But there's definetely a bug in
the ports Mk system, since adding USES+=iconv does not remove the
error. I don't think I even need iconv as a dependency, it should
be included lower down in the dependency tree.

I am not sure about this. At the very least, sope-core does use
iconv in its NGExtensions (e.g. NSString+Encoding.m). Can we really
assume some lower dependency package already pulls iconv in?

If something in a port links to libiconv (or anything else), then
the dependency should be registered in that port

OK, thanks guys. I will add libiconv as a LIB_DEPENDS. But I still
think there may be a bug. The make error tells me to use USES+=iconv
and it doesn't work, I still get the same error about libiconv not
being specified as a dependancy.

It seems adding "libiconv.so:converters/libiconv" to LIB_DEPENDS clears all errors and warnings. This is what I will use unless anyone can tell me why it's not recommended.

Thanks everyone involved, for your help.

--
Regards, Euan Thoms

Mathieu Arnold

2016-07-22 08:00:40 UTC

+--On 12 juillet 2016 23:08:52 +0800 Euan Thoms <***@potensol.com> wrote:
| I'm the maintainer of devel/sope2 (required for www/sogo2).
|
| Upon updating the port for an upstream version increment, I now get an
| error running "make" when DEVELOPER=yes is set in /etc/make.conf. The
| upstream project is in maintainence so I'm almost certain there's no
| changes in the upstream source requiring new dependencies. Especially not
| to do with iconv.
|
| It does NOT help if I add USES+=iconv to the Makefile.
|
| I will continue to submit the ports update patches, since I use things
| like "make check-plist" and "portlint -AC" always. I suspect it may fail
| in poudriere though.
|
| Below is the error message after runnning "make":
|
| gmake[2]: Leaving directory '/usr/ports/devel/sope2/work/SOPE'
| ====> Compressing man pages (compress-man)
| ===> Installing ldconfig configuration file
| ====> Running Q/A tests (stage-qa)
| Error:
| /usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is
| linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it is
| not declared as a dependency Warning: you need USES+=iconv

In that case, you will need USES=iconv:port.

--
Mathieu Arnold

Mathieu Arnold

2016-07-22 08:01:59 UTC

+--On 15 juillet 2016 11:02:23 +0200 Walter Schwarzenfeld
<***@utanet.at> wrote:
| USES? ssl:libressl
|
| the question mark is a typo, should be
| USES= ssl:libressl

Yes, because this doesn't mean anything, there is no USES=ssl:libressl, ssl
does not take any argument.

I'll change the ssl.mk file so that it errors out if an argument is there.

--
Mathieu Arnold

Euan Thoms

2016-07-26 02:02:58 UTC