Re: Error build the port devel/glib20

[Guido Falsi]

On 02/08/14 02:20, John Hein wrote:
> Vladislav Prodan wrote at 02:18 +0200 on Feb  8, 2014:
>  > # uname -a
>  > FreeBSD vm-10-1.domain.com 10.0-STABLE FreeBSD 10.0-STABLE #0 r261419: Mon 
> Feb  3 02:57:25 UTC 2014 
> r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>  >
>  > make BATCH=yes MAKE_JOBS_UNSAFE=yes WITH_COLLATION_FIX=yes install -C 
> /usr/ports/devel/glib20
>  >
>  > 
>  > gmake[5]: Entering directory 
> `/usr/ports/devel/glib20/work/glib-2.36.3/glib'
>  >   CC   libglib_2_0_la-gallocator.lo
> ...
>  >   CC   libglib_2_0_la-gconvert.lo
>  > gconvert.c:66:2: error: GNU libiconv not in use but included iconv.h is 
> from libiconv
>  > #error GNU libiconv not in use but included iconv.h is from libiconv
>  >  ^
> 
> See the 20130904 entry in ports/UPDATING

While the entry is relevant commit 341775 changed the situation a bit.

The patch in PR ports/186295 [1] should be helpful in this case.

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/186295

-- 
Guido Falsi 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: WARNING: devel/icu: recent update redners openldap-server and other ports unusable!

[Shane Ambler]

On 08/02/2014 08:24, O. Hartmann wrote:
> 
> Today a couple of updates has been introduced, one of them was an
> update of port devel/icu.
> 
> I the good manner/tradition of updating UPDATING, I expect a
> warning/hint/advice a couple of days from now - when everybody has
> already stepped into the mess.
> 
> On several boxes running 11.0-CURRENT and 9.2-STABLE, updating ports
> including devel/icu renders many ports unusable due to a library
> version bump in libicu.
> 
> After updating ports relying on devel/icu via
> 
> portmaster -r devel/icu
> 
> and the updating of port
> 
> net/openldap24-server
> 
> (which is openldap-sasl-server in my case), OpenLDAP doesn't start
> anymore on all boxes affected by the update of devel/icu!
> 
> I always get the error
> 
> 52f5551f hdb_db_init: Initializing HDB database
> 52f5551f olcDbDirectory: value #0: invalid path: Permission denied
> 52f5551f config error processing olcDatabase={1}hdb,cn=config:
> olcDbDirectory: value #0: invalid path: Permission denied 52f5551f
> send_ldap_result: conn=-1 op=0 p=0 52f5551f slapd destroy: freeing
> system resources. 52f5551f syncinfo_free: rid=001
> 52f5551f slapd stopped.
> 52f5551f connections_destroy: nothing to destroy.
> /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd
> 
> 
> This obscure 
> 
> olcDbDirectory: value #0: invalid path: Permission denied
> 
> is not obvious to me. The server ran minutes ago BEFORE the update, the
> directories containing the DB5 databases have all the correct ownership
> (ldap:ldap, I suspected first a misconfiguration as this error seems
> typical for a misconfiguration of the ownership).
> 
> Does anyone see the same problem? And maybe please would put out some
> notes in UPDATING within a considerable narrow timeframe regarding
> devel/icu! It seems, FreeBSD's ports systems get more and more messy.
> 
> oh
> 

Not the same problem but I did see building postgresql server break -
I changed databases/postgresql92-server/makefile with the following.
Ideally the test for *_52 should be added to configure.in rather than
replacing the oldest.

--- a/databases/postgresql92-server/Makefile
+++ b/databases/postgresql92-server/Makefile
@@ -355,6 +355,8 @@ post-patch:
 .  if defined(SERVER_ONLY) && ${PORT_OPTIONS:MICU}
@${REINPLACE_CMD} -E -e \
"s|^(m4_if.*)2.6[0-9](.*Autoconf version
)2.6[0-9]|\1${AUTOCONF_VERSION}\2${AUTOCONF_VERSION}|g" \
+   -e "s|ucol_open_43|ucol_open_52|g" \
+   -e "s|ucnv_fromUChars_43|ucnv_fromUChars_52|g" \
${WRKSRC}/configure.in
 .  endif


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Lev Serebryakov]

Hello, John.
You wrote 8 февраля 2014 г., 3:39:37:

 And it seems, that most of USE_GCC-equipped ports pull all this development
 toolkit for nothing!
>> DA> Well, some ports can be more or less difficult to get building with
>> DA> clang.  So depending on whether the maintainer(s) wish to choose the way
>> DA> of least resistance, they will sometimes decide to set USE_GCC.
>>   I'm not speaking about BUILD. I'm speaking about RUN. Why do I need 
>> compiler,
>> assembler, linker & Ko to run pre-build software?

JM> dynamically linked libraries.
JM> libcstd++
JM> libgfortran
JM> libquadmath
JM> libssp
JM> libgcc_s
JM> etc,etc
 90% of USE_GCC-ports don't use libgrotran & libquadmath. Many of them
doesn;t use libstdc++. virtualbox-ose-additions DOESN'T USAE ANY OF THESE
LIBRARIES! And I think, it is not unique in this regard!

 And, of course, 99.9% of them doesn't use Java!

JM> Ah, yes it is.  See above.
JM> GCC is built with GAS.  It needs the GAS that it's configured with.
  But all these ports, which uses only libgcc_s and/or libstdc++ don't.

  You try to explain why it is as it is now, from purely formal, technical
 point of view. I know, thank you.

  What It try to say, that now, when we have binary packages (thank you,
 everybody, who make it possible!) and we don't have gcc in base on
 10/CURRENT (and old gcc on older systems), we BADLY NEED way not to pull
 0.5G of dependencies with any package, which was build with gcc!

>> in case of USE_GCC, as libgcc.so + libstdc++.so is a tiiny fraction of 
>> full
>> binutils + gcc package, and on non-developers system there is no need to
>> have 0.5G of toolchain only because some software were build by this
>> tooclahin on our build cluster!
>>  And I have feeling, that right now many cases of USE_GCC=any could be
>> replaced with USE_GCC=any:build and some "magic" to link with
>> libgcc/libstdc++ statically. Without any modularization of packages and
>> pkgng support.

JM> My feeling is that this isn't correct.
 There are "-static-libgcc" and "-static-libstdc++" flags for gcc... What
does they mean? I understand, that it is not for EACH port, but, maybe, for
most of them they are Ok?

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: WARNING: devel/icu: recent update redners openldap-server and other ports unusable!

[O. Hartmann]

On Sat, 08 Feb 2014 18:42:44 +1030
Shane Ambler  wrote:

> On 08/02/2014 08:24, O. Hartmann wrote:
> > 
> > Today a couple of updates has been introduced, one of them was an
> > update of port devel/icu.
> > 
> > I the good manner/tradition of updating UPDATING, I expect a
> > warning/hint/advice a couple of days from now - when everybody has
> > already stepped into the mess.
> > 
> > On several boxes running 11.0-CURRENT and 9.2-STABLE, updating ports
> > including devel/icu renders many ports unusable due to a library
> > version bump in libicu.
> > 
> > After updating ports relying on devel/icu via
> > 
> > portmaster -r devel/icu
> > 
> > and the updating of port
> > 
> > net/openldap24-server
> > 
> > (which is openldap-sasl-server in my case), OpenLDAP doesn't start
> > anymore on all boxes affected by the update of devel/icu!
> > 
> > I always get the error
> > 
> > 52f5551f hdb_db_init: Initializing HDB database
> > 52f5551f olcDbDirectory: value #0: invalid path: Permission denied
> > 52f5551f config error processing olcDatabase={1}hdb,cn=config:
> > olcDbDirectory: value #0: invalid path: Permission denied 52f5551f
> > send_ldap_result: conn=-1 op=0 p=0 52f5551f slapd destroy: freeing
> > system resources. 52f5551f syncinfo_free: rid=001
> > 52f5551f slapd stopped.
> > 52f5551f connections_destroy: nothing to destroy.
> > /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd
> > 
> > 
> > This obscure 
> > 
> > olcDbDirectory: value #0: invalid path: Permission denied
> > 
> > is not obvious to me. The server ran minutes ago BEFORE the update,
> > the directories containing the DB5 databases have all the correct
> > ownership (ldap:ldap, I suspected first a misconfiguration as this
> > error seems typical for a misconfiguration of the ownership).
> > 
> > Does anyone see the same problem? And maybe please would put out
> > some notes in UPDATING within a considerable narrow timeframe
> > regarding devel/icu! It seems, FreeBSD's ports systems get more and
> > more messy.
> > 
> > oh
> > 
> 
> Not the same problem but I did see building postgresql server break -
> I changed databases/postgresql92-server/makefile with the following.
> Ideally the test for *_52 should be added to configure.in rather than
> replacing the oldest.
> 
> --- a/databases/postgresql92-server/Makefile
> +++ b/databases/postgresql92-server/Makefile
> @@ -355,6 +355,8 @@ post-patch:
>  .  if defined(SERVER_ONLY) && ${PORT_OPTIONS:MICU}
> @${REINPLACE_CMD} -E -e \
> "s|^(m4_if.*)2.6[0-9](.*Autoconf version
> )2.6[0-9]|\1${AUTOCONF_VERSION}\2${AUTOCONF_VERSION}|g" \
> +   -e "s|ucol_open_43|ucol_open_52|g" \
> +   -e "s|ucnv_fromUChars_43|ucnv_fromUChars_52|g" \
> ${WRKSRC}/configure.in
>  .  endif

In the openldap case, I checked again. My problem is obviously
triggered by the massive devel/icu updates I had to perform (there is
still no UPDATING entry reflecting this!).

Since last update of net/openldap24-server, a reinstallation of the
port changes(!) the ownership of the directory in which the database
of openldap server resides to root:wheel and it should be ldap:ldap or
be untouched!

after installation, I changed the ownership back to the ldap:ldap
value and the server started as expected again.

I checked the ownership several time and I was quite sure that the
ownership was correct but the OpenLDAP server won't start. After an
explicit setting of the ownership everything worked all right. I try
to reproduce this after I have gone through the devel/icu problem (a lot
of ports dropping out, unwilling to compile on CURRENT now). I try to
reproduce the weird observation or render/falsify my observation
nonsense (regarding the correct setting of ownership and the unwilling
openldap server).

Thanks for responding.

Oliver


signature.asc
Description: PGP signature

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[John Marino]

On 2/8/2014 09:20, Lev Serebryakov wrote:
> Hello, John.
> You wrote 8 февраля 2014 г., 3:39:37:
> 
> And it seems, that most of USE_GCC-equipped ports pull all this 
> development
> toolkit for nothing!
>>> DA> Well, some ports can be more or less difficult to get building with
>>> DA> clang.  So depending on whether the maintainer(s) wish to choose the way
>>> DA> of least resistance, they will sometimes decide to set USE_GCC.
>>>   I'm not speaking about BUILD. I'm speaking about RUN. Why do I need 
>>> compiler,
>>> assembler, linker & Ko to run pre-build software?
> 
> JM> dynamically linked libraries.
> JM> libcstd++
> JM> libgfortran
> JM> libquadmath
> JM> libssp
> JM> libgcc_s
> JM> etc,etc
>  90% of USE_GCC-ports don't use libgrotran & libquadmath. Many of them
> doesn;t use libstdc++. virtualbox-ose-additions DOESN'T USAE ANY OF THESE
> LIBRARIES! And I think, it is not unique in this regard!
> 
>  And, of course, 99.9% of them doesn't use Java!

It doesn't matter, you get everything that is built by default.  And you
need everything by default because sometimes gcc is needed for c++,
sometimes it's needed for fortran, sometimes it's needed for Ada
(gcc-aux), often the package has object files produced by different
languages but needs the same compiler to build them all.

So the only way to reduce unnecessary libraries is turn them off by
default, but that breaks lots of ports so you wouldn't do it.


> JM> Ah, yes it is.  See above.
> JM> GCC is built with GAS.  It needs the GAS that it's configured with.
>   But all these ports, which uses only libgcc_s and/or libstdc++ don't.
> 
>   You try to explain why it is as it is now, from purely formal, technical
>  point of view. I know, thank you.
> 
>   What It try to say, that now, when we have binary packages (thank you,
>  everybody, who make it possible!) and we don't have gcc in base on
>  10/CURRENT (and old gcc on older systems), we BADLY NEED way not to pull
>  0.5G of dependencies with any package, which was build with gcc!

If you have the gcc dynamic libraries, you have the gcc that uses them.
 If you have the gcc that uses them, it has a runtime dependency on the
binutils that built it.  All gcc built on FreeBSD have a dependency on
modern binutils (Not DragonFly though as they have binutils 2.22 and now
2.24 in base).

Unless the packages are purely static the entire gcc setup gets pulled
in.  But you only pay the price once. After that, every package pulling
in gcc is satisfied after the first one is installed.


> 
>>> in case of USE_GCC, as libgcc.so + libstdc++.so is a tiiny fraction of 
>>> full
>>> binutils + gcc package, and on non-developers system there is no need to
>>> have 0.5G of toolchain only because some software were build by this
>>> tooclahin on our build cluster!
>>>  And I have feeling, that right now many cases of USE_GCC=any could be
>>> replaced with USE_GCC=any:build and some "magic" to link with
>>> libgcc/libstdc++ statically. Without any modularization of packages and
>>> pkgng support.
> 
> JM> My feeling is that this isn't correct.
>  There are "-static-libgcc" and "-static-libstdc++" flags for gcc... What
> does they mean? I understand, that it is not for EACH port, but, maybe, for
> most of them they are Ok?

1st, that requires pretty invasive modification of whatever build system
works for that port, on a per-port basis.  Nobody is going to do that
extra work.
secondly, often packages don't build statically, they need dynamic for
some reason, often symbol visibility.

Like I said above, if you don't fix *ALL* of them, there's no point to
working on any of them.  Any port with USE_GCC=yes will pull in
everything anyway, so you'd have to kill them all.

I think most people will agree there are bigger fish to fry.  USE_GCC is
used as a last resort, they will slowly be removed as the packages get
fixed to work on clang (or clang gets better).

John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Lev Serebryakov]

Hello, John.
You wrote 8 февраля 2014 г., 12:32:23:

>> JM> dynamically linked libraries.
>> JM> libcstd++
>> JM> libgfortran
>> JM> libquadmath
>> JM> libssp
>> JM> libgcc_s
>> JM> etc,etc
>>  90% of USE_GCC-ports don't use libgrotran & libquadmath. Many of them
>> doesn;t use libstdc++. virtualbox-ose-additions DOESN'T USAE ANY OF THESE
>> LIBRARIES! And I think, it is not unique in this regard!
>> 
>>  And, of course, 99.9% of them doesn't use Java!

JM> It doesn't matter, you get everything that is built by default.  And you
JM> need everything by default because sometimes gcc is needed for c++,
JM> sometimes it's needed for fortran, sometimes it's needed for Ada
JM> (gcc-aux), often the package has object files produced by different
JM> languages but needs the same compiler to build them all.
 (sigh). I now how it is done now. Again, I try to say, that it should
be changed. For example, gcc port could be split into
gcc/g++/gfrotran/gcc-aux/gcj/runtime ports. 90% of software need gcc and/or
g++. I never used gfortran or gnu ADA and I never-ever hear about projects,
which need specifically gcj, especially when we have native OpenJDK7!

 Look at QT, for example. It is splitted to components.

JM> So the only way to reduce unnecessary libraries is turn them off by
JM> default, but that breaks lots of ports so you wouldn't do it.
 I speak about unnecessary binaries, headers and stuff like that here. Look,

gcc-4.6.4 -  567.0MiB
binutils-2.24 -   49.2MiB
mpfr-3.1.2-1.6MiB
mpc-1.2.0 -0.4MiB
gmp-5.1.3 -2.3MiB

 (all data by "pkg info" output)

 At same time:

 libstdc++.so.6 - 5.5MiB
 libgcc_s.so- 0.4MiB
 libssp.so  - 0.0MiB.

I'm sure, that 90% of USE_GCC ports use only these three libraries. It is
less than 1% of full toolchain size. You think it is Ok?

 Several ports could use libgfortran.so.3 (4.7MiB), libobjc.so.3 (0.5MiB)
 and libquadmath.so.0 (0.7MiB).

 I suspect, we don't have binary package, which needs libgcj.so
libgcj-tools.so (179MiB combined!).

JM> If you have the gcc dynamic libraries, you have the gcc that uses them.
   It is not obvious. Yes, now I have, but these libraries (10MiB) will work
  perfectly well without all other files (600MiB).

JM>  If you have the gcc that uses them, it has a runtime dependency on the
JM> binutils that built it.  All gcc built on FreeBSD have a dependency on
JM> modern binutils (Not DragonFly though as they have binutils 2.22 and now
JM> 2.24 in base).
  See above. virtualbox-ose-additions doesn't need assembler or linker or even
 compiler (ANY compiler) to work. Or any library, for that matter. Many
 ports needs one or two libraries, but not all this madness.

JM> Unless the packages are purely static the entire gcc setup gets pulled
JM> in.
  It is how we do things now, but it is not only way to do it and not better
 way for sure.

JM> Like I said above, if you don't fix *ALL* of them, there's no point to
JM> working on any of them.  Any port with USE_GCC=yes will pull in
JM> everything anyway, so you'd have to kill them all.
 It is perfectionism. May be, if we cover 50% of ports, but 50% which is
used by 95% of non-developing users (and other 50% is rarely used) it is
success.

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Lev Serebryakov]

Hello, John.
You wrote 8 февраля 2014 г., 12:32:23:

JM> It doesn't matter, you get everything that is built by default.  And you
JM> need everything by default because sometimes gcc is needed for c++,
JM> sometimes it's needed for fortran, sometimes it's needed for Ada
JM> (gcc-aux), often the package has object files produced by different
JM> languages but needs the same compiler to build them all.
 And let returns to virtualbox-ose-additions. It installs (I skip ass
scripts and text files, of course:

/boot/modules/vboxguest.ko
/boot/modules/vboxvideo.ko
  These two don't need any libraries, for sure.

/usr/local/bin/VBoxClient
libX11.so.6 => /usr/local/lib/libX11.so.6 (0x8008ab000)
libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x800bdd000)
libXt.so.6 => /usr/local/lib/libXt.so.6 (0x800de5000)
libXext.so.6 => /usr/local/lib/libXext.so.6 (0x801043000)
libXmu.so.6 => /usr/local/lib/libXmu.so.6 (0x801254000)
libthr.so.3 => /lib/libthr.so.3 (0x80146d000)
libc.so.7 => /lib/libc.so.7 (0x801692000)
libxcb.so.2 => /usr/local/lib/libxcb.so.2 (0x801a2b000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x801c49000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x801e4b000)
libpthread-stubs.so.0 => /usr/local/lib/libpthread-stubs.so.0 
(0x80205)
librpcsvc.so.5 => /usr/lib/librpcsvc.so.5 (0x802251000)
libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x80245a000)
libSM.so.6 => /usr/local/lib/libSM.so.6 (0x802662000)
libICE.so.6 => /usr/local/lib/libICE.so.6 (0x802869000)

/usr/local/lib/xorg/modules/drivers/vboxvideo_drv.so
libc.so.7 => /lib/libc.so.7 (0x80081d000)
/usr/local/lib/xorg/modules/input/vboxmouse_drv.so
libc.so.7 => /lib/libc.so.7 (0x80081d000)

/usr/local/sbin/VBoxControl
libthr.so.3 => /lib/libthr.so.3 (0x80088c000)
libc.so.7 => /lib/libc.so.7 (0x800ab1000)

/usr/local/sbin/VBoxService
libthr.so.3 => /lib/libthr.so.3 (0x8008bb000)
libc.so.7 => /lib/libc.so.7 (0x800ae)

  Why does it need runtime gcc dependency AT ALL?!

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
biology/molden  | 5.0.6   | 5.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[John Marino]

On 2/8/2014 10:24, Lev Serebryakov wrote:
> Hello, John.
> You wrote 8 февраля 2014 г., 12:32:23:
> 
>>> JM> dynamically linked libraries.
>>> JM> libcstd++
>>> JM> libgfortran
>>> JM> libquadmath
>>> JM> libssp
>>> JM> libgcc_s
>>> JM> etc,etc
>>>  90% of USE_GCC-ports don't use libgrotran & libquadmath. Many of them
>>> doesn;t use libstdc++. virtualbox-ose-additions DOESN'T USAE ANY OF THESE
>>> LIBRARIES! And I think, it is not unique in this regard!
>>>
>>>  And, of course, 99.9% of them doesn't use Java!
> 
> JM> It doesn't matter, you get everything that is built by default.  And you
> JM> need everything by default because sometimes gcc is needed for c++,
> JM> sometimes it's needed for fortran, sometimes it's needed for Ada
> JM> (gcc-aux), often the package has object files produced by different
> JM> languages but needs the same compiler to build them all.
>  (sigh). I now how it is done now. Again, I try to say, that it should
> be changed. For example, gcc port could be split into
> gcc/g++/gfrotran/gcc-aux/gcj/runtime ports. 90% of software need gcc and/or
> g++. I never used gfortran or gnu ADA and I never-ever hear about projects,
> which need specifically gcj, especially when we have native OpenJDK7!


Your "solution" causes multiple issues for others, and for what benefit?
 The libraries are not packaged individually.  You would need to split
up every GCC package into at least two packages, and then change the
infrastructure to add the compiler as the build dependency and the
libraries as a run dependency.  I do not see the library dependencies
getting whittled down to 5 - 15 separate packages though.  That is way
too much of a maintenance headache.

But the fact that you don't use use specific libraries is irrelevant.
The needs of the entire tree is what is being considered, as well as the
amount of work the maintainers are willing to do.  GCC x 5 is a set of
monster packages that I don't see a bunch of people clamoring to take over.


> JM> Like I said above, if you don't fix *ALL* of them, there's no point to
> JM> working on any of them.  Any port with USE_GCC=yes will pull in
> JM> everything anyway, so you'd have to kill them all.
>  It is perfectionism. May be, if we cover 50% of ports, but 50% which is
> used by 95% of non-developing users (and other 50% is rarely used) it is
> success.

No, it's all or nothing.  And you are asking people to do a tremendous
amount of work to address a personal philosophy.  While I can see value
in splitting out the gcc libraries into separate packages (especially
when subpackages come where one can package libraries separately for
free), I see zero value in reworking vendor makefiles.  I'd never agree
to it myself, nor would I want a non-maintainer making an invasive
change like that.


John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Lev Serebryakov]

Hello, John.
You wrote 8 февраля 2014 г., 13:37:23:

JM> No, it's all or nothing.  And you are asking people to do a tremendous
JM> amount of work to address a personal philosophy.  While I can see value
JM> in splitting out the gcc libraries into separate packages (especially
JM> when subpackages come where one can package libraries separately for
JM> free),
 It is best solution, of course. But what do I think: no pkgng could track,
which shared librearties are REALLY used, maybe, we could add some intelelct
to USE_GCC infrastructure to register runtime dependency (Ok, to full gcc
package till we have subpackages) ONLY if one if ut libraries are REALLY
used? As I've showed in previous message, package which surprises me, has
FAKE gcc dependency!

-- 
// Black Lion AKA Lev Serebryakov 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Matthias Andree]

Individual examples aside, I recollect that one of the selling points
for STAGING, together with pkgNG, was that we would later have the
chance to split up one build into multiple binary packages.

Not sure what other changes to the infrastructure are required
(Mk/bsd.port.mk needs to be taught to build more than one package from
the STAGEDIR), but it's not impossible that we'll see features as Lev
desires, later, as "perhaps in 2015".

And libgcc_s is a dependency you get on practically every port that is
compiled with a newer GCC.

And knowing that we come from source builds, getting binary packages
optimized to the point where most people are happy is still some way to go.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Matthew Seaman]

On 08/02/2014 09:37, John Marino wrote:
> Your "solution" causes multiple issues for others, and for what benefit?
>  The libraries are not packaged individually.  You would need to split
> up every GCC package into at least two packages, and then change the
> infrastructure to add the compiler as the build dependency and the
> libraries as a run dependency.  I do not see the library dependencies
> getting whittled down to 5 - 15 separate packages though.  That is way
> too much of a maintenance headache.
> 
> But the fact that you don't use use specific libraries is irrelevant.
> The needs of the entire tree is what is being considered, as well as the
> amount of work the maintainers are willing to do.  GCC x 5 is a set of
> monster packages that I don't see a bunch of people clamoring to take over.

In fact, this /is/ the plan.  This is exactly the sort of thing we want
to achieve by implementing sub-packages.  However, in the case of
dependencies on compiler toolchains, this shouldn't require massive
interventions in the ports tree.  If we create separate
gcc-c++11-runtime or clang-objc-runtime or whatever other combination
sub-packages, then it should be mostly a case of updating
/usr/ports/Mk/Uses/compiler.mk so that it registers a BUILD_DEPENDS on
the entire toolchain, and a RUN_DEPENDS on just the appropriate runtime
sub-package.

There are various other obvious sub-packaging chunks like separating out
documentation and examples, and various files that are now added to
packages due to options settings.  So it's going to be another sweeping
change across the ports, perhaps not quite so all-encompassing as the
current switch to staging, but similar.  (Staging is actually a
prerequisite to introducing sub-packages; the other requirement is
obsoleting the old pkg_tools, as they can't deal with this.)

Other than getting over the hump of implementing all this, will this
result in a massively increased workload for port maintainers?  It
shouldn't.  Essentially one port will now generate several sub-packages
instead of one package.  This will be automatic: just dividing up the
files from staging into different pkg tarballs according to tags given
in pkg-plist.  Tags which frequently already exist according to
OPTIONS_SUB.  It also means that in a lot of cases we will be compiling
all the different optional parts of a port regularly, so problems with
obscure parts should come to light more quickly.  Also the oft repeated
complaint that lang/php5 doesn't enable mod_php5 by default: that goes away.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[John Marino]

On 2/8/2014 11:26, Matthias Andree wrote:
> Individual examples aside, I recollect that one of the selling points
> for STAGING, together with pkgNG, was that we would later have the
> chance to split up one build into multiple binary packages.
> 
> Not sure what other changes to the infrastructure are required
> (Mk/bsd.port.mk needs to be taught to build more than one package from
> the STAGEDIR), but it's not impossible that we'll see features as Lev
> desires, later, as "perhaps in 2015".
> 
> And libgcc_s is a dependency you get on practically every port that is
> compiled with a newer GCC.

Are you sure this is still true?  Now that FreeBSD supports
dl_iterate_phdr (and has for a few years now), gcc exceptions are
handled through rtld, not libgcc_s.  I suspect that newer FreeBSD
releases have packages without this linked library.  Is there another
reason to see libgcc_s used these days?

John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Matthias Andree]

Am 08.02.2014 11:29, schrieb Matthew Seaman:

> Other than getting over the hump of implementing all this, will this
> result in a massively increased workload for port maintainers?  It
> shouldn't.  Essentially one port will now generate several sub-packages
> instead of one package.  This will be automatic: just dividing up the
> files from staging into different pkg tarballs according to tags given
> in pkg-plist.  Tags which frequently already exist according to
> OPTIONS_SUB.  It also means that in a lot of cases we will be compiling
> all the different optional parts of a port regularly, so problems with
> obscure parts should come to light more quickly.  Also the oft repeated
> complaint that lang/php5 doesn't enable mod_php5 by default: that goes away.

Consider this a proposal: Will we optionally have an alternate way to
mention separate pkg-plist files instead, or just use @package ...
@closepackage markers instead of PLIST-SUB markup?

I think that pkg-plist is already "decorated" beyond recognition for
some ports with possibly three %%PLIST_SUB_TAG%% on one line.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Matthias Andree]

Am 08.02.2014 11:31, schrieb John Marino:
> On 2/8/2014 11:26, Matthias Andree wrote:
>> Individual examples aside, I recollect that one of the selling points
>> for STAGING, together with pkgNG, was that we would later have the
>> chance to split up one build into multiple binary packages.
>>
>> Not sure what other changes to the infrastructure are required
>> (Mk/bsd.port.mk needs to be taught to build more than one package from
>> the STAGEDIR), but it's not impossible that we'll see features as Lev
>> desires, later, as "perhaps in 2015".
>>
>> And libgcc_s is a dependency you get on practically every port that is
>> compiled with a newer GCC.
> 
> Are you sure this is still true?  Now that FreeBSD supports
> dl_iterate_phdr (and has for a few years now), gcc exceptions are
> handled through rtld, not libgcc_s.  I suspect that newer FreeBSD
> releases have packages without this linked library.  Is there another
> reason to see libgcc_s used these days?

Never bothered to check.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USE_GCC politic -- why so many ports has it as runtime dependency?

[Matthew Seaman]

On 08/02/2014 10:33, Matthias Andree wrote:
> Am 08.02.2014 11:29, schrieb Matthew Seaman:
> 
>> Other than getting over the hump of implementing all this, will this
>> result in a massively increased workload for port maintainers?  It
>> shouldn't.  Essentially one port will now generate several sub-packages
>> instead of one package.  This will be automatic: just dividing up the
>> files from staging into different pkg tarballs according to tags given
>> in pkg-plist.  Tags which frequently already exist according to
>> OPTIONS_SUB.  It also means that in a lot of cases we will be compiling
>> all the different optional parts of a port regularly, so problems with
>> obscure parts should come to light more quickly.  Also the oft repeated
>> complaint that lang/php5 doesn't enable mod_php5 by default: that goes away.
> 
> Consider this a proposal: Will we optionally have an alternate way to
> mention separate pkg-plist files instead, or just use @package ...
> @closepackage markers instead of PLIST-SUB markup?
> 
> I think that pkg-plist is already "decorated" beyond recognition for
> some ports with possibly three %%PLIST_SUB_TAG%% on one line.

The code hasn't been written yet.  Anything is possible.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey




signature.asc
Description: OpenPGP digital signature

databases/firebird25-client needs version bump after icu update

[Phil Stone]

Hi,

After devel/icu update to version 5.2, a run was done to chase icu dependencies.
The port databases/firebird25-server was bumped as part of this run.

Howerver, the client port, databases/firebird25-client, was not.
Yet, this client port builds /usr/local/lib/libfbembed, which depends on icu.

When running 'portmaster -a' after a portsnap upgrade, devel/icu and 
databases/firebird25-server are rebuild, but not databases/firebird25-client. 
This actually causes databases/firebird25-server build to fail.

Has anybody encountred a similar experience?
Regards,
Phil
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

avogadro update

[Ajtim]

Hi!

Avogadro 1.1.1_1 update on reeBSD 10.0-RELEASE (amd64) doesn't work:

> Compressing man pages (compress-man)
===>  Installing for avogadro-1.1.1_1
===>  Checking if science/avogadro already installed
===>   Registering installation for avogadro-1.1.1_1
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonerror.h):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythoninterpreter.h):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonscript.h):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/avogadro/1_1/extensions/pythonterminal.so):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/python2.7/site-packages/Avogadro.so):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/wireframe.py):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/example.py):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/):
 No such file or directory
pkg-static: 
lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/): No 
such file or directory
*** Error code 74

Stop.
make[1]: stopped in /usr/ports/science/avogadro
*** Error code 1

Stop.
make: stopped in /usr/ports/science/avogadro
root@lumiwa:~# rehash
root@lumiwa:~# whereis avogadro
avogadro: /usr/local/man/man1/avogadro.1 /usr/ports/science/avogadro

Thank you.

-- 
Mitja
---
http://www.redbubble.com/people/lumiwa

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: avogadro update

[Alex V. Petrov]

For me stop build:

[ 10%] Building CXX object
libavogadro/src/extensions/surfaces/openqube/CMakeFiles/OpenQube.dir/moc_gaussianset.cxx.o
usr/local/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse
error at "BOOST_JOIN"
--- libavogadro/src/moc_pythonengine_p.cxx ---
*** [libavogadro/src/moc_pythonengine_p.cxx] Error code 1

make[4]: stopped in /usr/ports/science/avogadro/work/avogadro-1.1.1
1 error


2014-02-08 19:27 GMT+08:00 Ajtim :

> Hi!
>
> Avogadro 1.1.1_1 update on reeBSD 10.0-RELEASE (amd64) doesn't work:
>
> > Compressing man pages (compress-man)
> ===>  Installing for avogadro-1.1.1_1
> ===>  Checking if science/avogadro already installed
> ===>   Registering installation for avogadro-1.1.1_1
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonerror.h):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythoninterpreter.h):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonscript.h):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/avogadro/1_1/extensions/pythonterminal.so):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/python2.7/site-packages/Avogadro.so):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/wireframe.py):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/example.py):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/):
> No such file or directory
> pkg-static:
> lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/):
> No such file or directory
> *** Error code 74
>
> Stop.
> make[1]: stopped in /usr/ports/science/avogadro
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/science/avogadro
> root@lumiwa:~# rehash
> root@lumiwa:~# whereis avogadro
> avogadro: /usr/local/man/man1/avogadro.1 /usr/ports/science/avogadro
>
> Thank you.
>
> --
> Mitja
> ---
> http://www.redbubble.com/people/lumiwa
>
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>



-- 
--
Alex V. Petrov
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

graphics/ufraw: build failure because of old icu dependency

[Rainer Hurling]

After yesterdays update of devel/icu it also seems necessary to update
graphics/ufraw:


#diff -u Makefile.orig  Makefile
--- Makefile.orig   2014-02-06 16:44:50.0 +0100
+++ Makefile2014-02-08 12:38:24.0 +0100
@@ -103,7 +103,7 @@
 .endfor

 pre-build:
-   @${INSTALL_SCRIPT} ${LOCALBASE}/share/icu/50.1.2/mkinstalldirs \
+   @${INSTALL_SCRIPT} ${LOCALBASE}/share/icu/52.1/mkinstalldirs \
${WRKSRC}

 .include 


Thanks,
Rainer Hurling
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ICU sweeping upgrade: bug or feature?

[Andrea Venturoli]

Hello.

Today I started some ports' upgrade and icu went from 50.1.2 to 52.1.

As soon as this happened, lots of applications are not working anymore.
E.G.


% firefox
XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
Shared object "libicui18n.so.50" not found, required by "libxul.so"
Couldn't load XPCOM.




While everything is recompiling (which will take several hours, since at 
least FireFox, ThunderBird and LibreOffice, among others, are affected), 
I am left wondering what went wrong: usually backup libraries are kept 
in /usr/local/lib/compat/pkg...


So:

# cd /usr/local/lib/compat/pkg/
# ls |grep icu
libicudata.so.50.1.2
libicui18n.so.50.1.2
libicuio.so.50.1.2
libicule.so.50.1.2
libiculx.so.50.1.2
libicutest.so.50.1.2
libicutu.so.50.1.2
libicuuc.so.50.1.2


I have an idea:


# ln -s libicui18n.so.50.1.2 libicui18n.so.50


Now:

% firefox
XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
Shared object "libicuuc.so.50" not found, required by "libxul.so"
Couldn't load XPCOM.


Hmmm... so, to make it short:

# ln -s libicudata.so.50.1.2 libicu
# ln -s libicudata.so.50.1.2 libicudata.so.50


and Firefox and LibreOffice are starting again.



Hope this can help someone.
OTOH I would have expected this to happen automatically; shouldn't it?

 bye & Thanks
av.

P.S.

# uname -a
... 10.0-RELEASE ... amd64


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools

[Julian H. Stacey]

Michel Talon wrote:
> So
> how to interact with local.sqlite?

Thanks Michel,
Noted.
Would you please consider running send-pr to submit that for man 5 ?
Prepending
EXAMPLES
Appending
SEE ALSO pkg(8)

There is no src/share/man/man5/local.sqlite.5
in both 10.0-RELEASE & branches/-current/ 

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
 Interleave replies below like a play script.  Indent old text with "> ".
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: WARNING: devel/icu: recent update redners openldap-server and other ports unusable!

[Matthew Rezny]

> On Fri, Feb 07, 2014 at 10:54:45PM +0100, O. Hartmann wrote:
> > 
> > Today a couple of updates has been introduced, one of them was an
> > update of port devel/icu.
> > 
> > I the good manner/tradition of updating UPDATING, I expect a
> > warning/hint/advice a couple of days from now - when everybody has
> > already stepped into the mess.
> > 
> > On several boxes running 11.0-CURRENT and 9.2-STABLE, updating ports
> > including devel/icu renders many ports unusable due to a library
> > version bump in libicu.
> > 
> > After updating ports relying on devel/icu via
> > 
> > portmaster -r devel/icu
> > 
> > and the updating of port
> > 
> > net/openldap24-server
> > 
> > (which is openldap-sasl-server in my case), OpenLDAP doesn't start
> > anymore on all boxes affected by the update of devel/icu!
> > 
> > I always get the error
> > 
> > 52f5551f hdb_db_init: Initializing HDB database
> > 52f5551f olcDbDirectory: value #0: invalid path: Permission denied
> > 52f5551f config error processing olcDatabase={1}hdb,cn=config:
> > olcDbDirectory: value #0: invalid path: Permission denied 52f5551f
> > send_ldap_result: conn=-1 op=0 p=0 52f5551f slapd destroy: freeing
> > system resources. 52f5551f syncinfo_free: rid=001
> > 52f5551f slapd stopped.
> > 52f5551f connections_destroy: nothing to destroy.
> > /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd
> > 
> > 
> > This obscure 
> > 
> > olcDbDirectory: value #0: invalid path: Permission denied
> > 
> > is not obvious to me. The server ran minutes ago BEFORE the update,
> > the directories containing the DB5 databases have all the correct
> > ownership (ldap:ldap, I suspected first a misconfiguration as this
> > error seems typical for a misconfiguration of the ownership).
> > 
> > Does anyone see the same problem? And maybe please would put out
> > some notes in UPDATING within a considerable narrow timeframe
> > regarding devel/icu! It seems, FreeBSD's ports systems get more and
> > more messy.
> > 
> > oh
> 
> devel/icu has nothing to do with openldap, neither with one of
> openldap dependency.
> 
> Have you checked the full path to the said DB5 databases and not only
> the directory containing those files?
> 
> regards,
> Bapt

If glib is compiled with the collation fix, it links against icu, thus
any port which depends on glib also depends on icu. The update to
devel/icu has made quite a mess of one of my systems when it took me by
surprise yesterday as well. There are multiple stumbling blocks along
the way.

glib20 won't build if libiconv is installed from ports. Uninstalling
the libiconv port allows glib20 to build against iconv in base. There
is a PR with a not yet committed patch that should workaround this.

net/avahi-app can't properly upgrade. The port builds libavahi-glib.so
and then immediately tries to link against the lib of the same name
that is installed rather than the one that was just built. The installed
version of that library is linked against old icu which doesn't exist
so the link fails. Uninstalling avahi-app first forces the build to use
the library compiled against current icu. This is a bug in the port.

There was also a problem with hal, which was the tip of the iceburg I
hit, but I relieved myself of the dependency on hal before I realized I
had a much bigger problem and many ports to rebuild. I did not revisit
hal to see if it would build correct after glib was rebuilt against
icu, or if it too needed some extra step.

Without any entry in UPDATING, I was facing linking problems against
glib that didn't make any sense. Current version of glib was installed
and the missing symbols weren't even really from glib. It was only when
I finally ran pkg_libchk and saw the huge mess of things that wanted
libicu.so.50 that the picture finally became clear.

Looking at the history of both devel/icu and UPDATING, I see that for
the 4.6 and 4.8 updates there was an entry directing users to run
portmaster -r icu, but for 5.0 and 5.2 updates there is not entry, so
this is the second time there has been an icu bump without any advisory
in UPDATING. Please do not neglect this step up when updating ports.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: WARNING: devel/icu: recent update redners openldap-server and other ports unusable!

[Chris Rees]

Shane Ambler  wrote:
>On 08/02/2014 08:24, O. Hartmann wrote:
>> 
>> Today a couple of updates has been introduced, one of them was an
>> update of port devel/icu.
>> 
>> I the good manner/tradition of updating UPDATING, I expect a
>> warning/hint/advice a couple of days from now - when everybody has
>> already stepped into the mess.
>> 
>> On several boxes running 11.0-CURRENT and 9.2-STABLE, updating ports
>> including devel/icu renders many ports unusable due to a library
>> version bump in libicu.
>> 
>> After updating ports relying on devel/icu via
>> 
>> portmaster -r devel/icu
>> 
>> and the updating of port
>> 
>> net/openldap24-server
>> 
>> (which is openldap-sasl-server in my case), OpenLDAP doesn't start
>> anymore on all boxes affected by the update of devel/icu!
>> 
>> I always get the error
>> 
>> 52f5551f hdb_db_init: Initializing HDB database
>> 52f5551f olcDbDirectory: value #0: invalid path: Permission denied
>> 52f5551f config error processing olcDatabase={1}hdb,cn=config:
>> olcDbDirectory: value #0: invalid path: Permission denied 52f5551f
>> send_ldap_result: conn=-1 op=0 p=0 52f5551f slapd destroy: freeing
>> system resources. 52f5551f syncinfo_free: rid=001
>> 52f5551f slapd stopped.
>> 52f5551f connections_destroy: nothing to destroy.
>> /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd
>> 
>> 
>> This obscure 
>> 
>> olcDbDirectory: value #0: invalid path: Permission denied
>> 
>> is not obvious to me. The server ran minutes ago BEFORE the update,
>the
>> directories containing the DB5 databases have all the correct
>ownership
>> (ldap:ldap, I suspected first a misconfiguration as this error seems
>> typical for a misconfiguration of the ownership).
>> 
>> Does anyone see the same problem? And maybe please would put out some
>> notes in UPDATING within a considerable narrow timeframe regarding
>> devel/icu! It seems, FreeBSD's ports systems get more and more messy.
>> 
>> oh
>> 
>
>Not the same problem but I did see building postgresql server break -
>I changed databases/postgresql92-server/makefile with the following.
>Ideally the test for *_52 should be added to configure.in rather than
>replacing the oldest.
>
>--- a/databases/postgresql92-server/Makefile
>+++ b/databases/postgresql92-server/Makefile
>@@ -355,6 +355,8 @@ post-patch:
> .  if defined(SERVER_ONLY) && ${PORT_OPTIONS:MICU}
>@${REINPLACE_CMD} -E -e \
>"s|^(m4_if.*)2.6[0-9](.*Autoconf version
>)2.6[0-9]|\1${AUTOCONF_VERSION}\2${AUTOCONF_VERSION}|g" \
>+   -e "s|ucol_open_43|ucol_open_52|g" \
>+   -e "s|ucnv_fromUChars_43|ucnv_fromUChars_52|g" \
>${WRKSRC}/configure.in
> .  endif

Hmm, the ICU support was written by Palle, hence we are the upstream for it.

Palle, do you think this is a good fix?

Thanks Shane, by the way :)

Chris
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

[QAT] r343362: 4x leftovers

[Ports-QAT]

- Stage support
-

  Build ID:  20140208163800-16284
  Job owner: m...@freebsd.org
  Buildtime: 7 minutes
  Enddate:   Sat, 08 Feb 2014 16:45:06 GMT

  Revision:  r343362
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=343362

-

Port:dns/c-ares 1.10.0

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140208163800-16284-273548/c-ares-config-1.10.0.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140208163800-16284-273549/c-ares-config-1.10.0.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140208163800-16284-273550/c-ares-config-1.10.0.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~m...@freebsd.org/20140208163800-16284-273551/c-ares-config-1.10.0.log


--
Buildarchive URL: 
redports 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Warren Block]

On Sat, 8 Feb 2014, Andrea Venturoli wrote:


Today I started some ports' upgrade and icu went from 50.1.2 to 52.1.

As soon as this happened, lots of applications are not working anymore.

...


Hmmm... so, to make it short:

# ln -s libicudata.so.50.1.2 libicu
# ln -s libicudata.so.50.1.2 libicudata.so.50


and Firefox and LibreOffice are starting again.


This may very well come back to bite you in the future, causing 
mysterious failures long after you've forgotten you did it.  Here's a 
little Ruby script to detect these (it needs updating to work with pkg):

http://www.wonkity.com/~wblock/fakelib/fastfakelib

Running pkg_libchk [-q] after port upgrades has worked well for me.  It 
is from sysutils/bsdadminscripts by Dominic Fandrey, and easily detects 
applications that are using old libraries and should be rebuilt.  It 
worked this time also.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Andrea Venturoli]

On 02/08/14 12:21, Andrea Venturoli wrote:

Hello.

Today I started some ports' upgrade and icu went from 50.1.2 to 52.1.

As soon as this happened, lots of applications are not working anymore.
E.G.


% firefox
XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
Shared object "libicui18n.so.50" not found, required by "libxul.so"
Couldn't load XPCOM.




While everything is recompiling (which will take several hours, since at
least FireFox, ThunderBird and LibreOffice, among others, are affected),
I am left wondering what went wrong: usually backup libraries are kept
in /usr/local/lib/compat/pkg...

So:

# cd /usr/local/lib/compat/pkg/
# ls |grep icu
libicudata.so.50.1.2
libicui18n.so.50.1.2
libicuio.so.50.1.2
libicule.so.50.1.2
libiculx.so.50.1.2
libicutest.so.50.1.2
libicutu.so.50.1.2
libicuuc.so.50.1.2


I have an idea:


# ln -s libicui18n.so.50.1.2 libicui18n.so.50


Now:

% firefox
XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
Shared object "libicuuc.so.50" not found, required by "libxul.so"
Couldn't load XPCOM.


Hmmm... so, to make it short:

# ln -s libicudata.so.50.1.2 libicu
# ln -s libicudata.so.50.1.2 libicudata.so.50


and Firefox and LibreOffice are starting again.



Hope this can help someone.
OTOH I would have expected this to happen automatically; shouldn't it?

  bye & Thanks
 av.

P.S.

# uname -a
... 10.0-RELEASE ... amd64


BTW LibreOffice was not bumped, so it would not be recompiled by 
"portupgrade -r icu" or similar.


 bye
av.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Andrea Venturoli]

On 02/08/14 18:11, Andrea Venturoli wrote:


BTW LibreOffice was not bumped, so it would not be recompiled by
"portupgrade -r icu" or similar.


Forget this, please.
Now I see it bumped.

 bye & Sorry
av.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: curl-7.34.0 +Threaded DNS resolver

[Václav Zeman]

On 02/08/2014 12:10 AM, Kubilay Kocak wrote:
> On 8/02/2014 1:51 AM, Paul Macdonald wrote:
>>
>> Hi,
>>
>> I think there's an issue with the latest curl when Threaded DNS resolver
>> is selected.
>>
>> On several boxes curl doesn't return for dns required requests, but does
>> for ip's
>>
>> rebuilding without the option fixes the issue..
>>
>>
>> Paul
>>
>>
>>
> 
> Paul,
> 
> I came across the same issue testing a .34 port update before the recent
> update, and had a quick discussion with the #curl crew on freenode with
> no resolution other than further isolation:
> 
> 7.33.0 - OK
> 7.34.0+ - NOK
> 
> IPV6 RESOLVER_THREADED - OK
> NO_IPV6 RESOLVER_THREADED - NOK
> NO_IPV6 RESOLVER_DEFAULT - OK
> IPV6 RESOLVER_DEFAULT - OK
> 
> Note: There were no differences running the test suite, so it doesnt
> look like this issue is test covered
> 
> I suggest:
> 
> - Updating the port to 7.35.0 and reporting back on whether the issue
> still exists
> - Test 7.34.0 with and without IPv6 OPTION with the threaded resolver
> and confirm similar isolation as above
> 
> - Maintainer disables threaded resolver by default until
> isolated/resolved upstream

I think this is related:
. Newer version should
fix this issue.

-- 
VZ




signature.asc
Description: OpenPGP digital signature

Re: ICU sweeping upgrade: bug or feature?

[Baptiste Daroussin]

On Sat, Feb 08, 2014 at 06:11:43PM +0100, Andrea Venturoli wrote:
> On 02/08/14 12:21, Andrea Venturoli wrote:
> > Hello.
> >
> > Today I started some ports' upgrade and icu went from 50.1.2 to 52.1.
> >
> > As soon as this happened, lots of applications are not working anymore.
> > E.G.
> >
> >> % firefox
> >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
> >> Shared object "libicui18n.so.50" not found, required by "libxul.so"
> >> Couldn't load XPCOM.
> >
> >
> >
> > While everything is recompiling (which will take several hours, since at
> > least FireFox, ThunderBird and LibreOffice, among others, are affected),
> > I am left wondering what went wrong: usually backup libraries are kept
> > in /usr/local/lib/compat/pkg...
> >
> > So:
> >> # cd /usr/local/lib/compat/pkg/
> >> # ls |grep icu
> >> libicudata.so.50.1.2
> >> libicui18n.so.50.1.2
> >> libicuio.so.50.1.2
> >> libicule.so.50.1.2
> >> libiculx.so.50.1.2
> >> libicutest.so.50.1.2
> >> libicutu.so.50.1.2
> >> libicuuc.so.50.1.2
> >
> > I have an idea:
> >
> >> # ln -s libicui18n.so.50.1.2 libicui18n.so.50
> >
> > Now:
> >> % firefox
> >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
> >> Shared object "libicuuc.so.50" not found, required by "libxul.so"
> >> Couldn't load XPCOM.
> >
> > Hmmm... so, to make it short:
> >> # ln -s libicudata.so.50.1.2 libicu
> >> # ln -s libicudata.so.50.1.2 libicudata.so.50
> >
> > and Firefox and LibreOffice are starting again.
> >
> >
> >
> > Hope this can help someone.
> > OTOH I would have expected this to happen automatically; shouldn't it?
> >
> >   bye & Thanks
> >  av.
> >
> > P.S.
> >> # uname -a
> >> ... 10.0-RELEASE ... amd64
> 
> BTW LibreOffice was not bumped, so it would not be recompiled by 
> "portupgrade -r icu" or similar.
> 
>   bye
>   av.
LibreOffice has been bumped to chase that.
All the mozilla soft has been forgotten but they were the only one forgotten and
they have been bumped a couple of hours laters.

regards,
Bapt


pgpFrbyuvjYif.pgp
Description: PGP signature

Re: ICU sweeping upgrade: bug or feature?

[Kevin Oberman]

You need to bump gobject-introspection and glib20, as well. I'll report any
others I find later after the rebuild of those you caught and a run of
pkg_libchk.


On Sat, Feb 8, 2014 at 12:00 PM, Baptiste Daroussin wrote:

> On Sat, Feb 08, 2014 at 06:11:43PM +0100, Andrea Venturoli wrote:
> > On 02/08/14 12:21, Andrea Venturoli wrote:
> > > Hello.
> > >
> > > Today I started some ports' upgrade and icu went from 50.1.2 to 52.1.
> > >
> > > As soon as this happened, lots of applications are not working anymore.
> > > E.G.
> > >
> > >> % firefox
> > >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
> > >> Shared object "libicui18n.so.50" not found, required by "libxul.so"
> > >> Couldn't load XPCOM.
> > >
> > >
> > >
> > > While everything is recompiling (which will take several hours, since
> at
> > > least FireFox, ThunderBird and LibreOffice, among others, are
> affected),
> > > I am left wondering what went wrong: usually backup libraries are kept
> > > in /usr/local/lib/compat/pkg...
> > >
> > > So:
> > >> # cd /usr/local/lib/compat/pkg/
> > >> # ls |grep icu
> > >> libicudata.so.50.1.2
> > >> libicui18n.so.50.1.2
> > >> libicuio.so.50.1.2
> > >> libicule.so.50.1.2
> > >> libiculx.so.50.1.2
> > >> libicutest.so.50.1.2
> > >> libicutu.so.50.1.2
> > >> libicuuc.so.50.1.2
> > >
> > > I have an idea:
> > >
> > >> # ln -s libicui18n.so.50.1.2 libicui18n.so.50
> > >
> > > Now:
> > >> % firefox
> > >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
> > >> Shared object "libicuuc.so.50" not found, required by "libxul.so"
> > >> Couldn't load XPCOM.
> > >
> > > Hmmm... so, to make it short:
> > >> # ln -s libicudata.so.50.1.2 libicu
> > >> # ln -s libicudata.so.50.1.2 libicudata.so.50
> > >
> > > and Firefox and LibreOffice are starting again.
> > >
> > >
> > >
> > > Hope this can help someone.
> > > OTOH I would have expected this to happen automatically; shouldn't it?
> > >
> > >   bye & Thanks
> > >  av.
> > >
> > > P.S.
> > >> # uname -a
> > >> ... 10.0-RELEASE ... amd64
> >
> > BTW LibreOffice was not bumped, so it would not be recompiled by
> > "portupgrade -r icu" or similar.
> >
> >   bye
> >   av.
> LibreOffice has been bumped to chase that.
> All the mozilla soft has been forgotten but they were the only one
> forgotten and
> they have been bumped a couple of hours laters.
>
> regards,
> Bapt
>



-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Baptiste Daroussin]

On Sat, Feb 08, 2014 at 12:14:56PM -0800, Kevin Oberman wrote:
> You need to bump gobject-introspection and glib20, as well. I'll report any
> others I find later after the rebuild of those you caught and a run of
> pkg_libchk.
> 
No glib only depends on icu if one option is set which default to off, and then
glib20 pollutes tons of other ports.

regards,
Bapt


pgpAX1aNKdDUR.pgp
Description: PGP signature

Re: 10.0-release jail on head-hosted tinderbox (Was: Re: 10.0-hosted tinderbox: 8.4 builds broken?)

[Joe Marcus Clarke]

On 2/7/14, 2:18 AM, Alexey Dokuchaev wrote:

On Sun, Oct 13, 2013 at 01:36:45PM +0100, Chris Rees wrote:

It appears that really weird SRCBASE assumptions are made throughout the
code.  I'll have to put a temporary hack in to just make SRCBASE appear
inside the chroot whatever it's set to.  Setting and unsetting SRCBASE just
breaks different things in weird ways, and this is the only reliable fix
I've found.

Joe, please can I stick this in, and merge to the beta?

http://www.bayofrum.net/~crees/patches/tinderbox-fake-srcbase.diff

Alexey, try this patch.  This one definitely works for me, and gets the
dependencies working correctly.


Can be unrelated, but I've been observing some bad behavior with fresh
tinderbox code from CVS and equally fresh -CURRENT (just tried again
today): install FreeBSD/amd64, 'cvs up', rebuild world/kernel (GENERIC),
cvs co tinderbox, create jails for 10.0-RELEASE and 9.2-RELEASE.  Builds
for 9.2 work fine; trying to build anything for 10.0 always fails in a
similar way (take a look at attached make.0 file).  I've seen this on
i386/non-zfs as well.  Particularly, these lines look bad:

   /buildscript: pkg-static: not found
   tar: Error opening archive: Failed to open 'pkg-1.2.6.txz'
   /buildscript: ./pkg-static: not found
   error in dependency pkg-1.2.6.txz, exiting


This part looks weird:

skipping package pkg-1.2.6.txz for pcre-8.34 since it is missing

Why wasn't pkg built?  It appears the Makefile was generated correctly 
to a point.  Pcre should depend on pkg.  What does the Makefile look 
like?  Do you have any logs for the pkg package build?


Joe



./danfe



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"




--
Joe Marcus Clarke
FreeBSD GNOME Team  ::  gn...@freebsd.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Kevin Oberman]

Add atk, clutter, pango, gdk-pixbuf2, and json-glib-0.14.2.


On Sat, Feb 8, 2014 at 12:14 PM, Kevin Oberman  wrote:

> You need to bump gobject-introspection and glib20, as well. I'll report
> any others I find later after the rebuild of those you caught and a run of
> pkg_libchk.
>
>
> On Sat, Feb 8, 2014 at 12:00 PM, Baptiste Daroussin wrote:
>
>> On Sat, Feb 08, 2014 at 06:11:43PM +0100, Andrea Venturoli wrote:
>> > On 02/08/14 12:21, Andrea Venturoli wrote:
>> > > Hello.
>> > >
>> > > Today I started some ports' upgrade and icu went from 50.1.2 to 52.1.
>> > >
>> > > As soon as this happened, lots of applications are not working
>> anymore.
>> > > E.G.
>> > >
>> > >> % firefox
>> > >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
>> > >> Shared object "libicui18n.so.50" not found, required by "libxul.so"
>> > >> Couldn't load XPCOM.
>> > >
>> > >
>> > >
>> > > While everything is recompiling (which will take several hours, since
>> at
>> > > least FireFox, ThunderBird and LibreOffice, among others, are
>> affected),
>> > > I am left wondering what went wrong: usually backup libraries are kept
>> > > in /usr/local/lib/compat/pkg...
>> > >
>> > > So:
>> > >> # cd /usr/local/lib/compat/pkg/
>> > >> # ls |grep icu
>> > >> libicudata.so.50.1.2
>> > >> libicui18n.so.50.1.2
>> > >> libicuio.so.50.1.2
>> > >> libicule.so.50.1.2
>> > >> libiculx.so.50.1.2
>> > >> libicutest.so.50.1.2
>> > >> libicutu.so.50.1.2
>> > >> libicuuc.so.50.1.2
>> > >
>> > > I have an idea:
>> > >
>> > >> # ln -s libicui18n.so.50.1.2 libicui18n.so.50
>> > >
>> > > Now:
>> > >> % firefox
>> > >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
>> > >> Shared object "libicuuc.so.50" not found, required by "libxul.so"
>> > >> Couldn't load XPCOM.
>> > >
>> > > Hmmm... so, to make it short:
>> > >> # ln -s libicudata.so.50.1.2 libicu
>> > >> # ln -s libicudata.so.50.1.2 libicudata.so.50
>> > >
>> > > and Firefox and LibreOffice are starting again.
>> > >
>> > >
>> > >
>> > > Hope this can help someone.
>> > > OTOH I would have expected this to happen automatically; shouldn't it?
>> > >
>> > >   bye & Thanks
>> > >  av.
>> > >
>> > > P.S.
>> > >> # uname -a
>> > >> ... 10.0-RELEASE ... amd64
>> >
>> > BTW LibreOffice was not bumped, so it would not be recompiled by
>> > "portupgrade -r icu" or similar.
>> >
>> >   bye
>> >   av.
>> LibreOffice has been bumped to chase that.
>> All the mozilla soft has been forgotten but they were the only one
>> forgotten and
>> they have been bumped a couple of hours laters.
>>
>> regards,
>> Bapt
>>
>
>
>
> --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
>



-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

[QAT] r343384: 2x leftovers, 2x depend (fetch in security/luasec)

[Ports-QAT]

Update to 0.9.2.

PR: ports/182075
Submitted by:   Paul Procacci  / Benjamin Podszun 

-

  Build ID:  20140208203800-32675
  Job owner: l...@freebsd.org
  Buildtime: 9 minutes
  Enddate:   Sat, 08 Feb 2014 20:46:52 GMT

  Revision:  r343384
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=343384

-

Port:net-im/prosody 0.9.2

  Buildgroup: 8.4-QAT/amd64
  Buildstatus:   DEPEND (FETCH IN SECURITY/LUASEC)
  Log: 
https://qat.redports.org//~l...@freebsd.org/20140208203800-32675-273636/lua51-luasec-0.5.log

  Buildgroup: 8.4-QAT/i386
  Buildstatus:   DEPEND (FETCH IN SECURITY/LUASEC)
  Log: 
https://qat.redports.org//~l...@freebsd.org/20140208203800-32675-273637/lua51-luasec-0.5.log

  Buildgroup: 9.2-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~l...@freebsd.org/20140208203800-32675-273638/prosody-0.9.2.log

  Buildgroup: 9.2-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~l...@freebsd.org/20140208203800-32675-273639/prosody-0.9.2.log


--
Buildarchive URL: 
redports 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Baptiste Daroussin]

On Sat, Feb 08, 2014 at 12:26:44PM -0800, Kevin Oberman wrote:
> Add atk, clutter, pango, gdk-pixbuf2, and json-glib-0.14.2.
> 
You can add everything linked to glib to stah list


pgpMY7WiCMrIx.pgp
Description: PGP signature

Re: Error build the port devel/glib20

[Mark Knight]

On 08/02/2014 01:20, John Hein wrote:
> See the 20130904 entry in ports/UPDATING

I'm hitting the same issue. Unfortunately some ports seem to require
converters/libiconv from ports - e.g. converters/php5-iconv or
net/avahi-app.

First I removed libiconv per instructions in UPDATING and some ports
wouldn't build. Now I reinstall libiconv and different ports fail :(

Upgrading from 9.2 to 10.0 is turning out to be more difficult that
previous major bumps...

Unrelated but squid33 also barfs under 10.0 with cache_dir aufs.
cache_dir ufs is okay.

Cheers,
-- 
Mark
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ICU sweeping upgrade: bug or feature?

[Kevin Oberman]

Add gvfs, gconf2, ORBit2-2.14.19, libIDL-0.8.14_1, gtk2-2.24.22_1. (Almost
all of these were needed for either clutter or clutter-gtk.


On Sat, Feb 8, 2014 at 12:26 PM, Kevin Oberman  wrote:

> Add atk, clutter, pango, gdk-pixbuf2, and json-glib-0.14.2.
>
>
> On Sat, Feb 8, 2014 at 12:14 PM, Kevin Oberman wrote:
>
>> You need to bump gobject-introspection and glib20, as well. I'll report
>> any others I find later after the rebuild of those you caught and a run of
>> pkg_libchk.
>>
>>
>> On Sat, Feb 8, 2014 at 12:00 PM, Baptiste Daroussin wrote:
>>
>>> On Sat, Feb 08, 2014 at 06:11:43PM +0100, Andrea Venturoli wrote:
>>> > On 02/08/14 12:21, Andrea Venturoli wrote:
>>> > > Hello.
>>> > >
>>> > > Today I started some ports' upgrade and icu went from 50.1.2 to 52.1.
>>> > >
>>> > > As soon as this happened, lots of applications are not working
>>> anymore.
>>> > > E.G.
>>> > >
>>> > >> % firefox
>>> > >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
>>> > >> Shared object "libicui18n.so.50" not found, required by "libxul.so"
>>> > >> Couldn't load XPCOM.
>>> > >
>>> > >
>>> > >
>>> > > While everything is recompiling (which will take several hours,
>>> since at
>>> > > least FireFox, ThunderBird and LibreOffice, among others, are
>>> affected),
>>> > > I am left wondering what went wrong: usually backup libraries are
>>> kept
>>> > > in /usr/local/lib/compat/pkg...
>>> > >
>>> > > So:
>>> > >> # cd /usr/local/lib/compat/pkg/
>>> > >> # ls |grep icu
>>> > >> libicudata.so.50.1.2
>>> > >> libicui18n.so.50.1.2
>>> > >> libicuio.so.50.1.2
>>> > >> libicule.so.50.1.2
>>> > >> libiculx.so.50.1.2
>>> > >> libicutest.so.50.1.2
>>> > >> libicutu.so.50.1.2
>>> > >> libicuuc.so.50.1.2
>>> > >
>>> > > I have an idea:
>>> > >
>>> > >> # ln -s libicui18n.so.50.1.2 libicui18n.so.50
>>> > >
>>> > > Now:
>>> > >> % firefox
>>> > >> XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
>>> > >> Shared object "libicuuc.so.50" not found, required by "libxul.so"
>>> > >> Couldn't load XPCOM.
>>> > >
>>> > > Hmmm... so, to make it short:
>>> > >> # ln -s libicudata.so.50.1.2 libicu
>>> > >> # ln -s libicudata.so.50.1.2 libicudata.so.50
>>> > >
>>> > > and Firefox and LibreOffice are starting again.
>>> > >
>>> > >
>>> > >
>>> > > Hope this can help someone.
>>> > > OTOH I would have expected this to happen automatically; shouldn't
>>> it?
>>> > >
>>> > >   bye & Thanks
>>> > >  av.
>>> > >
>>> > > P.S.
>>> > >> # uname -a
>>> > >> ... 10.0-RELEASE ... amd64
>>> >
>>> > BTW LibreOffice was not bumped, so it would not be recompiled by
>>> > "portupgrade -r icu" or similar.
>>> >
>>> >   bye
>>> >   av.
>>> LibreOffice has been bumped to chase that.
>>> All the mozilla soft has been forgotten but they were the only one
>>> forgotten and
>>> they have been bumped a couple of hours laters.
>>>
>>> regards,
>>> Bapt
>>>
>>
>>
>>
>> --
>> R. Kevin Oberman, Network Engineer, Retired
>> E-mail: rkober...@gmail.com
>>
>
>
>
> --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
>



-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools

[Nikola Pavlović]

On 06/02/14 13:58, Rick Miller wrote:
> On Thu, Feb 6, 2014 at 7:23 AM, Daniel Nebdal  
> wrote:
> 
>> On Thu, Feb 6, 2014 at 12:41 PM, Rick Miller 
>>  wrote:
>>> On Thu, Feb 6, 2014 at 2:59 AM, Big Lebowski 
>>> 
>> wrote:
 The ability to install certain package version, instead of 
 installing simply the latest one. Please, please, pretty 
 please! :)
>>> 
>>> 
>>> I echo this sentiment, but I would like to take it a step
>>> further and say "a certain version or greater".
>>> 
>>> 
>> 
>> I suspect he meant  "a certain version, and *not* newer" - 
>> sometimes you might want to hold back a package.
>> 
> 
> Correct.  My wish is the functionality be extended further to mean "a
> certain version *or* newer", encompassing both features.  Thus, 
> allowing him to say "port-1.1", while I say "port-1.4 or newer" or 
> even "port-1.0 or newer".
> 

Python's pip has a nice syntax for this, for example:

somepackage>=1.6,<=1.8

Something like this could be adopted.  (Disregarding the discussion if
this is technically feasible ATM, I'm sure it will be eventually).


-- 
I guess the Little League is even littler than we thought.
-- D. Cavett




signature.asc
Description: OpenPGP digital signature

Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools

[Nikola Pavlović]

On 08/02/14 14:04, Julian H. Stacey wrote:
> Michel Talon wrote:
>> So
>> how to interact with local.sqlite?
> 
> Thanks Michel,
> Noted.

Further, if you really want to debug and inspect with text tools you can
simply do

$ sqlite3 local.sqlite .dump > dump.sql

or

$ sqlite3 -csv local.sqlite .dump > dump.csv

From there, I'm sure an impressive pipeline to do just about
anything you want can be constructed, if that's what you need.

You can also do any kind of additional SQL in that last parameter (.dump
is just an sqlite specific SQL meta command) with semicolon separated
statements.

-- 
Contestants have been briefed on some questions before the show.




signature.asc
Description: OpenPGP digital signature

Re: avogadro update

[Ajtim]

On Saturday 08 February 2014 19:41:42 Alex V. Petrov wrote:
> For me stop build:
> 
> [ 10%] Building CXX object
> libavogadro/src/extensions/surfaces/openqube/CMakeFiles/OpenQube.dir/moc_gaussianset.cxx.o
> usr/local/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse
> error at "BOOST_JOIN"
> --- libavogadro/src/moc_pythonengine_p.cxx ---
> *** [libavogadro/src/moc_pythonengine_p.cxx] Error code 1
> 
> make[4]: stopped in /usr/ports/science/avogadro/work/avogadro-1.1.1
> 1 error
> 
> 
> 2014-02-08 19:27 GMT+08:00 Ajtim :
> 
> > Hi!
> >
> > Avogadro 1.1.1_1 update on reeBSD 10.0-RELEASE (amd64) doesn't work:
> >
> > > Compressing man pages (compress-man)
> > ===>  Installing for avogadro-1.1.1_1
> > ===>  Checking if science/avogadro already installed
> > ===>   Registering installation for avogadro-1.1.1_1
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonerror.h):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythoninterpreter.h):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonscript.h):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/avogadro/1_1/extensions/pythonterminal.so):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/python2.7/site-packages/Avogadro.so):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/wireframe.py):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/example.py):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/):
> > No such file or directory
> > pkg-static:
> > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/):
> > No such file or directory
> > *** Error code 74
> >
> > Stop.
> > make[1]: stopped in /usr/ports/science/avogadro
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/ports/science/avogadro
> > root@lumiwa:~# rehash
> > root@lumiwa:~# whereis avogadro
> > avogadro: /usr/local/man/man1/avogadro.1 /usr/ports/science/avogadro
> >
> > Thank you.
> >
> > --
> > Mitja
> > ---
> > http://www.redbubble.com/people/lumiwa
> >
> > ___
> > freebsd-ports@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> >
> 
> 
> 
> 
I add NO_STAGE=yes in /usr/ports/science/avogaro/Makefile and it installed port.

-- 
Mitja
---
http://www.redbubble.com/people/lumiwa

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: avogadro update

[Baptiste Daroussin]

On Sat, Feb 08, 2014 at 05:45:51PM -0500, Ajtim wrote:
> On Saturday 08 February 2014 19:41:42 Alex V. Petrov wrote:
> > For me stop build:
> > 
> > [ 10%] Building CXX object
> > libavogadro/src/extensions/surfaces/openqube/CMakeFiles/OpenQube.dir/moc_gaussianset.cxx.o
> > usr/local/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse
> > error at "BOOST_JOIN"
> > --- libavogadro/src/moc_pythonengine_p.cxx ---
> > *** [libavogadro/src/moc_pythonengine_p.cxx] Error code 1
> > 
> > make[4]: stopped in /usr/ports/science/avogadro/work/avogadro-1.1.1
> > 1 error
> > 
> > 
> > 2014-02-08 19:27 GMT+08:00 Ajtim :
> > 
> > > Hi!
> > >
> > > Avogadro 1.1.1_1 update on reeBSD 10.0-RELEASE (amd64) doesn't work:
> > >
> > > > Compressing man pages (compress-man)
> > > ===>  Installing for avogadro-1.1.1_1
> > > ===>  Checking if science/avogadro already installed
> > > ===>   Registering installation for avogadro-1.1.1_1
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonerror.h):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythoninterpreter.h):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/include/avogadro/pythonscript.h):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/avogadro/1_1/extensions/pythonterminal.so):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/lib/python2.7/site-packages/Avogadro.so):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/wireframe.py):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/example.py):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/extensionScripts/):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/engineScripts/):
> > > No such file or directory
> > > pkg-static:
> > > lstat(/usr/ports/science/avogadro/work/stage/usr/local/share/libavogadro/):
> > > No such file or directory
> > > *** Error code 74
> > >
> > > Stop.
> > > make[1]: stopped in /usr/ports/science/avogadro
> > > *** Error code 1
> > >
> > > Stop.
> > > make: stopped in /usr/ports/science/avogadro
> > > root@lumiwa:~# rehash
> > > root@lumiwa:~# whereis avogadro
> > > avogadro: /usr/local/man/man1/avogadro.1 /usr/ports/science/avogadro
> > >
> > > Thank you.
> > >
> > > --
> > > Mitja
> > > ---
> > > http://www.redbubble.com/people/lumiwa
> > >
> > > ___
> > > freebsd-ports@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> > >
> > 
> > 
> > 
> > 
> I add NO_STAGE=yes in /usr/ports/science/avogaro/Makefile and it installed 
> port.
> 
This is not a fix, this hides the problem.

regards,
Bapt


pgpL1iLctydrY.pgp
Description: PGP signature

Trouble verifying a pkg-repo signature manually

[John W. O'Brien]

Hello freebsd-ports@,

I'm trying to build and maintain my own package repository and
understand how everything is put together in the process. Right now, I'm
having trouble understanding how the signatures are made and verified.
The following should illustrate both the problem I'm having and how I
think things are supposed to work.

My environment
--

# pkg -v
1.2.6
# openssl version
OpenSSL 0.9.8y 5 Feb 2013
# uname -a
FreeBSD .saltant.net 9.2-STABLE FreeBSD 9.2-STABLE #1 r260112: Mon
Dec 30 18:26:07 EST 2013
r...@.saltant.net:/usr/obj/usr/src/sys/NARB  amd64


Build a package
---

# cd /usr/ports/devel/pkgconf
# make PACKAGES=/tmp/packages package
[...]
===>  Building package for pkgconf-0.9.4
# ls -lR /tmp/packages
total 4
drwxr-xr-x  2 root  wheel  512 Feb  8 18:32 All

/tmp/packages/All:
total 24
-rw-r--r--  1 root  wheel  23488 Feb  8 18:32 pkgconf-0.9.4.txz


Prepare the keys


# cd /tmp/keys
# openssl genrsa -out repo.key 2048
Generating RSA private key, 2048 bit long modulus
+++
...+++
e is 65537 (0x10001)
# openssl rsa -in repo.key -pubout repo.pub
writing RSA key


Generate the repo
-

# pkg repo /tmp/packages /tmp/keys/repo.key
Generating repository catalog in /tmp/packages: done!


Testing the signature
-

# cd /tmp/test
# tar xf /tmp/packages/digests.txz
# openssl dgst -verify /tmp/keys/repo.pub \
-signature signature -sha256 digests
Verification Failure


Making and testing a new signature
--

# openssl dgst -sign /tmp/repo.key -sha256 -binary digests > test_sig
# openssl dgst -verify /tmp/keys/repo.pub \
-signature test_sig -sha256 digests
Verified OK

I would be grateful if somebody could point me in the right direction,
or disabuse me of some obvious misconception.

Regards,
John



signature.asc
Description: OpenPGP digital signature

Re: Trouble verifying a pkg-repo signature manually

[John W. O'Brien]

On 2/8/14 6:50 PM, John W. O'Brien wrote:
> Hello freebsd-ports@,
> 
> I'm trying to build and maintain my own package repository and
> understand how everything is put together in the process. Right now, I'm
> having trouble understanding how the signatures are made and verified.
> The following should illustrate both the problem I'm having and how I
> think things are supposed to work.
[...]
> Testing the signature
> -
> 
> # cd /tmp/test
> # tar xf /tmp/packages/digests.txz
> # openssl dgst -verify /tmp/keys/repo.pub \
> -signature signature -sha256 digests
> Verification Failure
[...]

I think I found out why this doesn't work.

Inside pkg-repo(8), the code that actually generates the signature [0],
signs an ASCII-encoded, zero-terminated [1] representation of the SHA256
digest. I would guess that inside "openssl dgst ... -sha256 ..." the
signature generation and verification are operating on a SHA256 blob
(i.e. unterminated binary).

So, the next best way I've come up with to verify a repo by hand is this:

# openssl rsautl -pubin -inkey /tmp/keys/repo.pub \
-verify -in test_sig -asn1parse
0:d=0  hl=2 l=  49 cons: SEQUENCE
2:d=1  hl=2 l=  13 cons:  SEQUENCE
4:d=2  hl=2 l=   9 prim:   OBJECT:sha256
   15:d=2  hl=2 l=   0 prim:   NULL
   17:d=1  hl=2 l=  32 prim:  OCTET STRING
   - 7d b0 d6 38 8c 0f 28 53-2a 76 40 4f d6 84 8f 24
}..8..(S*v@O...$
  0010 - e5 0a a1 57 45 ec f1 31-14 aa d0 4c 9a d0 fc 17
...WE..1...L
# sha256 -q digests
7db0d6388c0f28532a76404fd6848f24e50aa15745ecf13114aad04c9ad0fc17

I just visually compare the OCTET STRING to the digest.

[0] rsa_sign()
https://github.com/freebsd/pkg/blob/master/libpkg/rsa.c#L175
[2] sha256_hash()
https://github.com/freebsd/pkg/blob/master/libpkg/utils.c#L343



signature.asc
Description: OpenPGP digital signature

Creation of WebRTC directories to create a FreeBSD port

[Joe Nosay]

In the following directory trunk/webrtc/test there needs to be a freebsd
directory containing the three files attached.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Creating files for FreeBSD from Linux files in WebRTC

[Joe Nosay]

In trunk/webrtc/modules in the sub-directories of video_capture,
video_render and  audio_device need to have a directory named freebsd in
each. Both the linux and mac sub-directories reference the mixer, capture,
and other parts of the system. Which ports in audio and multimedia have
FreeBSD as a part of the source files- not patched- along with Linux and
possibly Mac? I should be able to start with basic files for each with
enough references to study with and compare.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

INDEX build failed for 8.x

[Ports Index build]

INDEX build failed with errors:
Generating INDEX-8 - please 
wait.."/home/indexbuild/tindex/ports/Mk/bsd.port.mk", line 6613: if-less endif
make: fatal errors encountered -- cannot continue
===> accessibility/ruby-atk failed
*** [describe.accessibility] Error code 1
"/home/indexbuild/tindex/ports/Mk/bsd.port.mk", line 6613: if-less endif
make: fatal errors encountered -- cannot continue
===> archivers/ruby-lha failed
*** [describe.archivers] Error code 1
*** [/home/indexbuild/tindex/ports/INDEX-8] Error code 1

Stop in /home/indexbuild/tindex/ports.
*** [index] Error code 1

Stop in /home/indexbuild/tindex/ports.
2 errors

Committers on the hook:
 bdrewery danilo mat stephen 

Most recent SVN update was:
Updating '.':
Ucad/gmsh/pkg-plist
Ucad/gmsh/Makefile
Ucad/gmsh/distinfo
Udevel/gearmand-devel/pkg-plist
Udevel/gearmand-devel/Makefile
Udevel/gearmand/pkg-plist
Udevel/gearmand/Makefile
UMk/bsd.ruby.mk
Umail/spamdyke/Makefile
Umail/spamdyke/distinfo
Umail/serialmail/pkg-plist
Umail/serialmail/Makefile
Uirc/rbot/Makefile
Uftp/twoftpd/Makefile
Uftp/wzdftpd/pkg-plist
Uftp/wzdftpd/Makefile
Utextproc/dbacl/Makefile
UUPDATING
Updated to revision 343420.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: INDEX build failed for 8.x

[Bryan Drewery]

My bad. It's been fixed.

On 2/8/2014 9:17 PM, Ports Index build wrote:
> INDEX build failed with errors:
> Generating INDEX-8 - please 
> wait.."/home/indexbuild/tindex/ports/Mk/bsd.port.mk", line 6613: if-less endif
> make: fatal errors encountered -- cannot continue
> ===> accessibility/ruby-atk failed
> *** [describe.accessibility] Error code 1
> "/home/indexbuild/tindex/ports/Mk/bsd.port.mk", line 6613: if-less endif
> make: fatal errors encountered -- cannot continue
> ===> archivers/ruby-lha failed
> *** [describe.archivers] Error code 1
> *** [/home/indexbuild/tindex/ports/INDEX-8] Error code 1
> 
> Stop in /home/indexbuild/tindex/ports.
> *** [index] Error code 1
> 
> Stop in /home/indexbuild/tindex/ports.
> 2 errors
> 
> Committers on the hook:
>  bdrewery danilo mat stephen 
> 
> Most recent SVN update was:
> Updating '.':
> Ucad/gmsh/pkg-plist
> Ucad/gmsh/Makefile
> Ucad/gmsh/distinfo
> Udevel/gearmand-devel/pkg-plist
> Udevel/gearmand-devel/Makefile
> Udevel/gearmand/pkg-plist
> Udevel/gearmand/Makefile
> UMk/bsd.ruby.mk
> Umail/spamdyke/Makefile
> Umail/spamdyke/distinfo
> Umail/serialmail/pkg-plist
> Umail/serialmail/Makefile
> Uirc/rbot/Makefile
> Uftp/twoftpd/Makefile
> Uftp/wzdftpd/pkg-plist
> Uftp/wzdftpd/Makefile
> Utextproc/dbacl/Makefile
> UUPDATING
> Updated to revision 343420.
> ___
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Error build the port devel/glib20

[John Hein]

Guido Falsi wrote at 09:05 +0100 on Feb  8, 2014:
 > On 02/08/14 02:20, John Hein wrote:
 > > Vladislav Prodan wrote at 02:18 +0200 on Feb  8, 2014:
 > >  > # uname -a
 > >  > FreeBSD vm-10-1.domain.com 10.0-STABLE FreeBSD 10.0-STABLE #0 r261419: 
 > > Mon Feb  3 02:57:25 UTC 2014 
 > > r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
 > >  >
 > >  > make BATCH=yes MAKE_JOBS_UNSAFE=yes WITH_COLLATION_FIX=yes install -C 
 > > /usr/ports/devel/glib20
 > >  >
 > >  > 
 > >  > gmake[5]: Entering directory 
 > > `/usr/ports/devel/glib20/work/glib-2.36.3/glib'
 > >  >   CC   libglib_2_0_la-gallocator.lo
 > > ...
 > >  >   CC   libglib_2_0_la-gconvert.lo
 > >  > gconvert.c:66:2: error: GNU libiconv not in use but included iconv.h is 
 > > from libiconv
 > >  > #error GNU libiconv not in use but included iconv.h is from libiconv
 > >  >  ^
 > >
 > > See the 20130904 entry in ports/UPDATING
 >
 > While the entry is relevant commit 341775 changed the situation a bit.
 >
 > The patch in PR ports/186295 [1] should be helpful in this case.
 >
 > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/186295

Fair enough.
There aren't many ports using this feature from 341775 (and thus pulling
in converters/libiconv) on 10.x yet.  If the OP doesn't have one of
those ports in place, the effects of the note in UPDATING should be in
force.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

INDEX now builds successfully on 8.x

[Ports Index build]

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"