Re: Runtime loader issue

[Tijl Coosemans]

On Wed, 9 May 2018 16:45:51 -0700 Steve Kargl 
 wrote:
> In review PR 228007, it came to my attention some individuals are
> mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> issue".  See
>  
> https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html
> 
> The problem can be summarized by the following 
> 
> % gfortran7 -o z h.f90
> % ./z
> /lib/libgcc_s.so.1: version GCC_4.8.0 required by \
>   /usr/local/lib/gcc7/libgfortran.so.4 not found
> 
> gfortran7 is installed from ports/lang/gcc7.  This is not 
> a "gfortran's FreeBSD issue".  This is a FreeBSD loader issue.
> 
> Specifically, there is a shared library name clash.
> 
> % ldconfig -r | grep gcc_
>  6:-lgcc_s.1 => /lib/libgcc_s.so.1
>716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
> 
> % ldd z
> z:
>libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000)
>libm.so.5 => /lib/libm.so.5 (0x200a17000)
>libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000)
>libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000)
>libc.so.7 => /lib/libc.so.7 (0x200ca3000)
> 
> So, the runtime loader finds 6 instead of 716, tries to link, 
> fails, and issues an error message.  There are a number ways to
> fix this issue.
> 
> 1) By far, the best solution would be to stop hijacking the libgcc
>name in libraries installed on FreeBSD that are not related to
>actual GCC software.
> 
> % ls -l /lib/libgcc* /usr/lib/libgcc*
> (trimming lines)
> /lib/libgcc_s.so.1
> /usr/lib/libgcc.a@ -> libcompiler_rt.a
> /usr/lib/libgcc_eh.a
> /usr/lib/libgcc_eh_p.a
> /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a
> /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1
> 
>Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)?  Yes, I'm
>aware that clang does not work on all archs and the ancient gcc
>lives on.
> 
> 2) Given the expected push back againt solution 1), this solution
>proposes bumping the library version for /lib/libgcc_s.so.1 from
>1 to some larger value, say, 10.  It is unlikely that GCC will
>bump its shared library number anytime soon.  GCC bumped it from
>0 to 1 some 16 years ago.
> 
>https://gcc.gnu.org/viewcvs/gcc?view=revision=43316
> 
>This solution, however, papers over the general problem with
>name clashes.
> 
> 3) This solution is to actually fix the runtime loader.  If an error
>occurs with loading a shared library, then iterate over the entries
>in the hints file to check to see if another hint would satisfy
>the linking.  Here, instead of issuing the above error, the loader
>would find entry 716, and load the correct libgcc_s.so.1.
> 
>Admittedly, I haven't looked to see how difficult this solution
>would be.
>
> 4) Bump the shared library number of the individual ports.  As a proof
>of concept, I've done this with ports/lang/gcc6.
> 
> % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc 
> --- libgcc/config/t-slibgcc.orig2018-05-08 12:47:42.334495000 -0700
> +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700
> @@ -20,7 +20,7 @@
>  
>  SHLIB_EXT = .so
>  SHLIB_SOLINK = @shlib_base_name@.so
> -SHLIB_SOVERSION = 1
> +SHLIB_SOVERSION = 2
>  SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION)
>  SHLIB_MAP = @shlib_map_file@
>  SHLIB_OBJS = @shlib_objs@
> 
> % ldconfig -r | grep gcc_
>  6:-lgcc_s.1 => /lib/libgcc_s.so.1
>716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1
>766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2
> 
> % gfortran6 -o z h.f90
> % ./z
>  hello
> % ldd z
> z:
>libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000)
>libm.so.5 => /lib/libm.so.5 (0x20096c000)
>libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a)
>libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000)
>libc.so.7 => /lib/libc.so.7 (0x200df7000)
> 
>This works for this particular name conflict.  Hopefully, FreeBSD
>never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2.  This,
>however, introduces an incompatibility with what is actually distributed
>by GCC.
> 
> Finally, can people stop referring to the above error as
> "gfortran's FreeBSD issue".  This is a FreeBSD runtime loader issue.

libgcc_s.so implements the _Unwind_* API to handle stack unwinding.  This
code is shared between all compilers and languages because the stack can
contain frames from different compilers and languages.  So, you cannot
change the name or version of the library.

I've been testing the attached patch in combination with the ports tree
patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228046.

The patch makes three changes to /etc/rc.d/ldconfig:
1) Use 'sort -r' so /usr/local/lib/gcc7 appears before /usr/local/lib/gcc6.
2) Move hardcoded paths like /lib and /usr/lib to /etc/defaults/rc.conf
   so the order relative to other paths can be configured.
3) Change the order of 

Re: Conflicts due to renamed KDE4 ports

[Tijl Coosemans]

On Tue, 17 Apr 2018 16:19:39 +0200 Tobias C. Berner wrote:
> Long answer: KDE is shipped in mulitple, let's call them groups:
>   - frameworks (libraries to build kde and qt applications) -- we call
> these ports kf5-foo
>   - plasma (the desktop) -- we'll call these ports plasma5-foo
>   - applications (the applications)
> 
> Now, previously during KDE SC4 days, this was a whole "blob". This is why
> it made sense to call them all kde4-foo or foo-kde4.
> Now with this new split there is no real notion to call an application
> foo-kde5. For example during the transition in the last few
> years many KDE Application releases were a mix of Qt4 and Qt5 (i.e.
> kdelibs4 and kf5 based applications). So we would have had
> a kate-kde5 that was using kdelibs-kde4 ... well that would have been
> confusing too.
> 
> The same thing will eventually happen when the next KDE Frameworks will
> roll around I expect, where the applications get updated one after
> another, with mixed releases in between.
> 
> We opted for the same method as other ports use. A new version appears that
> is incompatible, move "bar/foo" to "bar/foo3" and update "bar/foo" in
> place.

I don't think this is the norm.  All the big ports (perl, python, php,
gcc, mysql, gtk, qt,...) just leave bar/foo and create bar/foo4.  In
place updating to an incompatible version can be a complete surprise
for users (POLA violation) and leave them with a broken system.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Tijl Coosemans]

On Tue, 17 Apr 2018 00:42:48 +0200 Adriaan de Groot  wrote:
> [where did this discussion take place, earlier? this is the first I've seen 
> it]
> 
> So, there are roughly two migration paths: supposing someone has x11/kde4 
> installed, which has dependencies on many applications and a Plasma 4 
> desktop, 
> kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop, 
> while renaming everything to have a -kde4 suffix. The other path is to 
> migrate 
> to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and 
> if we do get one it probably won't be called x11/kde5.
> 
> For single applications, the migration looks similar: you had, around january 
> 2018, port . That's the KDE4 version. Now there is port -kde4, if 
> you want to stick to KDE4 software (which is no longer released upstream, and 
> is based on an EOL toolkit, but some people feel quite strongly about this). 
> Ports  are returning, without a suffix, to mean "the latest-and-greatest-
> version-of-". This is consistent with other ports which have a , 
> sometimes a -devel for upcoming things, and a - for older 
> versions if you have specific dependencies on old versions.
> 
> Historically, things were a mess with naming with the KDE ports. We think 
> we've got a good scheme now: -kde4 (and in the far future, -kf5) 
> for 
> versions of the software based on an older stack, and  for the current 
> one. But the pain of getting from the mess to something better organized has 
> to happen at some point.

What happens when you run pkg upgrade on a 6 months old installation of KDE4?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Tijl Coosemans]

On Mon, 16 Apr 2018 20:11:33 +0200 Stefan Esser <s...@freebsd.org> wrote:
> Am 16.04.18 um 12:38 schrieb Tijl Coosemans:
>> On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser <s...@freebsd.org> wrote:  
>>> The way the new KDE5/KF5 ports have been introduced a few weeks back has
>>> caused me quite some effort (more than 100 hours of work), and now there
>>> have been further changes to implement KDE5 support (which I generally
>>> appreciate), which cause further complications and seem not to be well
>>> thought out.
>>>
>>> These problems affect at least all portmaster users, but I guess portupgrade
>>> is affected as well and a "pkg upgrade" dry-run indicates, that it will also
>>> cause breakage to binary upgrades of KDE4 installations.  
>> 
>> Removing entries from MOVED after only a few weeks is a bad idea, but
>> it's not something you have to worry about.  As long as portmaster
>> behaves more or less the same as pkg you're good.  
> 
> I only tried a dry run, but it appears, that pkg does not deal with this
> situation correctly. Grzegorz Junka reported, that it did not work for
> him and he had to manually delete all KDE ports and re-install them from
> his repository built with poudriere.
> 
> 
> A correct decision is impossible given on the information in the ports.
> 
> It is correct to upgrade e.g. databases/akonadi (akonadi-1.13.0_6) to
> databases/akonadi-kde4 (akonadi-kde4-1.13.0_7), but neither the origin
> nor package name nor a MOVED entry provide that information.
> 
> It is not correct to replace databases/akonadi (akonadi-1.13.0_6) by
> databases/akonadi (akonadi-17.12.3), but this can only be seen by
> checking the forward and backward dependencies (which are for KDE5/QT5
> instead of KDE4/QT4 of the installed port).
> 
> The same considerations applied to another port may lead to different
> results. While pkg requires exact dependencies to be installed, it is
> possible to use alternatives to satisfy dependencies with portmaster.
> And this feature is heavily used, e.g. to use a different version of
> samba than the default hard-wired into package dependencies. But this
> flexibility needs a basis for deciding, whether such a replacement is
> valid and how to perform upgrades in that situation.
> 
> 
> If akonadi is installed only as a dependency of other ports, then pkg will
> install the akonadi-kde4 version. But since the old version is installed
> as an in-use dependency of other KDE4 ports, it will not be removed before
> the installation of the new version is attempted (which will lead to an
> install conflict, since files of an installed port are to be overwritten).
> 
> It is possible to manually and forcefully delete akonadi-1.13.0_6 before
> starting pkg upgrade for the KDE4 ports that depend on it. In that case,
> there is no conflict. But pkg autodelete cannot be used, since to remove
> the dependency on the old version, the (conflicting) new version must be
> registered in the ports that depend on akonadi.
> 
> If akonadi has been directly installed and not (only) as a dependency,
> the akonadi-17.12.3 will be considered to be an upgrade of akonadi-1.13.*
> (same origin and same package name, except for the version numbers). This
> will remove the required dependency from the KDE4 ports and will register
> the KDE5 version as new dependency of those ports (although it completely
> useless in that role).
> 
> 
> When not even pkg can deal with this situation, how should portmaster?
> 
> The packages are built without consideration for the requirements of a
> running system, and pkg sees all the meta-information of all installed
> packages and the one being processed and can e.g. see, that files will
> conflict (which portmaster can only do after completely building the
> port, which means that this is long after the decision to use that port
> has been required).
> 
> 
> The lack of consideration given by port maintainers is quite frustrating,
> since it requires a lot of effort to work around the issues caused.

Like I said, IMHO it's not your problem, so you don't need to work around
it and you don't have to feel frustrated by it.  Without an entry in MOVED
there's no way for portmaster or pkg to know that the old akonadi needs to
be replaced with akonadi-kde4.  If any user contacts you about this you
can forward them to kde@ because they created the problem.

IMHO, entries in MOVED should stay for at least a year, if not several
years, so kde@ should restore the kde4 MOVED entries and give the kde5
ports a -kde5 suffix or something.  Hopefully there aren't that many users
yet because you can't create MOVED entries for this move.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Conflicts due to renamed KDE4 ports

[Tijl Coosemans]

On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser  wrote:
> The way the new KDE5/KF5 ports have been introduced a few weeks back has
> caused me quite some effort (more than 100 hours of work), and now there
> have been further changes to implement KDE5 support (which I generally
> appreciate), which cause further complications and seem not to be well
> thought out.
> 
> These problems affect at least all portmaster users, but I guess portupgrade
> is affected as well and a "pkg upgrade" dry-run indicates, that it will also
> cause breakage to binary upgrades of KDE4 installations.

Removing entries from MOVED after only a few weeks is a bad idea, but
it's not something you have to worry about.  As long as portmaster
behaves more or less the same as pkg you're good.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: reccomendation for a building architecture schematic diagram editor ?

[Tijl Coosemans]

On Mon, 16 Apr 2018 10:21:20 +0200 "Julian H. Stacey"  wrote:
> Hi po...@freebsd.org people,
> Might any of you have a FreeBSD ports/ reccomendation for a building
> architecture schematic diagram editor, please ? To plan eg big house room
> layouts { furniture moves, building sale / rent} etc ?
> 
> I'm not looking for professional architects or structural engineers
> tools to plan new buildings.  I'm not looking for millimetre precise
> kitchen layout programs if such exist, I'm just looking to produce
> the sort of plan one gets from estate agents, and on landlord/
> tenant rental contracts etc.
> 
> I searched, but nothing from https://www.freebsd.org/cgi/ports.cgi
> 
> Only port I can think of is xfig, which I've used for other things
>   https://svnweb.freebsd.org/ports/head/graphics/xfig/
> but wondering if something else more appropriate exists ?
> 
> Looking for something to tart up my hand sketches & a raft of
> measurements hand written on them, taken from a laser measurer.
> 
> I'm not looking to include a bluetooth professional laser measurer
> to PC/android data transfer, though they exist, I just bought a
> much cheaper simple laser measurer, & content to hand edit.

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

Re: pkg fallout - wrong shared lib version?

[Tijl Coosemans]

On Tue, 20 Feb 2018 18:13:07 -0500 "Jason E. Hale"  wrote:
> On Tue, Feb 20, 2018 at 12:36 PM, Anton Shterenlikht  wrote:
>> My port lang/opencoarrays gives this error
>> via pkg-fallout:
>>
>> ...
>> -- Installing: 
>> /wrkdirs/usr/ports/lang/opencoarrays/work/stage/usr/local/lib/libcaf_mpi.so.1
>> ...
>>  
>> ===>  Building package for opencoarrays-1.9.3  
>> pkg-static: Unable to access file 
>> /wrkdirs/usr/ports/lang/opencoarrays/work/stage/usr/local/lib/libcaf_mpi.so.2:No
>>  such file or directory
>>
>> On the system where I did the testing I get:
>>
>> # pkg info -xl opencoarr
>> opencoarrays-1.9.3:
>> ...
>> /usr/local/lib/libcaf_mpi.so.2
>>
>> Accrdingly I put
>>
>> lib/libcaf_mpi.so.2
>>
>> in pkg-plist
>>
>> Where did I go wrong?
> 
> I just took a quick look at the port and src/mpi/CMakeLists.txt is
> setting the SOVERSION differently depending on which version the
> Fortran compiler is:
> 
> set(CAF_SO_VERSION 0)
> if(gfortran_compiler)
>   if(NOT CMAKE_Fortran_COMPILER_VERSION VERSION_LESS 7.0.0)
> set(CAF_SO_VERSION 2)
>   elseif(NOT CMAKE_Fortran_COMPILER_VERSION VERSION_LESS 6.0.0)
> set(CAF_SO_VERSION 1)
>   endif()
> endif()
> 
> You will probably have to do a check for the compiler version and
> adjust pkg-plist accordingly.
> 
> I've CC'd tijl since he landed this.

Should be fixed in r462483.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

On Mon, 15 Jan 2018 18:37:47 +0100 Dimitry Andric  wrote:
> On 15 Jan 2018, at 11:43, Luca Pizzamiglio  wrote:
>> I've already received a couple of messages from pkg-fallout about build
>> failure on head-i386-default [1] [2] both pointing to the same errors,
>> about missing intrinsic symbols related to __atomic_*
>> 
>> The clang documentation about C11 atomic builtins [3] stats that __atomic_*
>> are GCC extension and Clang provides them.
>> 
>> It seems to me that this specific GCC-compatible builtin are enabled on
>> amd64, but not on i386.
>> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
>> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
>> for every ports that need it ?
> 
> There is some strangeness going on with an upstream bug fix [1], which
> has the unintended side effect of sometimes emitting libcalls to
> __atomic functions that we do not have on i386.  I've commented on the
> upstream bug report, but I do not know an easy workaround at this
> point.
> 
> [1] https://bugs.llvm.org/show_bug.cgi?id=34347

It looks to me clang is doing fewer libcalls now and more inlining,
which is why the configure tests succeed now.  That clang generates
cmpxchg8b on i486 has always been the case.  The fix for 34347 exposes
this more now.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

On Mon, 15 Jan 2018 17:08:58 + David Chisnall  wrote:
> On 15 Jan 2018, at 17:00, Jan Beich  wrote:
>> It wouldn't help (see below). Clang 6 accidentally made __atomic* work
>> enough to satisfy configure check but not for the port to build. I guess,
>> it also confuses configure in net/librdkafka and net-mgmt/netdata.
> 
> Can we (by which I probably mean emaste@) push out an EN that adds the
> atomic.c from compiler-rt to our libgcc_s?  That should provide all of
> these helper functions.  Clang assumes that they exist because both
> compiler-rt and vaguely recent libgcc_s provide them.  Recent GCC will
> also assume that they exist and so the correct fix is probably for us
> to make them to exist.
> 
> If this is difficult, then we can perhaps provide a port that compiles
> atomic.c into libatomic_fudge.so or similar and provides a libgcc_s.so
> that’s a linker script that forces linking to libatomic_fudge.so and
> libgcc_s.so.

I can understand emitting function calls on i486 but according to Jan,
clang is emitting function calls on i586 as well.  It used to inline
this which is why we never needed these functions in libgcc.  Is it
normal that clang emits function calls now?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

On Mon, 15 Jan 2018 11:43:44 +0100 Luca Pizzamiglio  
wrote:
> I've already received a couple of messages from pkg-fallout about build
> failure on head-i386-default [1] [2] both pointing to the same errors,
> about missing intrinsic symbols related to __atomic_*
> 
> The clang documentation about C11 atomic builtins [3] stats that __atomic_*
> are GCC extension and Clang provides them.
> 
> It seems to me that this specific GCC-compatible builtin are enabled on
> amd64, but not on i386.
> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
> for every ports that need it ?
> 
> [1]
> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/librdkafka-0.11.3.log
> [2]
> http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/stress-ng-0.09.09.log
> [3] https://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic

8 byte atomics requires at least i586.  So either find a way to disable
the use of these atomics in these ports or add something like this to
the port Makefile.

.if ${ARCH} == i386 && ! ${MACHINE_CPU:Mi586}
CFLAGS+=-march=i586
.endif
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Why portmaster try to install python 3.6 when I have 3.4 set in /etc/make.conf?

[Tijl Coosemans]

On Wed, 10 Jan 2018 21:59:17 +0100 Stefan Esser  wrote:
> Am 10.01.18 um 21:30 schrieb Stefan Esser:
>> Am 10.01.18 um 17:29 schrieb Lev Serebryakov:  
>>> I have system with pre-FLAVORed ports installed, and try to update
>>> ports with new version of "portmaster". My "/etc/make.conf" contains:
>>>
>>> DEFAULT_VERSIONS+=  python2=2.7
>>> DEFAULT_VERSIONS+=  python3=3.4
>>> DEFAULT_VERSIONS+=  python=3.4
>>>
>>>  But "portmaster -a" try to install python 3.6:
>>>  
>>> ===>>> All >> py34-pip-9.0.1 (12/12)
>>> ===>>> The devel/py3-pip port moved to devel/py-pip@py36
>>> ===>>> Reason: Moved to a flavored, generic, version  
>>> [...]  
>>> ===>>> All >> py34-pip-9.0.1 >> devel/py-setuptools@py36 >>  
>>> lang/python36 (14/14)  
>> 
>> Another example that the FLAVOR feature is not well designed :(
>> 
>> The entry in /usr/ports/MOVED maps devel/py3-pip to devel/py-pip@py36
>> even though building that port with FLAVOR=py34 builds the correct
>> version with the expected dependency on Python-3.4.
>> 
>> If at least the output of "make pretty-flavors-package-names" did hint
>> at the existence of a package for FLAVOR=py34, I could make portmaster
>> override the wrong FLAVOR obtained from the MOVED file.
>> 
>> But the output of that command is:
>> 
>> $ cd /usr/ports/devel/py-py
>> $ make pretty-flavors-package-names
>> py27: py27-py-1.5.2
>> py36: py36-py-1.5.2  
> 
> I have just checked, that the ports infrastructure already kind of
> supports this case. With PYTHON3_DEFAULT=3.4 set in /etc/make.conf,
> it is possible to determine the flavor that corresponds to the
> package to be upgraded:
> 
> $ PYTHON3_DEFAULT=3.4 make pretty-flavors-package-names

You're not supposed to set PYTHON3_DEFAULT directly.  Users should set
DEFAULT_VERSIONS=python3=3.4, like Lev showed above.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: What to do when SCons-based project tries to open $LDFLAGS value as a file?

[Tijl Coosemans]

On Thu, 28 Dec 2017 23:35:00 -0800 Yuri  wrote:
> I am getting this error from scons:
> 
>> g++6 -o lib/libtmv.so.0 " -L/usr/local/lib -fstack-protector   
>> -Wl,-rpath=/usr/local/lib/gcc6 -L/usr/local/lib/gcc6" -fopenmp -shared ...
>>
>> g++6: error:  -L/usr/local/lib -fstack-protector   
>> -Wl,-rpath=/usr/local/lib/gcc6 -L/usr/local/lib/gcc6: No such file or 
>> directory
> 
> It tries to open LDFLAGS that were passed to it as LINKFLAGS as a file.

Figure out where the double quotes come from and remove that.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Linux ports tutorial? WPS Office

[Tijl Coosemans]

On Thu, 14 Dec 2017 18:27:10 -0500 Pedro Giffuni  wrote:
> The port still doesn't work:
> - It appears it wants to use a old version of libpng that is not in our 
> centos7.
> - USE_RPM doesn't install anything, it seems like we are missing support 
> for non-base RPMs.
> 
> I think I'll bail on this port, it requires some packaging-foo that I 
> don't want to spend time on.
> 
> I'll leave my WIP here, for someone else to play with it:
> 
> https://people.freebsd.org/~pfg/ports/linux-wps-office.tgz

USE_LINUX_RPM is only for Linux infrastructure ports.  You should remove
that and add your own do-install.  You also need NO_WRKSUBDIR=yes and
PLIST_SUB=LINUXBASE=${LINUXBASE}.

The do-install target should copy WRKSRC/opt and WRKSRC/usr/bin to
${STAGEDIR}${LINUXBASE}.  WRKSRC/etc and WRKSRC/usr/share look like
they should go to ${STAGEDIR}${PREFIX}.

Then you also need to add startup scripts for et, wpp and wps containing
something like this:

#! /bin/sh
exec /compat/linux/bin/sh /usr/bin/et "$@"

And let do-install copy them to ${STAGEDIR}${PREFIX/bin.

You also need to replace /usr/bin with ${PREFIX} in .desktop files.

I would also add -office to PORTNAME and remove PKGNAMESUFFIX.

The old libpng it is looking for is in CentOS 6, so USES=linux:c7 won't
work.  For now it's best to simply use USES=linux.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FireFox memory usage

[Tijl Coosemans]

On Wed, 01 Nov 2017 21:10:13 +0100 Jan Beich  wrote:
> Jan Beich  writes:
>> Andrea Venturoli  writes:
>>> I'm on 10.3/amd64 with firefox-esr 52.3.0.
>>>
>>> Since a few days my 4GiB desktop is crawling due to swap usage and
>>> looking at top, I see FireFox using almost 7GiB of RAM (SIZE column),
>>> 2.5 of which are "RES".  
>>
>> Check about:memory and Devolper Tools -> Memory for clues. For more
>> advanced debugging (DMD, Refcount tracing) you'd need a custom build.
>>
>> Firefox on FreeBSD is known to consume more memory than on other
>> platforms because it uses system jemalloc rather than mozjemalloc.
>> Mozilla doesn't test memory usage without mozjemalloc. However, porting
>> mozjemalloc has stalled[1] unless someone helps.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1153683  
> 
> If one is on Firefox 55+ or FreeBSD 12+ while suboptimal compared to
> mozjemalloc the old jemalloc4 optimizations can be restored by
> 
>   $ MALLOC_CONF="narenas:1,tcache:false" firefox ...
> 
> https://dxr.mozilla.org/mozilla-esr52/source/memory/build/jemalloc_config.cpp#35

This appears to be such a huge improvement that you should really put
this in the port even if it's still not as good as mozjemalloc.

You may also want to add the firefox patch attached to bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222356.  It reduces
disk I/O, which is a big performance improvement on older systems with
slow disks.  The kernel patches in that bug remove over 90% of the I/O
but not all, and FreeBSD releases don't have those patches yet.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: po/Makefile.in.in was not created by intltoolize."

[Tijl Coosemans]

On Thu, 26 Oct 2017 01:11:55 +0800 blubee blubeeme  wrote:
> I found this really old thread:
> https://mail.gnome.org/archives/gtkmm-list/2009-August/msg00072.html
> 
> and this really old script to "work around" the issue.
> 
> #! /bin/sh -etest -n "$srcdir" || srcdir=`dirname "$0"`test -n
> "$srcdir" || srcdir=.(
>   cd "$srcdir" &&
>   AUTOPOINT='intltoolize --automake --copy' autoreconf --force
> --install --verbose) || exittest -n "$NOCONFIGURE" ||
> "$srcdir/configure" "$@"
> 
> 
> 
> Do I just have to implement this in the ports Makefile or is there some
> workaround?

Just add USES=autoreconf and USE_GNOME=intltool to your Makefile.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Makefile cannot download from Sourceforge

[Tijl Coosemans]

On Tue, 17 Oct 2017 00:32:26 +0800 blubee blubeeme  wrote:
> I'm trying to download some files from sourceforge but it fails constantly.
> 
> PORTNAME= zipios++
> PORTVERSION=  2.1.1
> MASTER_SITES= SF/zipios/

It looks like this should be SF/zipios/${PORTNAME}/${PORTVERSION}

> DISTFILES=zipios-2.1.1.tar.gz
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Using blaslapack

[Tijl Coosemans]

On Mon, 16 Oct 2017 09:20:26 +0300 Gleb Popov <6year...@gmail.com> wrote:
> I'm porting an application (DLib, https://reviews.freebsd.org/D12559) that
> uses BLAS and LAPACK, and I have some questions.
> 
> 1. Is there any pure C implementation that does not require Fortran
> compiler?

Probably not, BLAS and LAPACK are Fortran libraries.  Any implementation
in C still provides Fortran wrappers.  And often these implementations
only implement performance critical functions and use the original
Fortran for everything else.

> 2. My application looks for cblas_ddot function in BLAS library, but the
> default library (netlib) doesn't seem to have that. It has ddot, though, so
> I'm not sure if it is a wrong check on app's side, or netlib is indeed
> doesn't suit there. For now I've used openblas, but I'm also not sure if it
> is a right choice.

It's part of CBLAS which is also included in OpenBLAS.

> 3. How to link properly to any of BLAS libraries? All BLAS implementations
> blaslapack.mk features require Fortran. This implies USE_GCC=yes, so these
> are compiled with GCC, not Clang. Now when I try to link Clang-compiled
> DLib to GCC-compiled openblas, I get undefined references:
> 
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__getf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatunditf@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__subtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__multf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__unordtf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__lttf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__addtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__gttf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__divtf3@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__letf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__netf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatditf@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__eqtf2@GCC_4.6.0'
> //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to
> `__floatsitf@GCC_4.6.0'
> 
> I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is
> also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this
> is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath
> as advised by lang/gcc6 pkg-message doesn't help. The only workaround I
> came up with is USE_GCC=yes to compile DLib itself, but that's pretty
> unsatisfactory.

This is a known problem.  If your port depends on another port that
has USES=fortran the easiest is to add USES=fortran to your port as
well.  C code will still be built with Clang then.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gnu ltdl and FreeBSD

[Tijl Coosemans]

On Mon, 16 Oct 2017 10:44:42 +0200 Tijl Coosemans <t...@freebsd.org> wrote:
> On Mon, 16 Oct 2017 13:37:57 +0800 blubee blubeeme <gurenc...@gmail.com> 
> wrote:
>> CONFIGURE_ARGS=  --without-included-ltdl --disable-ltdl-install
>> USES=autoreconf gmake  
> 
> Here you should add "libtool" to USES.

You may also have to add "localbase".
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gnu ltdl and FreeBSD

[Tijl Coosemans]

On Mon, 16 Oct 2017 13:37:57 +0800 blubee blubeeme  wrote:
> I'm trying to port some software that keeps failing when it tries to find a
> config.h.
> 
> I know the config.h file is there but I think the compilation is failing
> because it's trying to build ltdl and freebsd doesn't need that since
> freebsd already has dlopen in libc.
> 
> Which configure flag could I try to get rid of building that lib? The full
> configure --help file is below.
> 
> My current makefile has these settings:
> HAS_CONFIGURE=   yes

This should be GNU_CONFIGURE=yes.

> CONFIGURE_ARGS=  --without-included-ltdl --disable-ltdl-install
> USES=autoreconf gmake

Here you should add "libtool" to USES.

And maybe the code really needs libltdl.  See if there are any calls to
lt_dlinit or lt_dlopen.  You can then add this dependency:

LIB_DEPENDS=libltdl.so:devel/libltdl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: INSTALL_TARGET=install-strip runs into "permission denied"

[Tijl Coosemans]

On Mon, 24 Apr 2017 21:03:22 +0200 (CEST) Gerald Pfeifer <ger...@pfeifer.com> 
wrote:
> On Sun, 23 Apr 2017, Tijl Coosemans wrote:
>>> [ https://reviews.freebsd.org/D10357 ]  
>> Yes, but in my opinion we should stop relying on upstream build systems
>> to get stripping right and let bsd.port.mk strip ELF files after staging.
>> It's less work for maintainers.  Then instead of stripping, bsd.port.mk
>> could also extract debug symbols into separate files and put them into a
>> debug subpackage.  
> 
> Yes, that sounds a lot more reliable and maintainable (and overall
> less work compared to patching hundreds of ports).
> 
> Until something like this is in place, should we ignore those
> complaints from the QA framework or patch individual ports?

That's not my decision to make.  It's not that important for gcc I think.
The only reason to strip files is to make them a bit smaller and gcc is
not going to be installed on space constrained systems where this matters.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: INSTALL_TARGET=install-strip runs into "permission denied"

[Tijl Coosemans]

On Sat, 22 Apr 2017 22:37:57 +0200 (CEST) Gerald Pfeifer <ger...@pfeifer.com> 
wrote:
> [ Old thread alert, but still relevant. ]
> 
> On Mon, 19 Jan 2015, Tijl Coosemans wrote:
>>>>> install   -m 555 mkheaders 
>>>>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/mkheaders
>>>>> test -z 'strip' || strip 
>>>>> .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl
>>>>> strip: unable to copy file 
>>>>> '.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl';
>>>>>  reason: Permission denied
>>>>> Makefile:191: recipe for target 'install-strip' failed
>>>>> gmake[3]: *** [install-strip] Error 1  
>>>> This strip command seems redundant.  Isn't fixincl already stripped by
>>>> the "install -s" command above?  
>>> Good point.
>>>   
>>>> What does this piece of the log look like outside the ports framework?  
>>> 
>>> /usr/bin/install -c fixinc.sh 
>>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixinc.sh
>>> /usr/bin/install -c fixincl 
>>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
>>> /usr/bin/install -c mkheaders 
>>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/mkheaders
>>> test -z 'strip' || strip 
>>> .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
>>> gmake[2]: Leaving directory '.../OBJ-0118-1528/fixincludes'
>>> 
>>> (I also tried setting STRIP_CMD to true, alas that is not used by GCC.)  
>> Try adding BINMODE=755 to the port Makefile or STRIP=true to CONFIGURE_ARGS  
> 
> Both of these allow the build to succeed as a regular user (non-root), 
> when INSTALL_TARGET=install-strip is set.
> 
> Alas with STRIP=true many files end up being not stripped, whereas with 
> the BINMODE setting the list is down to one file.
>   
> This appears to be the case since various aspects of GCC do not use our
> install-* tools, but a script install-sh (which you can find at the root 
> of the GCC source tree that uses cp, chmod, strip,... for compatibility 
> reasons with many systems).
> 
> So I guess setting BINMODE=755 is the best option if we want binaries
> and libraries in the gcc* ports stripped?
> 
> 
> (This is now also tracked in https://reviews.freebsd.org/D10357 where
> miwi proposed a patch originally.)

Yes, but in my opinion we should stop relying on upstream build systems
to get stripping right and let bsd.port.mk strip ELF files after staging.
It's less work for maintainers.  Then instead of stripping, bsd.port.mk
could also extract debug symbols into separate files and put them into a
debug subpackage.  Using something like this:

objcopy --only-keep-debug file file.debug
objcopy -S --add-gnu-debuglink=file.debug file
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Fri, 21 Apr 2017 00:18:53 +0200 Mathieu Arnold  wrote:
> Le 21/04/2017 à 00:16, Baptiste Daroussin a écrit:
>> On Fri, Apr 21, 2017 at 12:13:52AM +0200, Mathieu Arnold wrote:
>>> I am waiting on an exp-run to fix this once and for all.
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218067
>>>
>>> When that is committed, anything can be added to the path pkgconfig
>>> searches, ports will always install it in the right place.
>>
>> Sorry but why? why not moving libdata/pkgconfig to lib/pkgconfig? what
>> is the rationale?
>
> Because a lot of build software know that on FreeBSD, the .pc file go
> in libdata/pkgconfig. If we move to some other place, we'll have a
> USES=pathfixmore for the next 25 years until everyone understands we
> moved it some place else.

1. It's not a lot.  Certainly the amount of software that does not know
   about libdata is way bigger.
2. You don't need USES=pathfixmore, you just change the fixup target
   in your patch to move files in the other direction.  This fixup can
   then be removed in 25 years (less if you let it print a warning)
   while your fixup will have to be kept forever.
3. Proper porting of emulators/wine to amd64 requires building 32 bit
   versions of dependencies.  Their pkgconfig files would go to
   lib32/pkgconfig when configured with --libdir=${PREFIX}/lib32 while
   something like libdata/pkgconfig32 would require yet more patches
   and fixups.

Any difference from Linux makes porting work harder, so there should be
good reasons and there are none whatsoever to use libdata/pkgconfig over
lib/pkgconfig.  I really don't get why portmgr keeps blocking this
change every time it comes up in the past few years.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg checksum mismatch for a variety of ports

[Tijl Coosemans]

On Wed, 15 Mar 2017 14:55:00 + tech-lists  wrote:
> Hello ports@,
> 
> What's the significance of this and what can I do about it? Deinstalling
> and reinstalling doesn't help. These were installed with ports r436245
> on 11.0-stable r314138:
> 
> # pkg check -s
> 
> Checking all packages:   3%
> bluefish-2.2.10: checksum mismatch for
> /usr/local/share/applications/mimeinfo.cache
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/XMLnamespaces
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/aliases
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/generic-icons
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/globs
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/globs2
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/icons
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/magic
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/mime.cache
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/subclasses
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/treemagic
> bluefish-2.2.10: checksum mismatch for /usr/local/share/mime/types
> Checking all packages:   4%
> calibre-2.81.0: checksum mismatch for
> /usr/local/share/mime/application/epub+zip.xml
> calibre-2.81.0: checksum mismatch for
> /usr/local/share/mime/application/x-mobipocket-ebook.xml
> 
> thanks

It's a problem with the packaging.  "--disable-update-databases" should
be added to CONFIGURE_ARGS in www/bluefish/Makefile.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: bsd.sites.mk: Do we prefer http or https (or both)

[Tijl Coosemans]

On Mon, 13 Mar 2017 09:32:13 -0600 Adam Weinberger <ad...@adamw.org> wrote:
> On 13 Mar, 2017, at 7:32, Tijl Coosemans <t...@freebsd.org> wrote:
>> On Sat, 11 Mar 2017 14:25:13 -0700 Adam Weinberger <ad...@adamw.org>
>> wrote:
>>>> On 11 Mar, 2017, at 12:53, Adam Weinberger <ad...@adamw.org> wrote:
>>>>> On 11 Mar, 2017, at 12:29, Tijl Coosemans <t...@freebsd.org> wrote:
>>>>> On Sat, 11 Mar 2017 10:18:18 -0700 Adam Weinberger <ad...@adamw.org>
>>>>> wrote:
>>>>>> On 11 Mar, 2017, at 10:13, Tijl Coosemans <t...@freebsd.org>
>>>>>> wrote:
>>>>>>> On Sat, 11 Mar 2017 12:18:51 + (UTC) jbe...@freebsd.org (Jan
>>>>>>> Beich) wrote:
>>>>>>>> Tijl Coosemans <t...@freebsd.org> writes:
>>>>>>>>> On Sat, 11 Mar 2017 10:53:01 +0100 (CET) Gerald Pfeifer
>>>>>>>>> <ger...@pfeifer.com> wrote:
>>>>>>>>>> As some of you may have seen, I have done a bit of work on
>>>>>>>>>> bsd.sites.mk recently.
>>>>>>>>>> 
>>>>>>>>>> One question I ran into:  If a site offers both HTTPS and
>>>>>>>>>> HTTP, which of the two do we prefer?  (Or do we want to list
>>>>>>>>>> both?)
>>>>>>>>> 
>>>>>>>>> https first for people that run 'make makesum'.
>>>>>>>> 
>>>>>>>> It was made MITM-friendly sometime ago.
>>>>>>>> 
>>>>>>>> https://svnweb.freebsd.org/changeset/ports/324051
>>>>>>> 
>>>>>>> Ugh, can portmgr approve the attached patch?
>>>>>> 
>>>>>> If distfiles from sites with invalid certificates won't fetch for
>>>>>> end-users, they won't fetch during makesum either.
>>>>> 
>>>>> - Given that web browsers have become much less forgiving about such
>>>>>  certificates this is probably much less of a problem nowadays.
>>>>> - Possibly, many of these errors are because users forgot to install
>>>>>  ca_root_nss.  We can hold port maintainers to a higher standard and
>>>>>  expect them to have this installed.
>>>>> - Such sites should perhaps be removed from MASTER_SITES.  If
>>>>>  that's not possible FETCH_ENV can be set in the port Makefile.
>>>> 
>>>> I don't disagree with any point. Do you want to submit a PR so that
>>>> an exp-run of sorts can see how many distfiles we're talking about?
>>> 
>>> Antoine reminded me that this only affects makesum, so I guess there's
>>> really no way of telling what ports this would affect. Either way,
>>> your reasoning is sound and you've convinced me. I'm good with this
>>> change; as you said, worst-case scenario, ports with broken
>>> MASTER_SITES can override FETCH_ENV or a toggle can be added.
>> 
>> Committed in r436081.
>
> Can you please add a quick blurb about this to CHANGES?

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

Re: bsd.sites.mk: Do we prefer http or https (or both)

[Tijl Coosemans]

On Sat, 11 Mar 2017 14:25:13 -0700 Adam Weinberger <ad...@adamw.org>
wrote:
>> On 11 Mar, 2017, at 12:53, Adam Weinberger <ad...@adamw.org> wrote:
>>> On 11 Mar, 2017, at 12:29, Tijl Coosemans <t...@freebsd.org> wrote:
>>> On Sat, 11 Mar 2017 10:18:18 -0700 Adam Weinberger <ad...@adamw.org>
>>> wrote:
>>>> On 11 Mar, 2017, at 10:13, Tijl Coosemans <t...@freebsd.org>
>>>> wrote:
>>>>> On Sat, 11 Mar 2017 12:18:51 + (UTC) jbe...@freebsd.org (Jan
>>>>> Beich) wrote:
>>>>>> Tijl Coosemans <t...@freebsd.org> writes:
>>>>>>> On Sat, 11 Mar 2017 10:53:01 +0100 (CET) Gerald Pfeifer
>>>>>>> <ger...@pfeifer.com> wrote:
>>>>>>>> As some of you may have seen, I have done a bit of work on
>>>>>>>> bsd.sites.mk recently.
>>>>>>>> 
>>>>>>>> One question I ran into:  If a site offers both HTTPS and
>>>>>>>> HTTP, which of the two do we prefer?  (Or do we want to list
>>>>>>>> both?)
>>>>>>> 
>>>>>>> https first for people that run 'make makesum'.
>>>>>> 
>>>>>> It was made MITM-friendly sometime ago.
>>>>>> 
>>>>>> https://svnweb.freebsd.org/changeset/ports/324051
>>>>> 
>>>>> Ugh, can portmgr approve the attached patch?
>>>> 
>>>> If distfiles from sites with invalid certificates won't fetch for
>>>> end-users, they won't fetch during makesum either.
>>> 
>>> - Given that web browsers have become much less forgiving about such
>>>   certificates this is probably much less of a problem nowadays.
>>> - Possibly, many of these errors are because users forgot to install
>>>   ca_root_nss.  We can hold port maintainers to a higher standard and
>>>   expect them to have this installed.
>>> - Such sites should perhaps be removed from MASTER_SITES.  If
>>>   that's not possible FETCH_ENV can be set in the port Makefile.
>> 
>> I don't disagree with any point. Do you want to submit a PR so that
>> an exp-run of sorts can see how many distfiles we're talking about?
>
> Antoine reminded me that this only affects makesum, so I guess there's
> really no way of telling what ports this would affect. Either way,
> your reasoning is sound and you've convinced me. I'm good with this
> change; as you said, worst-case scenario, ports with broken
> MASTER_SITES can override FETCH_ENV or a toggle can be added.

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

Re: Flashplayer issue

[Tijl Coosemans]

On Sun, 12 Mar 2017 08:45:53 -0600 The Doctor  wrote:
> Installing linux-flashplayer-24.0.0.221...
> pkg-static: linux-flashplayer-24.0.0.221 conflicts with 
> linux-c7-flashplugin-24.0.0.186 (installs files into the same place).  
> Problematic file: 
> /usr/local/lib/browser_plugins/symlinks/linux-firefox/libflashplayer.so
> *** Error code 70

What is it about this message that you don't understand?  Because then
we need to improve the wording.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: bsd.sites.mk: Do we prefer http or https (or both)

[Tijl Coosemans]

On Sat, 11 Mar 2017 10:18:18 -0700 Adam Weinberger <ad...@adamw.org>
wrote:
> On 11 Mar, 2017, at 10:13, Tijl Coosemans <t...@freebsd.org> wrote:
>> On Sat, 11 Mar 2017 12:18:51 + (UTC) jbe...@freebsd.org (Jan
>> Beich) wrote:  
>>> Tijl Coosemans <t...@freebsd.org> writes:  
>>>> On Sat, 11 Mar 2017 10:53:01 +0100 (CET) Gerald Pfeifer
>>>> <ger...@pfeifer.com> wrote:  
>>>>> As some of you may have seen, I have done a bit of work on
>>>>> bsd.sites.mk recently.
>>>>> 
>>>>> One question I ran into:  If a site offers both HTTPS and HTTP, 
>>>>> which of the two do we prefer?  (Or do we want to list both?)
>>>> 
>>>> https first for people that run 'make makesum'.
>>> 
>>> It was made MITM-friendly sometime ago.
>>> 
>>> https://svnweb.freebsd.org/changeset/ports/324051  
>> 
>> Ugh, can portmgr approve the attached
>> patch?___  
> 
> If distfiles from sites with invalid certificates won't fetch for
> end-users, they won't fetch during makesum either.

- Given that web browsers have become much less forgiving about such
  certificates this is probably much less of a problem nowadays.
- Possibly, many of these errors are because users forgot to install
  ca_root_nss.  We can hold port maintainers to a higher standard and
  expect them to have this installed.
- Such sites should perhaps be removed from MASTER_SITES.  If that's not
  possible FETCH_ENV can be set in the port Makefile.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: bsd.sites.mk: Do we prefer http or https (or both)

[Tijl Coosemans]

On Sat, 11 Mar 2017 12:18:51 + (UTC) jbe...@freebsd.org (Jan Beich) wrote:
> Tijl Coosemans <t...@freebsd.org> writes:
>> On Sat, 11 Mar 2017 10:53:01 +0100 (CET) Gerald Pfeifer <ger...@pfeifer.com> 
>> wrote:
>>> As some of you may have seen, I have done a bit of work on
>>> bsd.sites.mk recently.
>>> 
>>> One question I ran into:  If a site offers both HTTPS and HTTP, 
>>> which of the two do we prefer?  (Or do we want to list both?)  
>>
>> https first for people that run 'make makesum'.  
> 
> It was made MITM-friendly sometime ago.
> 
> https://svnweb.freebsd.org/changeset/ports/324051

Ugh, can portmgr approve the attached patch?Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk	(revision 435950)
+++ Mk/bsd.port.mk	(working copy)
@@ -2007,7 +2007,9 @@ BUILD_FAIL_MESSAGE+=	Try to set MAKE_JOB
 
 .include "${PORTSDIR}/Mk/bsd.ccache.mk"
 
+.if !make(makesum)
 FETCH_ENV?=		SSL_NO_VERIFY_PEER=1 SSL_NO_VERIFY_HOSTNAME=1
+.endif
 FETCH_BINARY?=	/usr/bin/fetch
 FETCH_ARGS?=	-Fpr
 FETCH_REGET?=	1
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: bsd.sites.mk: Do we prefer http or https (or both)

[Tijl Coosemans]

On Sat, 11 Mar 2017 10:53:01 +0100 (CET) Gerald Pfeifer  
wrote:
> As some of you may have seen, I have done a bit of work on
> bsd.sites.mk recently.
> 
> One question I ran into:  If a site offers both HTTPS and HTTP, 
> which of the two do we prefer?  (Or do we want to list both?)

https first for people that run 'make makesum'.
http second for people that can't use https.

For pkg-descr WWW I always use https if available.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Fri, 10 Mar 2017 08:38:30 -0800 Steve Kargl 
<s...@troutmask.apl.washington.edu> wrote:
> On Fri, Mar 10, 2017 at 05:03:08PM +0100, Tijl Coosemans wrote:
>> On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav <d...@des.no> wrote:  
>>> John Baldwin <j...@freebsd.org> writes:  
>>>> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
>>>> so long as our default MANPATH included both if that means applying fewer
>>>> patches to ports.
>>> 
>>> The default MANPATH is constructed dynamically from PATH:
>>> 
>>>  1.   From each component of the user's PATH for the first of:
>>>   -   pathname/man
>>>   -   pathname/MAN
>>>   -   If pathname ends with /bin: pathname/../man
>>>   Note: Special logic exists to make /bin and /usr/bin look in
>>>   /usr/share/man for manual files.
>>> 
>>> If we change this to:
>>> 
>>>  1.   From each component of the user's PATH for the first of:
>>>   -   pathname/man
>>>   -   pathname/MAN
>>>   -   If pathname ends with /bin or /sbin: pathname/../man and
>>>   pathname/../share/man
>>> 
>>> we wouldn't need any "special logic", but I really don't like the idea
>>> of having different ports installing man pages in different locations.  
>> 
>> I grepped the ports tree and found nearly 5700 ports.  That's a lot to
>> change all at once but it may be doable.  It depends on how much fallout
>> there is in the exp-run.  
> 
> ln -s /usr/local/share/man /usr/local/man
> 
> should cause the manpages to land where you want.  Then port
> maintainers can sweep ports/ to allow for the removal of symlink. 

Yeah, I had to deal with installing through symlinks in the Linux ports
because bin, lib and sbin have become symlinks there now.  There are
complications with that.  FreeBSD releases have a bug in libarchive that
causes problems when extracting hardlinks through symlinks.  Recent
versions of pkg have workarounds for that but not everybody runs it yet.
Before you can create the symlink you have to move the existing
directory, but what if the new directory already exists?  Will you
overwrite files?  Commands like pkg-which and pkg-delete only work
through the symlink because the new paths are not in the pkg database.
Packages that don't know about the symlink may try to create it as a
directory or remove it as a directory on uninstall.  I ended up avoiding
it at all costs in the Linux ports by moving files around in the staging
area if necessary.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Tue, 7 Mar 2017 00:56:10 +0100 Baptiste Daroussin  wrote:
> My proposal is to add to the manpath /usr/local/share/man in default
> man(1) command in FreeBSD 12 (MFCed to 11-STABLE)
> 
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that
> for those two, what do you think?

I don't think we can expect users to install the latest errata or to
run the latest head or stable, so a port would be needed.  Could the
pkg port be used for this?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav  wrote:
> John Baldwin  writes:
>> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
>> so long as our default MANPATH included both if that means applying fewer
>> patches to ports.  
> 
> The default MANPATH is constructed dynamically from PATH:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin: pathname/../man
>   Note: Special logic exists to make /bin and /usr/bin look in
>   /usr/share/man for manual files.
> 
> If we change this to:
> 
>  1.   From each component of the user's PATH for the first of:
>   -   pathname/man
>   -   pathname/MAN
>   -   If pathname ends with /bin or /sbin: pathname/../man and
>   pathname/../share/man
> 
> we wouldn't need any "special logic", but I really don't like the idea
> of having different ports installing man pages in different locations.

I grepped the ports tree and found nearly 5700 ports.  That's a lot to
change all at once but it may be doable.  It depends on how much fallout
there is in the exp-run.

Ports are installed into a staging area now where files can be moved to
another location.  So a post-install make target could be added that
moves the man pages to share/man if necessary (and prints a warning to
maintainers in that case).  Then all pkg-plist and PLIST_FILES need to
be modified (with sed) and PORTREVISION needs to be bumped (also
scripted).

The same could be done to move info and pkgconfig files.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Thu, 9 Mar 2017 19:43:05 -0600 Benjamin Kaduk <ka...@mit.edu> wrote:
> On Thu, Mar 09, 2017 at 12:35:32PM +0100, Tijl Coosemans wrote:
>> Note that -rpath /usr/local/lib isn't added by gcc but by libtool
>> because it assumes rtld will not search that directory automatically.
>> If you run './configure CC=gcc --prefix=/usr && make check' the tests
>> should succeed (without --enable-new-dtags) because -rpath isn't used
>> then.  
> 
> Sounds like a bug in the libtool packaging, then?

Rtld only searches /lib and /usr/lib.  It also searches the ldconfig
hints file and /usr/local/lib is there by default (ldconfig_paths in
/etc/defaults/rc.conf), but users are allowed to change that, for
instance when they install ports in another location than /usr/local.

Arguably, because our default compiler links with --enable-new-dtags,
gcc should as well, but because of the different run-time semantics of
DT_RPATH and DT_RUNPATH this is a potential minefield.  Upstream
binutils changed the default in ld once and this was quickly reverted.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Thu, 09 Mar 2017 09:29:42 +0100 Dag-Erling Smørgrav <d...@des.no> wrote:
> Tijl Coosemans <t...@freebsd.org> writes:
>> If you want to run a program from its build directory and the program
>> links to a library also in the build directory then you have to run the
>> program with LD_LIBRARY_PATH environment variable set to the build
>> directory.  Or, you could link the program with -rpath , but
>> then you should relink it before installation.  It's one of the things
>> libtool takes care of automatically.
>>
>> If this is the problem you have then it has nothing to do with gcc.  If
>> you're not using libtool then your program probably does not have any
>> rpath or runpath so it falls back on rtld/ldconfig which may find it in
>> /usr/local/lib.  
> 
> You are correct in theory, but I am using libtool and it doesn't work.
> 
> Here's a series of emails I wrote to the maintainer a little over six
> months ago explaining the problem:
> 
> 1)
> 
> | I discovered that lang/gcc48 (and presumably the other gcc ports as
> | well) not only have /usr/local/include in their default include path,
> | but actually place it ahead of /usr/include.  This is causing me no end
> | of grief with software that uses iconv, because GNU libiconv's 
> | f*s up your namespace so the build fails unless you explicitly link with
> | GNU libiconv instead of using the libc version.  [...]

Right, to use libc iconv(3) with -I/usr/local/include and GNU libiconv
installed you have to compile with -DLIBICONV_PLUG.

> 2)
> 
> |  [...] I realized over the weekend that the
> | situation is even worse than I initially thought.  Basically, ports gcc
> | is unusable for any other purpose than to build ports which don't
> | support clang.  Let me explain with a hypothetical scenario:
> | 
> | You are developing a library which is important enough that you need to
> | have the stable version installed on your development system.  It is
> | installed in /usr/local as usual.  You've been working on fixing a bug,
> | and have written a unit test which exercises the relevant code and
> | verified that it can deterministically trigger the bug.  You fix the bug
> | and 'make check' again, all green.  Then you clean out your working
> | copy, re-run configure with CC=gcc and 'make check' again.  Your tests
> | fail.
> | 
> | What happened is that when you built your code with gcc, the tests were
> | linked and run with the stable version of the library, where the bug is
> | not fixed.  You can build with LDFLAGS=-L$(top_builddir)/lib, you can
> | even specify the full path to the library in LDADD for each individual
> | test, it doesn't matter.  It will *always* pick the installed version
> | first.  The only way to get your tests to pass is to not have the
> | library installed.
> | 
> | Real-world example - a 10.3 system with upstream OpenPAM installed
> | because it uses OpenPAM's OATH implementation:
> | 
> | with base clang:
> | 
> | des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
> | /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
> | libpam.so.2 => /home/des/src/openpam/trunk/lib/libpam/.libs/libpam.so.2 
> (0x800822000)
> | liboath.so.2 => 
> /home/des/src/openpam/trunk/lib/liboath/.libs/liboath.so.2 (0x800a34000)
> | libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
> | libc.so.7 => /lib/libc.so.7 (0x80102f000)
> | 
> | with lang/gcc:
> | 
> | des@desk ~/src/openpam/trunk% pkg which =gcc
> | /usr/local/bin/gcc was installed by package gcc-4.8.5_2
> | des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
> | /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
> | libpam.so.2 => /usr/local/lib/libpam.so.2 (0x800822000)
> | liboath.so.2 => /usr/local/lib/liboath.so.2 (0x800a34000)
> | libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
> | libc.so.7 => /lib/libc.so.7 (0x80102f000)
> | libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8013dc000)
> | libthr.so.3 => /lib/libthr.so.3 (0x8017e9000)
> | 
> | (and don't ask me why the gcc version is linked with two different
> | versions of libcrypto!)

Here you can probably get things working by adding -Wl,--enable-new-dtags
to LDFLAGS in the configure script (or to AM_LDFLAGS in Makefile.am).
Clang runs ld(1) with this flag by default, gcc does not.  With clang the
program has DT_RUNPATH /usr/local/lib, which rtld(1) checks after
LD_LIBRARY_PATH, and with gcc the program has DT_RPATH /usr/local/lib which
rtld checks *before* LD_LIBRARY_PATH.

(The gold(1) linker also enables this flag by default.)

The reason it links to libcrypto twice is because liboath.so.2 p

Re: manpath change for ports ?

[Tijl Coosemans]

On Wed, 8 Mar 2017 10:31:32 -0700 Warner Losh <i...@bsdimp.com> wrote:
> On Wed, Mar 8, 2017 at 10:21 AM, Tijl Coosemans <t...@freebsd.org> wrote:
>> Are you talking about gcc implicitly searching /usr/local/include and
>> /usr/local/lib?  
> 
> That's currently inconsistent between base gcc, clang, binutils and
> ports versions. I forget which ones do and which ones don't search
> automatically.

It's only ports binutils and ports gcc that search /usr/local.

> IMHO, they all should.

I used to think this too, but now I think it should be possible to use
any compiler to compile something from base or something that should only
depend on things from base, for testing purposes or perhaps because it
needs to be deployed on some other machine.  Compilers shouldn't search
/usr/local implicitly then.  It's easy enough to add -I and -L flags
(perhaps using pkg-config) but it's not easy to remove built-in -I and
-L flags.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav  wrote:
> 4) Remove the hardcoded library path in lang/gcc*
> 
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...

If you want to run a program from its build directory and the program
links to a library also in the build directory then you have to run the
program with LD_LIBRARY_PATH environment variable set to the build
directory.  Or, you could link the program with -rpath , but
then you should relink it before installation.  It's one of the things
libtool takes care of automatically.

If this is the problem you have then it has nothing to do with gcc.  If
you're not using libtool then your program probably does not have any
rpath or runpath so it falls back on rtld/ldconfig which may find it in
/usr/local/lib.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav  wrote:
> 4) Remove the hardcoded library path in lang/gcc*
> 
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...

Are you talking about gcc implicitly searching /usr/local/include and
/usr/local/lib?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Tue, 7 Mar 2017 09:51:14 -0600 Eric van Gyzen  wrote:
> On 03/06/2017 17:56, Baptiste Daroussin wrote:
>> I would like to propose a change in the localbase hier for ports  
> 
> [...]
> 
>> Which will also remove tons of hacks from the ports tree.
>>
>> What do you think?  
> 
> This sounds good to me.
> 
> I seem to recall that most(?) Linux distros used /usr/man many years 
> ago, but they switched to /usr/share/man, I think in the early 2000s. 
> If that's correct, then I consider our /usr/local/man path a historical 
> curiosity that should finally be changed to /usr/local/share/man.

Yes, we used PREFIX/man because that's what software developed for
Linux used at the time.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Make index fails with no entry for /usr/ports/audio/linux-c7-mikmod

[Tijl Coosemans]

On Mon, 20 Feb 2017 08:35:55 +0200 Vasil Dimov  wrote:
> This happens when emulators/linux_base-c7 is installed. Then
> games/linux-uplink-demo/Makefile which contains "USE_LINUX=... mikmod
> ..." picks up a dependency on audio/linux-c7-mikmod which does not
> exist.
> 
> Should audio/linux-c7-mikmod be added, similarly to other?

I've removed the mikmod dependency in r434476 (and r434481) because it's
no longer needed.  Mikmod is not provided by centos.org but by Fedora's
EPEL repository and for CentOS 7 this repository is amd64 only so it
would not work for this i386 game anyway.

> This is a diff between c6 and c7 ports, that could eventually cause
> similar problems:

Thanks, I've also removed naslibs from www/linux-opera in r434483.  The
other ports aren't causing any problems at moment I think.  I'll try to
keep an eye on it.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problem with index

[Tijl Coosemans]

On Mon, 20 Feb 2017 12:29:47 + Matthew Seaman  wrote:
> On 2017/02/20 11:36, Gerard Seibert wrote:
>> I just updated my ports tree using "portsnap". I then ran the following
>> command:
>> 
>> /usr/sbin/pkg version -vL=
>> 
>> This resulted in the following message:
>> 
>> postfix-current-3.2.20170129,4 >   succeeds index (index has 3.2.0.r1,4)
>> 
>> This does not seem correct. What is happening and how do I correct it?   
> 
> Your index file is out of date -- portsnap doesn't updated it because it
> changes too fast to be suitable for keeping in SVN.
> 
> You need to
> 
>   # make fetchindex
> 
> from /usr/ports to download a pre-built index.  Or build your own, by
> 'make index'.  Or tell 'pkg version' to compare versions directly with
> what's in your ports tree by 'pkg version -vP=' (but this will be quite
> a bit slower).

Portsnap should update the INDEX file.  Check /etc/portsnap.conf.  There
should be a line like this: INDEX INDEX- DESCRIBE- where  is the
major version of the FreeBSD release you have installed (10, 11 or 12).
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problem with building libgcrypt

[Tijl Coosemans]

On Tue, 14 Feb 2017 15:11:30 +1100 (EST) Dave Horsfall  
wrote:
>>> What is the output of "pkg which /usr/local/lib/libiconv.la"?
>> 
>> Not found; I sense a generic approach to any more errors of this type :-)
> 
> Removed as suggested (along with libxslt) as nothing claimed to be using
> it, now it's complaining that they're missing when building graphics/peps
> (I gave docbook a miss):
> 
> libtool:   error: cannot find the library '/usr/local/lib/libiconv.la' or
> unhandled argument '/usr/local/lib/libiconv.la'
> 
> Why is libiconv.la now suddenly required?
> 
> At this rate it'll be a full install, but that is definitely a last
> resort (and the 10.3 CD I burned had better be readable).

Keep following the 20140909 entry in UPDATING.  You should run this
command now:

find /usr/local/lib -name '*.la' | xargs grep -l 'libiconv\.la' | xargs pkg 
which
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problem with building libgcrypt

[Tijl Coosemans]

On Mon, 13 Feb 2017 19:01:07 +1100 (EST) Dave Horsfall <d...@horsfall.org> 
wrote:
> On Sun, 12 Feb 2017, Tijl Coosemans wrote:
>>> *** [libgcrypt.la] Error code 1  
>> 
>> See the 20140909 entry in /usr/ports/UPDATING about missing .la files.  
> 
> Thanks - that did the trick.
> 
> Next problem: when building misc/freebsd-doc-en, it fails with:
> 
> libtool: link: cc -shared  -fPIC -DPIC  .libs/attrvt.o .libs/xslt.o 
> .libs/xsltlocale.o .libs/xsltutils.o .libs/pattern.o .libs/templates.o 
> .libs/variables.o .libs/keys.o .libs/numbers.o .libs/extensions.o 
> .libs/extra.o .libs/functions.o .libs/namespaces.o .libs/imports.o 
> .libs/attributes.o .libs/documents.o .libs/preproc.o .libs/transform.o 
> .libs/security.o   -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath 
> -Wl,/usr/local/lib -L/usr/local/lib /usr/local/lib/libxml2.so 
> /usr/local/lib/libiconv.so -lz -llzma -L/usr/lib -lm  -O2 -fstack-protector 
> -Wl,--version-script=./libxslt.syms -fstack-protector   -Wl,-soname 
> -Wl,libxslt.so.1 -o .libs/libxslt.so.1.1.29
> cc: error: no such file or directory: '/usr/local/lib/libiconv.so'
> gmake[4]: *** [Makefile:534: libxslt.la] Error 1

That's probably still because of some .la file.  Does
/usr/local/lib/libiconv.la still exist?  What is the output of
"pkg which /usr/local/lib/libiconv.la"?  If it says "not found in
database" remove it.  If it says "installed by package X" rebuild X.
Same for /usr/local/lib/libxml2.la.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problem with building libgcrypt

[Tijl Coosemans]

On Sun, 12 Feb 2017 21:04:58 +1100 (EST) Dave Horsfall  
wrote:
> Rebuilding ports on 10.3 after upgrade from 9.3, on the final portmaster 
> leg:
> 
> libtool: link: ranlib .libs/libgcrypt.a
> libtool: link: rm -fr .libs/libgcrypt.lax
> sed: /usr/local/lib/libintl.la: No such file or directory
> libtool: link: `/usr/local/lib/libintl.la' is not a valid libtool archive
> *** [libgcrypt.la] Error code 1

See the 20140909 entry in /usr/ports/UPDATING about missing .la files.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: CFT upgrade to xorg 1.18.4 and newer intel/ati DDX

[Tijl Coosemans]

On Tue, 24 Jan 2017 00:55:16 +0100 Baptiste Daroussin 
wrote:
> This is a call for testing for newer Xorg along with newer drivers:
> intel and ati.
> 
> The patch against the head ports:
> https://people.freebsd.org/~bapt/newxorg.diff

I first updated the ati driver.  Running glxgears then crashed the X
server with a segfault.  The newer xorg-server seems to fix that.
Everything looks fine so far.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Does building linux packages under poudriere require linux compatibility emulation?

[Tijl Coosemans]

On Sat, 14 Jan 2017 15:11:42 +0100 Tijl Coosemans <t...@freebsd.org> wrote:
> On Sat, 14 Jan 2017 01:07:09 +0100 Mark Martinec 
> <mark.martinec+free...@ijs.si> wrote:
>> When building packages under poudriere on 11.0-RELEASE-p7 (from a 
>> command line in a terminal window) I'm noticing occasional streams of
>> diagnostic:
>> 
>>ELF binary type "3" not known.
>> 
>> which seem to be related to building some linux packages (example below,
>> parallel builds). Poudriere still reports success for these builds.
>> 
>> The host where poudriere is running does not have linux.ko loaded.
>> 
>> Does building such packages really require linuxilator configured
>> on the build host ???  
> 
> To build a package, its dependencies need to be installed and on
> installation some packages may need to run certain commands and for
> linux packages these commands may be linux programs.  So, yes, if you
> need to build linux packages the build host should have USE_LINUX=yes
> in /etc/rc.conf.

That should be linux_enable="YES" in /etc/rc.conf, not USE_LINUX.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: flash plugin / nsplugin wrapper

[Tijl Coosemans]

On Sat, 14 Jan 2017 10:56:41 -0700 The Doctor  wrote:
> Hello.
> 
> consistency please.
> 
> Can these plugin have the option of Centos 6 OR centos 7 install;.
> 
> I need Centos 7 for Xen / bhyve virtualisation.

Add DEFAULT_VERSIONS+=linux=c7 or c7_64 to /etc/make.conf and all linux
ports will depend on CentOS 7.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Does building linux packages under poudriere require linux compatibility emulation?

[Tijl Coosemans]

On Sat, 14 Jan 2017 01:07:09 +0100 Mark Martinec  
wrote:
> When building packages under poudriere on 11.0-RELEASE-p7 (from a 
> command line in a terminal window) I'm noticing occasional streams of
> diagnostic:
> 
>ELF binary type "3" not known.
> 
> which seem to be related to building some linux packages (example below,
> parallel builds). Poudriere still reports success for these builds.
> 
> The host where poudriere is running does not have linux.ko loaded.
> 
> Does building such packages really require linuxilator configured
> on the build host ???

To build a package, its dependencies need to be installed and on
installation some packages may need to run certain commands and for
linux packages these commands may be linux programs.  So, yes, if you
need to build linux packages the build host should have USE_LINUX=yes
in /etc/rc.conf.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Gettext Issues

[Tijl Coosemans]

On Fri, 16 Dec 2016 17:17:52 -0700 "@lbutlr"  wrote:
>> On 16 Dec 2016, at 00:22, @lbutlr  wrote:
>>> 2014-11-30
>>> Affects: users of devel/gettext (close to everyone)
>>> Author: t...@freebsd.org
>>> Reason:
>>>  The devel/gettext port has been split up in devel/gettext-runtime, a
>>>  lightweight package containing runtime libraries, and devel/gettext-tools,
>>>  a package containing developer tools.  The devel/gettext port still exists
>>>  as a metaport.
>>> 
>>>  You must first delete the existing installation of gettext and then
>>>  reinstall it.  This will break sudo, so you *must* do this in a root
>>>  shell (sudo -i) if you use sudo.
>> 
>> I cannot imagine that gettext hasn't been updated on my system in over
>> 2 years, but I seem to be having an issue that appears to be related
>> to this based on the errors.
>> 
>> Shared object "libintl.so.8" not found, required by "bash"
>> 
>> For example.
>> 
>> I have logged into the console directly as the root user and tried to
>> build gettext via portmaster of via make clean && make install but I
>> get errors about missing files.
>> 
>> pkg-static: Unable to access file
>> /usr/ports/devel/gettext-runtime/work/stage/usr/local/include/autosprintf.h:
>> No such file or directory
>> 
>> 
>> I've tried to build gettext-runtime first, but to no avail.
> 
> To clarify, if I try to make gettext-runtime it ends with:
> 
> install  -m 0644 ABOUT-NLS 
> '/usr/ports/devel/gettext-runtime/work/stage/usr/local/share/gettext'
> > Compressing man pages (compress-man)  
> ls: 
> /usr/ports/devel/gettext-runtime/work/stage/usr/local/info/autosprintf.info*: 
> No such file or directory
> 
> And the error is correct, the file does not exist.

Can you email me
/usr/ports/devel/gettext-runtime/work/gettext-0.19.8.1/gettext-runtime/config.log
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Setting up CUPS on FreeBSD-arm using Raspberry Pi 2

[Tijl Coosemans]

On Mon, 5 Dec 2016 09:25:31 -0800 bob prohaska <f...@www.zefox.net> wrote:
> On Mon, Dec 05, 2016 at 10:40:27AM +0100, Tijl Coosemans wrote:
> > 
> > Check that you have the following files and if not install x11/libXScrnSaver
> > 
> > /usr/local/lib/libXss.a
> > /usr/local/lib/libXss.so
> > /usr/local/lib/libXss.so.1
> > /usr/local/lib/libXss.so.1.0.0  
> 
> Re-building and installing x11/libXScrnSaver did the trick, CUPS now works.
> 
> How did you connect not finding lXss and XScrnSaver? I tried a Google
> search and found nothing that came close Is there a database that
> associates library names with originating source code?

I have it installed and then 'pkg which /usr/local/lib/libXss.so' tells
you the package name.  If you don't have that file you can query all
packages using 'pkg rquery '%o %b' | grep libXss'.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Setting up CUPS on FreeBSD-arm using Raspberry Pi 2

[Tijl Coosemans]

On Sun, 4 Dec 2016 15:05:09 -0800 bob prohaska <f...@www.zefox.net> wrote:
> On Sun, Dec 04, 2016 at 11:14:00PM +0100, Tijl Coosemans wrote:
>> You need cups-filters yes.  Please post the last couple of build commands
>> and error messages you are seeing.  
> 
> The build command is just 
> make -DBATCH
> 
> There's much intermediate output and lots of warnings, ending with
> 
> snippage..
> 
> xicc/xicc.h:86:23: note: expanded from macro 'icxSigJabData'
> #define icxSigJabData ((icColorSpaceSignature) icmMakeTag('J','a','b',' '))
>   ^
> Archive gamut/libgammap.a 
> Cc_ xicc/xspect.o 
> Cc_ xicc/xcolorants.o 
> Cc_ xicc/xutils.o 
> 45 warnings generated.
> Archive icc/libicc.a 
> Cc_ xicc/iccjpeg.o 
> Cc_ xicc/xdevlin.o 
> Cc_ xicc/xcam.o 
> Cc_ xicc/cam97s3.o 
> Cc_ xicc/cam02.o 
> Cc_ xicc/mpp.o 
> Cc_ xicc/ccmx.o 
> Cc_ xicc/ccss.o 
> Cc_ xicc/xfit.o 
> Cc_ xicc/xdgb.o 
> Cc_ xicc/moncurve.o 
> Cc_ xicc/xcal.o 
> Cc_ xicc/bt1886.o 
> xicc/bt1886.c:111:2: warning: array index 2 is past the end of the array 
> (which
>   contains 2 elements) [-Warray-bounds]
> p->tab[2] = 0.0;
> ^  ~
> xicc/bt1886.h:27:2: note: array 'tab' declared here
> double tab[2];  /* Target ab offset valu...
> ^
> 1 warning generated.
> Cc_ xicc/xcolorants2.o 
> 5 warnings generated.
> Cc_ xicc/xutils2.o 
> Archive xicc/libxcolorants.a 
> Cc_ xicc/iccjpeg2.o 
> Link_ imdi/imdi_make 
> /usr/bin/ld: cannot find -lXss
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
>   cc -o imdi/imdi_make  imdi/imdi_make.o imdi/imdi_gen.o imdi/cgen.o
> -L/usr/local/lib -g -lrt -lX11 -lXext -lXxf86vm -lXinerama -lXrandr -lXau 
> -lXdmcp -lXss -lusb -ltiff -ljpeg -lpng -lz -lm -lpthread  
> 
> ...failed Link_ imdi/imdi_make ...
> ...skipped imdi_k.h for lack of imdi_make...
> ...skipped imdi.o for lack of imdi.c...
> ...skipped libimdi.a for lack of libimdi.a(imdi.o)...
> Archive xicc/libxutils.a 
> Archive xicc/libxicc.a 
> ...failed updating 1 target(s)...
> ...skipped 3 target(s)...
> ...updated 77 target(s)...
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/ports/graphics/argyllcms
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/graphics/colord
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/print/cups-filters
> root@www:/usr/ports/print/cups-filters # 
> 
> Restarting make in /usr/ports/graphics/argyllcms has the same effect.

Check that you have the following files and if not install x11/libXScrnSaver

/usr/local/lib/libXss.a
/usr/local/lib/libXss.so
/usr/local/lib/libXss.so.1
/usr/local/lib/libXss.so.1.0.0
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Setting up CUPS on FreeBSD-arm using Raspberry Pi 2

[Tijl Coosemans]

On Sun, 4 Dec 2016 10:20:58 -0800 bob prohaska  wrote:
> In trying to set up CUPS on a Raspberry Pi running -current there seems
> to be a catch-22: CUPS compiles, installs and answers a browser pointed
> at localhost:631 but attemps to print a test page report
> 
> no such file or directory
> 
> which it is suggested (by a web search) can be fixed by installing
> /usr/ports/print/cups-filters.
> 
> An attempt to make cups-filters appears to stop in something called
> icc, apparently /usr/ports/lang/icc, which is of inconsistent with
> an ARM host.
> 
> Am I correct in thinking that cups-filters is necessary to getting
> CUPS running on a Raspberry Pi? It's a model 2 if that matters, uname
> reports
> 
> FreeBSD 12.0-CURRENT (RPI2) #0 r309382: Fri Dec  2 23:22:02 PST 2016

You need cups-filters yes.  Please post the last couple of build commands
and error messages you are seeing.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADSUP] Default Perl changed to 5.24.

[Tijl Coosemans]

On Fri, 4 Nov 2016 23:00:56 + tech-lists  wrote:
> On 04/11/2016 22:58, tech-lists wrote:
>> On 03/11/2016 15:00, Mathieu Arnold wrote:  
>>> Instructions on how to switch are in UPDATING.
>>>
>>> If you do not want to switch, you do not have to do anything.
>>
>> I followed the instructions in /usr/ports/UPDATING for portupgrade. I
>> have found that numerous ports will not build:
>>
>> ** Listing the failed packages (-:ignored / *:skipped / !:failed)
>> ! net/p5-Socket (p5-Socket-2.021)   (unknown build error)
>> ! security/p5-Crypt-IDEA (p5-Crypt-IDEA-1.10_1) (unknown build error)
>> ! net-mgmt/p5-NetAddr-IP (p5-NetAddr-IP-4.078)  (unknown build error)
>> ! converters/p5-Encode-JIS2K (p5-Encode-JIS2K-0.03) (unknown build
>> error)
>> ! converters/p5-Unicode-String (p5-Unicode-String-2.10) (unknown build
>> error)
>> * converters/p5-Unicode-Map8 (p5-Unicode-Map8-0.13_1)
>> ! math/p5-Bit-Vector (p5-Bit-Vector-7.4)(unknown build error)
>> ! devel/p5-Filter (p5-Filter-1.55)  (unknown build error)
>> ! chinese/p5-Encode-HanExtra (p5-Encode-HanExtra-0.23_1)(unknown
>> build error)
>> ! security/p5-Digest-SHA1 (p5-Digest-SHA1-2.13_1) (unknown build error)
>>
>> [snip loads more]
>>
>> This happens after I removed the DEFAULT_VERSIONS+= line in make.conf
>> and ran portupgrade -f `pkg shlib -qR libperl.so.5.20` as indicated in
>> the second step.
>>
>> How can I fix? System is r308206 (11-STABLE) and ports is r425362
> 
> edit: the error I get now when I try to rebuild an affected port singly is:
> 
> ===>   p5-Socket-2.021 depends on package: perl5>=5.24<5.25 - found
> ===>  Configuring for p5-Socket-2.021  
> env: /usr/local/bin/perl5.24.1: No such file or directory
> *** Error code 127
> 
> Stop.
> make: stopped in /storage/usr/ports/net/p5-Socket

It's probably caused by pkg not copying hardlinks:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213255
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make clean failes to cleanup everything

[Tijl Coosemans]

On Tue, 4 Oct 2016 14:18:51 +0200 Gerhard Schmidt <schm...@ze.tum.de> wrote:
> Am 04.10.2016 um 14:03 schrieb Tijl Coosemans:
>> On Tue, 4 Oct 2016 13:36:29 +0200 Gerhard Schmidt <schm...@ze.tum.de> wrote: 
>>  
>>> Am 04.10.2016 um 12:48 schrieb Tijl Coosemans:  
>>>> On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt <schm...@ze.tum.de> 
>>>> wrote:
>>>>> make clean fails to clean autoconf and automake.
>>>>>
>>>>> If a port uses autoconf and autoconf isn't installed on the system, it
>>>>> will be build and installed.
>>>>>
>>>>> if you run make clean after installing the port, every dependency is
>>>>> cleaned as well but not autoconf.
>>>>
>>>> Can you give an example of such a port, because we have two mechanisms
>>>> that can pull in autoconf.
>>>
>>> It's seams to be quite a complex problem.
>>>
>>> To find out which ports causes this problem tried to build lang/php56
>>> which uses autoconf. But when I do a make clean autoconf is cleaned as
>>> well.
>>>
>>> [root@etustar /usr/ports/lang/php56]# make clean  
>>> ===>  Cleaning for autoconf-2.69_1
>>> ===>  Cleaning for php56-5.6.25_1
>>>
>>> But it also installs help2man, gmake, p5-Locale-gettext-1.06 and
>>> autoconf-wrapper-20131203 and these are not cleaned.
>>>
>>> The transcript is attached as typescript_clean
>>>
>>> now do a pkg autoremove which removes autoconf and the missed ports form
>>> the system.
>>>
>>> now try again to compile php56 and it fails
>>>
>>> the transcript is attached as typescript_unclean
>>>
>>> It seams that dependencies of dependencies are not clean. It seams that
>>> autoconf was only the most memorable one.  
>> 
>> This seems to be intended.  Make clean runs make limited-clean-depends
>> which cleans direct dependencies only.  If you want to do full recursive
>> clean you have to run make clean-depends.
> 
> I use FreeBSD since FreeBSD 2.2.5. When did this change in semantics
> happen? Why do the first layer. This is something nobody can understand.
> Either make clean should only clean the actual port. So everybody sees
> that dependencies are not cleaned (maybe a message "You should run make
> clean-depens to clean dependencies as well" should be printed if
> dependencies are touched) or do it right and clean all touched.
> 
> make clean-depends doesn't take that much more time than make clean, so
> why the change?

I've filed a bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213188
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make clean failes to cleanup everything

[Tijl Coosemans]

On Tue, 4 Oct 2016 13:36:29 +0200 Gerhard Schmidt <schm...@ze.tum.de> wrote:
> Am 04.10.2016 um 12:48 schrieb Tijl Coosemans:
>> On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt <schm...@ze.tum.de> wrote: 
>>  
>>> make clean fails to clean autoconf and automake.
>>>
>>> If a port uses autoconf and autoconf isn't installed on the system, it
>>> will be build and installed.
>>>
>>> if you run make clean after installing the port, every dependency is
>>> cleaned as well but not autoconf.  
>> 
>> Can you give an example of such a port, because we have two mechanisms
>> that can pull in autoconf.  
> 
> It's seams to be quite a complex problem.
> 
> To find out which ports causes this problem tried to build lang/php56
> which uses autoconf. But when I do a make clean autoconf is cleaned as
> well.
> 
> [root@etustar /usr/ports/lang/php56]# make clean
> ===>  Cleaning for autoconf-2.69_1
> ===>  Cleaning for php56-5.6.25_1  
> 
> But it also installs help2man, gmake, p5-Locale-gettext-1.06 and
> autoconf-wrapper-20131203 and these are not cleaned.
> 
> The transcript is attached as typescript_clean
> 
> now do a pkg autoremove which removes autoconf and the missed ports form
> the system.
> 
> now try again to compile php56 and it fails
> 
> the transcript is attached as typescript_unclean
> 
> It seams that dependencies of dependencies are not clean. It seams that
> autoconf was only the most memorable one.

This seems to be intended.  Make clean runs make limited-clean-depends
which cleans direct dependencies only.  If you want to do full recursive
clean you have to run make clean-depends.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: make clean failes to cleanup everything

[Tijl Coosemans]

On Tue, 4 Oct 2016 09:52:23 +0200 Gerhard Schmidt  wrote:
> make clean fails to clean autoconf and automake.
> 
> If a port uses autoconf and autoconf isn't installed on the system, it
> will be build and installed.
> 
> if you run make clean after installing the port, every dependency is
> cleaned as well but not autoconf.

Can you give an example of such a port, because we have two mechanisms
that can pull in autoconf.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How to migrate from ports/emulators/linux_base-c6 to linux_base-c7?

[Tijl Coosemans]

On Fri, 30 Sep 2016 13:30:21 -0700 David Wolfskill  wrote:
> Per ports/UPDATING entry 20141215, I have been using
> emulators/linux_base-c6 on my laptop for some time.
> 
> I recently noticed that ports/emulators/linux_base-c7 now exists (as of
> r421391: 2016-09-05 13:10:30 -0700 (Mon, 05 Sep 2016)).
> 
> On the other hand, while I count 76 "linux{,base}-c6*" ports (as
> of ports/head @422979), I only see a single "linux{,_base}-c7*" port --
> ports/emulators/linux_base-c7 itself.
> 
> Scanning through ports/UPDATING, the most recent entry on
> emulators/linux* is the above-cited 20141215, and the previous entry
> (20141209) is the latest entry to document a process for migrating from
> one Linux emulation infrastructure to another.  I believe a few of the
> particular it cites may well be rather out-of-date.
> 
> So I'm wondering:
> * At what point might it be ... reasonable ... to consider migrating
>   from linux_base-c6 to linux_base-c7?
> 
> * Are there any particular steps to take to accomplish such a migration?

We are still working on the other c7 ports: https://reviews.freebsd.org/D7886
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: linux_base-c6 (....) on amd64 without x86_64 support

[Tijl Coosemans]

On Tue, 20 Sep 2016 13:19:23 +0200 Matthias Apitz  wrote:
> My other poudriere oven is freebsd-r302904-ports-20160716 (r418627)
> so I will use this. What is the correct setting in make.conf for c6 x86_64?

Before r421387:

OVERRIDE_LINUX_BASE_PORT=c6_64
OVERRIDE_LINUX_NONBASE_PORTS=c6_64

After r421387:

DEFAULT_VERSIONS+=linux=c6_64

(OVERRIDE_* still works but produces a warning.)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: linux_base-c6 (....) on amd64 without x86_64 support

[Tijl Coosemans]

On Tue, 20 Sep 2016 10:34:11 +0200 Matthias Apitz <g...@unixarea.de> wrote:
> El día Monday, September 19, 2016 a las 01:51:19PM +0200, Tijl Coosemans 
> escribió:
>> On Mon, 19 Sep 2016 12:50:17 +0200 Matthias Apitz <g...@unixarea.de> wrote:  
>>> I have compiled my ports with poudriere on amd64, based on ports r414411
>>> at the moment, and learned that the linux*c6 packages does not have
>>> x86_64 support; I recompiled as test emulators/linux_base-c6 and only if
>>> I set in /etc/make.conf:
>>> 
>>> OVERRIDE_LINUX_BASE_PORT=c6_64
>>> 
>>> the package is built as linux_base-c6_64-6.7_1.txz and has 64-bit
>>> support (and 32-bit too). Why do I have to set this extra variable
>>> OVERRIDE_LINUX_BASE_PORT?  
>> 
>> Because it is new and experimental.  I plan to enable it by default in
>> January 2017, after FreeBSD 9, 10.1 and 10.2 EoL.  
> 
> I have checked out head of ports, but it is unwilling to build it on:
> 
> # uname -a
> FreeBSD c720-r292778-amd64 11.0-CURRENT FreeBSD 11.0-CURRENT #0
> r292778: Mon Dec 28 05:45:37 CET 2015
> root@poudriere-amd64:/usr/local/r292778/obj/usr/local/r292778/src/sys/GENERIC
> amd64

You need at least r297602, so try a more recent 11-stable or 12-current.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: linux_base-c6 (....) on amd64 without x86_64 support

[Tijl Coosemans]

On Mon, 19 Sep 2016 12:50:17 +0200 Matthias Apitz  wrote:
> I have compiled my ports with poudriere on amd64, based on ports r414411
> at the moment, and learned that the linux*c6 packages does not have
> x86_64 support; I recompiled as test emulators/linux_base-c6 and only if
> I set in /etc/make.conf:
> 
> OVERRIDE_LINUX_BASE_PORT=c6_64
> 
> the package is built as linux_base-c6_64-6.7_1.txz and has 64-bit
> support (and 32-bit too). Why do I have to set this extra variable
> OVERRIDE_LINUX_BASE_PORT?

Because it is new and experimental.  I plan to enable it by default in
January 2017, after FreeBSD 9, 10.1 and 10.2 EoL.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ports: on the fly pkg-plist creation from git pull

[Tijl Coosemans]

On Mon, 5 Sep 2016 15:52:34 +0200 CeDeROM  wrote:
> I am creating a port from a GIT repository. I would like to keep the
> GIT file structure to user can update the project with GIT tools. I
> know this is not the best and not even the valid way to update, but in
> this particular case there is no other choice yet.. and the project
> changes really fast so updates from GIT are reasonable and desired.
> Hopefully it will change in a next major release and we can simply
> create a package.
> 
> I did the simple automation of project clone, submodiles clone,
> initial configuration, etc, inside port Makefile.
> 
> The problem is with the pkg-plist. I can create one with `make plist`
> based on the staged filesystem and it works until update. I would like
> make to create a plist file after fetch and build as a part of
> automation. How can I call `make makeplis` on each build?

pkg-plist is processed before the staging area is created so running
makeplist from post-install or post-stage is too late.  You'll have to
do something like this instead:

post-install:
(cd ${STAGEDIR}${PREFIX} && ${FIND} -s * -not -type d >> ${TMPPLIST})
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Tijl Coosemans]

On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov  
wrote:
> The option which would fix all this mess is:
> 1. add rpath for gcc lib/ directory into spec file
> and
> 2. make ports collection use its own compiler instead of fighting with
>the base.

That still doesn't cover all cases, e.g.:

port exec -> base lib -> libgcc_s.so.1
  -> port lib -> recent libgcc_s.so.1

An example is:

% echo 'int main(void){}' > test.c
% clang37 -o test test.c -lexecinfo -lgfortran -L/usr/local/lib/gcc5 
-Wl,-rpath,/usr/local/lib/gcc5
% ./test
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc5/libgfortran.so.3 not found

The base library (libexecinfo) doesn't have DT_RPATH or DT_RUNPATH so the
only way rtld can find the right libgcc_s.so is if the executable (test)
has DT_RPATH and no DT_RUNPATH.  Clang runs ld with --enable-new-dtags
so the executable has DT_RUNPATH.  DT_RPATH is deprecated in the Linux
world so there are probably more ports that use --enable-new-dtags.
Another example seems to be Rust.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Tijl Coosemans]

On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric <d...@freebsd.org> wrote:
> On 18 Aug 2016, at 11:15, Tijl Coosemans <t...@freebsd.org> wrote: 
>> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
>> <s...@troutmask.apl.washington.edu> wrote:
>>> % gfortran6 -o z foo.f90 && ./z
>>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
>>> /usr/local/lib/gcc6/libgfortran.so.3 not found
>>> % ldconfig -r | grep libgcc
>>>6:-lgcc_s.1 => /lib/libgcc_s.so.1
>>>735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
>>> 
>>> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
>>> be convinced to build, install, and use libgcc_s6.so.1, then the
>>> problem is solved without a wrapper.  
>> 
>> In this case the real cause of the problem is that compilers and linkers
>> search /lib and /usr/lib last and ldconfig searches them first.  Renaming
>> the library is just a hack around that.  
> 
> Well, even if you would adjust the compilers and linkers to look in
> /usr/local/lib first,

No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last.
That would match base ld(1) so anything that links successfully at
compile-time will also link successfully at run-time (if there are no
other search order mismatches leading to conflicts).

But, this means that in case of a name conflict between base and ports,
the ports provided library is assumed to be the right one.  I'm not 100%
sure this is smart.  Usually the ports version of a library is more
recent and if the name is the same it should be backward compatible, but
if that's not the case (older or not compatible) base utilities may fail
to run (like ./z in the example above) and that's maybe worse than ports
or locally built programs failing.

> how would you solve the problem of having
> multiple, possibly incompatible versions of the same library in
> different directories?
> 
> For example, on one of my systems, I now have these:
> 
> /usr/local/lib/gcc47/libgcc_s.so.1
> /usr/local/lib/gcc48/libgcc_s.so.1
> /usr/local/lib/gcc49/libgcc_s.so.1
> /usr/local/lib/gcc5/libgcc_s.so.1
> /usr/local/lib/gcc6/libgcc_s.so.1
> /usr/local/lib/gcc7/libgcc_s.so.1
> 
> So which one are you going to put at the front of the path?  The gcc7
> version?  If you are lucky that one is backwards compatible with all the
> previous ones, but still I would like it much better if a program
> compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
> of libgcc_s.so.
> 
> Steve's proposed scheme solves that quite nicely, in my opinion.  The
> problem is only in the details, as usual.  There will be many configure
> scripts and libtool-like utilities out there, that assume libgcc must be
> linked using -lgcc_s, not -lgcc_s$VERSION.

This is a separate problem that has been discussed many times before.
The ports tree adds -Wl,-rpath to *FLAGS in several places to choose
a library.  I now noticed there is a FAQ about this at
https://gcc.gnu.org/faq.html#rpath.  It gives some suggestions including
creating wrapper scripts, but they wouldn't work when code is compiled
with gfortran but linked with Clang cc/c++.  The only thing that works
in this case is -Wl,-rpath.  Another option would be to create a port
that installs a recent version of libgcc in /usr/local/lib and let the
gcc ports use that instead of their own copy.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Problems with out libgcc_s.so in base

[Tijl Coosemans]

On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
 wrote:
> On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote:
>> On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:  
>>> Freebsd-ports could also use a wrapper:
>>> % cat ~/bin/gfc7
>>> #! /bin/sh
>>> DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'`
>>> export DIR
>>> 
>>> LD_LIBRARY_PATH=$DIR/work/7/lib
>>> export LD_LIBRARY_PATH
>>> 
>>> LD_RUN_PATH=$DIR/work/7/lib
>>> export LD_RUN_PATH
>>> 
>>> $DIR/work/7/bin/gfortran -fno-backtrace $@  
>> 
>> Yes. I have also suggested we use a wrapper to the ports guys.
> 
> I thought about this a bit, and cleaner solution might be
> to add the program suffix to libgcc_s.so.1.  For example,
> 
> % cat foo.f90
> program foo
>print *, 'Hello'
> end program
> % gfortran6 -o z foo.f90 && ./z
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> /usr/local/lib/gcc6/libgfortran.so.3 not found
> % ldconfig -r | grep libgcc
> 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> 
> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> be convinced to build, install, and use libgcc_s6.so.1, then the
> problem is solved without a wrapper.

In this case the real cause of the problem is that compilers and linkers
search /lib and /usr/lib last and ldconfig searches them first.  Renaming
the library is just a hack around that.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg(1) continues after pre-install script fails

[Tijl Coosemans]

On Wed, 3 Aug 2016 18:15:42 +0200 Baptiste Daroussin <b...@freebsd.org> wrote:
> On Wed, Aug 03, 2016 at 05:03:01PM +0200, Tijl Coosemans wrote:
>> The linux_base-* packages require Linux support in the kernel during
>> installation because they run /compat/linux/sbin/ldconfig.  The packages
>> have a PRE-INSTALL script that checks this and returns an error if the
>> support isn't there, but pkg(1) ignores such errors and continues to
>> install the files anyway.  Then it runs ldconfig via POST-INSTALL which
>> fails but errors from this are also ignored and pkg(1) exits normally.
>> It looks like this:
>> 
>> sysctl: unknown oid 'compat.linux.osrelease'
>> linuxulator is not (kld)loaded, exiting
>> pkg-static: PRE-INSTALL script failed
>> ELF binary type "0" not known.
>> /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
>> pkg-static: POST-INSTALL script failed
>> 
>> Shouldn't pkg(1) abort when pre-install fails and return an error when
>> post-install fails?  
> 
> It has been reverted because the number of script failing in the ports tree
> is still too high :(

Can you provide a patch that enables this again and request an exp-run?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

pkg(1) continues after pre-install script fails

[Tijl Coosemans]

The linux_base-* packages require Linux support in the kernel during
installation because they run /compat/linux/sbin/ldconfig.  The packages
have a PRE-INSTALL script that checks this and returns an error if the
support isn't there, but pkg(1) ignores such errors and continues to
install the files anyway.  Then it runs ldconfig via POST-INSTALL which
fails but errors from this are also ignored and pkg(1) exits normally.
It looks like this:

sysctl: unknown oid 'compat.linux.osrelease'
linuxulator is not (kld)loaded, exiting
pkg-static: PRE-INSTALL script failed
ELF binary type "0" not known.
/bin/sh: /compat/linux/sbin/ldconfig: Exec format error
pkg-static: POST-INSTALL script failed

Shouldn't pkg(1) abort when pre-install fails and return an error when
post-install fails?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: linux-c6/c6_64 update

[Tijl Coosemans]

On Tue, 21 Jun 2016 00:01:36 +0200 Walter Schwarzenfeld 
 wrote:
> Update linux-c6/linux_c6:64 (Revision 417169) from today
> I have linux-c6_64\* packages installed.
> Portmaster updated this packages. But it tried also install some 
> linux-c6 packages, but this failed.
> After second try, portmaster states right: "all packages up-to-date".
> But it has installed all linux-c6_64 packages as automatic. Maybe, this 
> could cause problems if someone tries to run pkg autoremove.
> I mailed this the portmaster maintainer.

Do you have the following in /etc/make.conf:

OVERRIDE_LINUX_BASE_PORT=   c6_64
OVERRIDE_LINUX_NONBASE_PORTS=   c6_64
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: failure compile libGL-11.1.2

[Tijl Coosemans]

On Mon, 18 Apr 2016 15:13:39 +0200 Willem Offermans 
 wrote:
> Dear FreeBSD friends,
> 
> I have inherited an old FreeBSD beast and I'm trying to update it to 10.3.
> 
> However the following error occurred during compiling libGL:
> 
> ===>  Building for libGL-11.1.2  
> 
> [cut some messages in between]
> 
> libtool:   error: cannot find the library '/usr/local/lib/libXext.la' or 
> unhandled argument '/usr/local/lib/libXext.la'
> 
> '/usr/local/lib/libXext.la' is indeed not present. But the file is also not 
> present on another FreeBSD 10.2 system. So I suppose it is not needed. Is 
> there something old on the server pointing to this file? How can I proceed?

See the 20140909 entry in /usr/ports/UPDATING.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: pkg vs hplip

[Tijl Coosemans]

On Fri, 18 Mar 2016 11:44:24 +0200 Andriy Gapon  wrote:
> On 17/03/2016 21:41, Andriy Gapon wrote:
>> I am trying to upgrade to the latest official packages and I am getting the
>> following:
>> 
>> $ pkg upgrade
>> ...
>> Installed packages to be UPGRADED:
>> ...
>> hplip-plugin: 3.14.10 -> 3.16.2 [poudriere]
>> hplip: 3.14.10_1 -> 3.16.2_1 [FreeBSD]
>> gutenprint-ijs: 5.2.10_1 -> 5.2.10_2 [FreeBSD]
>> gutenprint-cups: 5.2.10_1 -> 5.2.10_2 [FreeBSD]
>> gutenprint-base: 5.2.10_1 -> 5.2.10_2 [FreeBSD]
>> gtk3: 3.18.8 -> 3.18.8_1 [FreeBSD]
>> gtk2: 2.24.29 -> 2.24.29_1 [FreeBSD]
>> giflib: 5.1.2_1 -> 5.1.2_2 [FreeBSD]
>> ghostscript9-base: 9.06_11 -> 9.06_12 [FreeBSD]
>> gdb: 7.10_5 -> 7.11 [poudriere]
>> foomatic-filters: 4.0.17_5 -> 4.0.17_6 [FreeBSD]
>> firefox: 45.0_1,1 -> 45.0_3,1 [FreeBSD]
>> epdfview: 0.1.8_10 -> 0.1.8_11 [FreeBSD]
>> eclipse: 4.5.1 -> 4.5.2 [FreeBSD]
>> cups-filters: 1.8.2 -> 1.8.2_2 [FreeBSD]
>> cups: 2.0.3_1 -> 2.1.3_1 [FreeBSD]
>> ...
>> The process will require 90 MiB more space.
>> 379 MiB to be downloaded.
>> 
>> Proceed with this action? [y/N]: y
>> ...
>> Fetching py27-attrs-15.2.0.txz: 100%   18 KiB  18.1kB/s00:01
>> Checking integrity... done (16 conflicting)
>> pkg: Cannot solve problem using SAT solver:
>> require rule: package hplip(r) depends on a requirement provided by:
>> net-snmp(l)net-snmp(l)net-snmp(l)
>> require rule: package hplip(r) depends on a requirement provided by:
>> cups-image(l)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)
>> require rule: package hplip(r) depends on a requirement provided by:
>> cups-client(l)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)cups(r)
>> require rule: package hplip(r) depends on a requirement provided by:
>> sane-backends(l)epkowa(r)sane-backends(l)sane-backends(l)
>> require rule: package hplip(r) depends on a requirement provided by:
>> dbus(l)dbus(l)dbus(l)
>> require rule: package hplip(r) depends on a requirement provided by:
>> jpeg-turbo(l)mozjpeg(r)jpeg(r)jpeg-turbo(l)jpeg-turbo(l)
>> upgrade rule: upgrade local hplip-3.16.2_1 to remote hplip-3.16.2_1
>> upgrade rule: upgrade local hplip-3.16.2_1 to remote hplip-3.16.2_1
>> upgrade rule: upgrade local hplip-3.14.10_1 to remote hplip-3.16.2_1
>> cannot install package hplip, remove it from request? [Y/n]: 
>> I can not figure out what the problem is here.  
> 
> Followup: I answered Y and kept answering Y when I was prompted 3 more times,
> but after that some magic happened and pkg announced that it is going to do 
> the
> following:
> 
> Installed packages to be REMOVED:
> foomatic-filters-4.0.17_5
> cups-client-2.0.3_2
> cups-image-2.0.3_2
> cups-base-2.0.3_5
> cups-pstoraster-8.15.4_8
> 
> New packages to be INSTALLED:
> py27-attrs: 15.2.0 [FreeBSD]
> 
> Installed packages to be UPGRADED:
> qpdf: 5.1.2_1 -> 5.1.2_2 [FreeBSD]
> ghostscript9-base: 9.06_11 -> 9.06_12 [FreeBSD]
> cups: 2.0.3_1 -> 2.1.3_1 [FreeBSD]
> cups-filters: 1.8.2 -> 1.8.2_2 [FreeBSD]
> ...
> hplip: 3.14.10_1 -> 3.16.2_1 [FreeBSD]
> ...
> hplip-plugin: 3.14.10 -> 3.16.2 [poudriere]
> ...
> 
> This seems to be correct.
> 
> 
>> Please note that I use a multi-repository configuration: the official
>> repository for most packages and a local, poudriere-built one for some
>> packages including hplip-plugin.
>> 
>> Any help would be appreciated!

This looks correct, but if you want to get to the bottom of this you'll
have to talk to one the pkg developers.  My guess is that the initial SAT
problem may be too difficult to solve for the SAT solver included in pkg.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: USB devices and the latest update to CUPS

[Tijl Coosemans]

On Fri, 18 Mar 2016 09:40:01 +0100 Thomas Gellekum 
 wrote:
> On 03/18/2016 07:14, Jonathan Chen wrote:
>> Ever since the latest update to CUPS, jobs sent attached to my USB
>> printer are stuck with:
>> 
>> D [18/Mar/2016:17:01:05 +1300] [Job 407] libusb_get_device_list=1
>> I [18/Mar/2016:17:01:05 +1300] [Job 407] Waiting for printer to become
>> available.
>> 
>> This will loop indefinitely, with the printer never coming available.
>> 
>> If I stop CUPS and directly cat(1) a file to /dev/unlpt0, output will
>> appear; so it's nothing to do with the USB connection to the printer.
>> 
>> Anyone else seeing this?  
> 
> Yes. I also noticed that the LIBUSB was dropped (unset in my case).

Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207939
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: print/cups overhaul (PR 207746) side-effects

[Tijl Coosemans]

On Sat, 12 Mar 2016 16:41:47 +0100 Martin Waschbüsch <mar...@waschbuesch.de> 
wrote:
> Am 12.03.2016 um 14:10 schrieb Tijl Coosemans <t...@freebsd.org>:
>> On Fri, 11 Mar 2016 20:52:08 +0100 Martin Waschbüsch <mar...@waschbuesch.de> 
>> wrote:  
>>> I just did a rebuild of packages for my webservers with poudriere.
>>> What I noticed was that via the print/cups overhaul (see PR 207746),
>>> quite a lot (>50) of additional dependencies are added to the system,
>>> including lots of x11 related libs, avahi, dbus, cairo, opengl, etc.
>>> 
>>> This stems from installing pecl-imagick which results in pulling in
>>> ImageMagick, ghostscript, and cups.
>>> 
>>> Now, of course I can manually remove port options and reduce the number
>>> of additional dependencies, but I feel uneasy about the defaults now.
>>> 
>>> If I wanted to adjust an existing port to be less greedy with regards
>>> to dependencies, how would I go about that? Create a slave port?  
>> 
>> print/cups has its X11 option disabled by default.  It does depend on
>> devel/dbus which has its X11 option enabled by default, but this only
>> pulls in a few X11 dependencies, definitely not cairo.  
> 
> That is not true. Cairo does get pulled in.
> 
> Steps to recreate (on a 10.2 build box):
> 
> $ poudriere ports -c -p HEAD
> $ poudriere jail -c -v 10.2-RELEASE -j test -p HEAD
> 
> just to be safe, I add:
> 
> $ echo "OPTIONS_UNSET+= X11" > /usr/local/etc/poudriere.d/test-make.conf
> 
> select the one port to build:
> 
> $ echo "print/cups" > /usr/local/etc/poudriere.d/test-port-list
> $ poudriere options -j test -p HEAD -f 
> /usr/local/etc/poudriere.d/test-port-list
> 
> Then do a dry-run:
> 
> $ poudriere bulk -n -j test -p HEAD -f 
> /usr/local/etc/poudriere.d/test-port-list
> 
> This ends up telling me that the following 126 ports would be built:

I see.  It's a build dependency of gobject-introspection, but not a run
dependency so it shouldn't get installed when you install the cups package.
If you don't need Zeroconf support you can disable the AVAHI option in
print/cups.  If you do want it you can disable the OPENGL option in
graphics/cairo.  That should take out the most expensive dependencies like
llvm.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: cups update

[Tijl Coosemans]

On Sat, 12 Mar 2016 06:50:36 -0500 Stari Karp  wrote:
> Hi!
> 
> In /usr/ports/UPDATING is:
> 
> "20160311:
>   AFFECTS: print/cups-base, print/cups-client, print/cups-image
>   AUTHOR: t...@freebsd.org
> 
>   The cups-base, cups-client and cups-image packages have been combined
>   into one cups package.  If you build your own ports the easiest way
> to
>   update is to delete these packages first and then build and install
>   print/cups."
> 
> Does above mean that we don't need anymore cups-client, cups-image,
> cups-base which are still in the ports tree?

cups-client, cups-image and cups-base no longer exist in the ports tree.
There is only print/cups.

> I did as you wrote and I have a problems:
> pkg_libchk -o
> print/cups-filters: /usr/local/libexec/cups/filter/bannertopdf misses
> libfontembed.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/foomatic-rip misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/gstoraster misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/imagetopdf misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/imagetoraster misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/pdftoraster misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/rastertoescpx misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/rastertopclx misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/rastertopdf misses
> libcupsfilters.so.1
> print/cups-filters: /usr/local/libexec/cups/filter/texttopdf misses
> libfontembed.so.1

That's odd, because both libfontembed and libcupsfilters are provided by
print/cups-filters, so it's missing its own libraries.  Try rebuilding
and reinstalling print/cups-filters.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: print/cups overhaul (PR 207746) side-effects

[Tijl Coosemans]

On Fri, 11 Mar 2016 20:52:08 +0100 Martin Waschbüsch  
wrote:
> I just did a rebuild of packages for my webservers with poudriere.
> What I noticed was that via the print/cups overhaul (see PR 207746),
> quite a lot (>50) of additional dependencies are added to the system,
> including lots of x11 related libs, avahi, dbus, cairo, opengl, etc.
> 
> This stems from installing pecl-imagick which results in pulling in
> ImageMagick, ghostscript, and cups.
> 
> Now, of course I can manually remove port options and reduce the number
> of additional dependencies, but I feel uneasy about the defaults now.
> 
> If I wanted to adjust an existing port to be less greedy with regards
> to dependencies, how would I go about that? Create a slave port?

print/cups has its X11 option disabled by default.  It does depend on
devel/dbus which has its X11 option enabled by default, but this only
pulls in a few X11 dependencies, definitely not cairo.

print/cups-filters on the other hand depends on graphics/poppler and
that has an option to depend on cairo which is enabled by default.
So you can disable this option, or if your server doesn't need to print
you can uninstall cups-filters and its dependencies.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: help make port for opencoarrays

[Tijl Coosemans]

On Mon, 22 Feb 2016 09:50:01 + David Chisnall <thera...@freebsd.org> wrote:
> On 22 Feb 2016, at 09:01, Tijl Coosemans <t...@freebsd.org> wrote:
>> I think Fortran is fine.  It's C++ that's in a bad shape.  I think the
>> lang/gcc* ports need to be modified so libstdc++ sits on top of libcxxrt
>> instead of libsupc++.  Maybe David can say more about that (CCed).  
> 
> Ideally, they should be modified to just use libc++.  I thought that bapt
> had done this, but I might have misremembered.

Now I remember he created USES=compiler:gcc-c++11-lib which modifies
CXXFLAGS and LDFLAGS so g++ uses libc++ headers and library.  That works
inside the ports tree but it still leaves g++ cumbersome to use on the
command line.

What about libcompiler_rt, should the gcc ports use that library too
(for its personality function for instance)?

The base system still seems to be using the unwind implementation from
gcc.  Will that change at some point?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: help make port for opencoarrays

[Tijl Coosemans]

On Sun, 21 Feb 2016 13:51:28 -0800 (PST) Anton Shterenlikht  
wrote:
> From thie...@pompo.net Sun Feb 21 17:36:47 2016
>> Le mer 17 f_v 16 _ 23:50:37 +0100, Anton Shterenlikht 
>> _crivait_:  
>>> Please help/advise
>>> 
>>> https://github.com/sourceryinstitute/opencoarrays
>>> 
>>> It requires mpich built with at least gcc5.3,
>>> more specifically mpif90 built with gcc5.3 or gcc6.
>>> net/mpich has FORTRAN_USES=fortran, which I understand
>>> triggers lang/gcc.
>>> 
>>> Is it a good idea (or at all possible) to add
>>> an option to net/mpich to choose a particular
>>> gcc version?
>>> 
>>> Any other advice?  
>>
>> ATM Fortran in FreeBSD is in a very bad shape, and, as you know, we
>> encounter difficulties with several ports (french/aster, cad/salome,
>> etc.) caused by a mix between clang and Gcc, and thus libstdc++ /
>> libc++.  

I think Fortran is fine.  It's C++ that's in a bad shape.  I think the
lang/gcc* ports need to be modified so libstdc++ sits on top of libcxxrt
instead of libsupc++.  Maybe David can say more about that (CCed).

>> If building mpich with a newer Gcc could solve the problem with
>> opencoarrays, I'm afraid it would cause uncompatibilities in other
>> dependencies - but unfortunately I cannot suggest a better alternative!  
> 
> Well, I'm only asking for an option in the port.
> The default will not change.
> 
> I'll have a go locally and see what happens.
> But I'm not sure what option to use to build
> with e.g. GCC6. Is it this line?
> 
> FORTRAN_USES=   fortran
> 
> Or are you saying that building mpich with
> non-default gcc is problematic because all
> its dependencies should be built with the
> same gcc version?

Users can change ports tree default versions by setting DEFAULT_VERSIONS
in /etc/make.conf:

DEFAULT_VERSIONS=   gcc=5

DEFAULT_VERSIONS is handled in /usr/ports/Mk/bsd.default-versions.mk and
/usr/ports/Mk/Uses/fortran.mk uses it to select the Fortran compiler.
So with the line above the Fortran part of net/mpich will be built with
lang/gcc5.

In your opencoarray port I think you can do something like this:

...
USES=   fortran
...
.include 

.if ${GCC_DEFAULT:R} < 5
IGNORE= This port requires that the default GCC version is 5 or higher
.endif
...
.include 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: lang/gcc48 fails to build [on HEAD]

[Tijl Coosemans]

On Fri, 27 Nov 2015 13:59:54 +0100 Baptiste Daroussin  wrote:
> On Tue, Nov 10, 2015 at 07:23:40PM +0100, Rainer Hurling wrote:
>> I think I found the problem.
>> 
>> In my initial mail of this thread, I reported, that after upgrading
>> Freebsd 11.0-CURRENT to r290538 (including locale and localedef updates)
>> I am not able to build lang/gccXX any more. All I get are errors like
>> that in usr/ports/lang/gccXX/work/build/gcc:
>> 
>> 
>> In file included from .././../gcc-4.8.5/gcc/genflags.c:26:
>> In file included from ./tm.h:16:
>> ./options.h:4293:3: error: redefinition of enumerator 'OPT_C'
>>   OPT_C = 129,   /* -C */
>>   ^
>> 
>> 
>> After more than 20 of them the build stops with
>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>> 20 errors generated.
>> 
>> 
>> This is with locale for Germany:
>> LANG=de_DE.UTF-8
>> LC_CTYPE="de_DE.UTF-8"
>> LC_COLLATE="de_DE.UTF-8"
>> LC_TIME="de_DE.UTF-8"
>> LC_NUMERIC="de_DE.UTF-8"
>> LC_MONETARY="de_DE.UTF-8"
>> LC_MESSAGES="de_DE.UTF-8"
>> LC_ALL=
>> 
>> 
>> If I use 'LC_COLLATE="C"' for the build, the build works fine again:
>> 
>> cd /usr/ports/lang/gcc48
>> env LC_COLLATE="C" make
>> ...
>> 
>> 
>> So it seems, that something with the new 'locale' code in base of HEAD
>> is not working as expected here? (At least for other locales than US?)
>> 
>> I added bapt@, because he is the author introducing the new code into HEAD.
>> 
>> Hope, my explanations are clear enough to get the problem. Please feel
>> free to ask for more information, if needed.
> 
> Your explanations are good, sorry for the delay for my reply I will look
> into it.

I ran into this with lang/sdcc* which includes cpp from gcc.  At some
point the build runs an awk script (opt-gather.awk) that collects command
line options defined in *.opt files, sorts them and then puts them into
a C array.  The problem seems to be that FreeBSD awk takes collation into
account when sorting strings while GNU awk doesn't.  POSIX says that
FreeBSD is correct, so I was thinking of adding something like this to
bsd.port.mk:

USE_LOCALE?=C
LANG=   ${USE_LOCALE}
LC_ALL= ${USE_LOCALE}
.export LANG LC_ALL

This gives a consistent locale environment for port builds.  Some ports
already set LANG or LC_ALL.  That would have to be reviewed and I haven't
had time for that yet.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Proper way to get base iconv.h with autoconf?

[Tijl Coosemans]

On Sun, 5 Jul 2015 21:11:55 + Marcin Cieslak sa...@saper.info wrote:
 [X-posted, replies set to po...@freebsd.org]
 
 Hello,
 
 I have managed to upstream few things needed
 to make mono work on FreeBSD without local patches.
 
 Now I am stuck with the iconv detection code.
 
 Mono (or it's dumbled-down glib called eglib) need
 libiconv for two things - charset conversion:
 
 
 https://github.com/mono/mono/blob/master/eglib/src/giconv.c
 
 and getting default charset information
 
 https://github.com/mono/mono/blob/master/eglib/src/gunicode.c#L223
 
 The latter can be solved by using nl_langinfo (CODESET);
 and avoiding the need to link libcharset.so
 
 
 Mono uses standard iconv.m4 autoconf test, version 11
 https://github.com/mono/mono/blob/master/eglib/m4/iconv.m4
 
 which is developed in the gettext and gnulib (The GNU portability
 library):
 
 http://git.savannah.gnu.org/cgit/gnulib.git/log/m4/iconv.m4
 
 http://git.savannah.gnu.org/cgit/gettext.git/log/gettext-runtime/m4/iconv.m4
 
 Whenever -I/usr/local/include is added to CPPFLAGS for
 some reason (some other library, or jest using /usr/local as
 default prefix) the configure script fails to use base header
 and libc support and needs using GNU iconv as a dependency;
 because this simple test fails:
 
 
 configure:13910: checking for iconv
 configure:13934: cc -o conftest -g -O2 -g -D_GNU_SOURCE -I/usr/local/include  
 conftest.c  5
 /tmp/conftest-ee6d62.o: In function `main':
 /home/saper/sw/mono/eglib/conftest.c:42: undefined reference to 
 `libiconv_open'
 /home/saper/sw/mono/eglib/conftest.c:43: undefined reference to `libiconv'
 /home/saper/sw/mono/eglib/conftest.c:44: undefined reference to 
 `libiconv_close'
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 configure:13934: $? = 1
 configure: failed program was:
 | /* confdefs.h */
 | #define PACKAGE_NAME eglib
 | #define PACKAGE_TARNAME eglib
 | #define PACKAGE_VERSION 0.3
 | #define PACKAGE_STRING eglib 0.3
 | #define PACKAGE_BUGREPORT 
 http://bugzilla.xamarin.com/enter_bug.cgi?classification=Mono;
 
 --snip--
 
 | /* end confdefs.h.  */
 |
 | #include stdlib.h
 | #include iconv.h
 |
 | int
 | main ()
 | {
 | iconv_t cd = iconv_open(,);
 |iconv(cd,NULL,NULL,NULL,NULL);
 |iconv_close(cd);
 |   ;
 |   return 0;
 | }
 configure:13958: cc -o conftest -g -O2 -g -D_GNU_SOURCE -I/usr/local/include  
 conftest.c  /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib 5
 configure:13958: $? = 0
 configure:13968: result: yes
 
 The iconv.h test fails because /usr/local/include/iconv.h
 redefines iconv_open (and friends) to libiconv_open 
 
 Any ideas how to fix/improve the iconv.m4 detection code
 - to use the FreeBSD's base iconv.h and not require a library?

This works as intended and behaves exactly the same as on Linux.

When you don't have libiconv installed, base iconv is used.
When you have libiconv installed, libiconv is used.
When you have libiconv installed, but don't want to use it you can
add -DLIBICONV_PLUG to CPPFLAGS.

It's up to the user to choose one of these and not something that you
as a developer need to worry about.  So no changes to mono or iconv.m4
are needed.

When creating a port that uses iconv you just add USES=iconv to the port
Makefile and it should do the right thing.
___
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: gdb in ports

[Tijl Coosemans]

On Mon, 11 May 2015 16:21:42 -0400 Jason Woodward woodwa...@averesystems.com 
wrote:
 Hi all,
 
 I had sent this to Luca but maybe others might have an idea...
 
 
 I'm running into some difficulty debugging a live, multithreaded
 application.  This seems to be the case with the 7.8.x gdbs and 7.9 (both
 9.2 and 10 release).  When I attach, I see duplicates for the first thread:
 
   5Thread 817ff2c00 (LWP 100541) 0x00080bd6286c in poll () at
 poll.S:3
   4Thread 80efe8c00 (LWP 100546) 0x00080bd6286c in poll () at
 poll.S:3
   3Thread 80efe9000 (LWP 100878) 0x00080bd6286c in poll () at
 poll.S:3
 * 2Thread 80efe9400 (LWP 101124) 0x00080bd6286c in poll () at
 poll.S:3
 * 1Thread 80efe9400 (LWP 101124) 0x00080bd6286c in poll () at
 poll.S:3
 
 Trying to select 1 or 2 always ends up selecting 2:
 
 (gdb) thread 1
 [Switching to thread 2 (Thread 80efe9400 (LWP 101124))]
 #0  0x00080bd6286c in poll () at poll.S:3
 3   in poll.S
 (gdb) thread 2
 [Switching to thread 2 (Thread 80efe9400 (LWP 101124))]
 #0  0x00080bd6286c in poll () at poll.S:33   in poll.S
 (gdb)
 
 On top of this, when stepping through it seems threads that start and stop
 quickly have some sort of race condition that results in the thread
 tracking getting messed up.  Sometimes I'll end up on thread 74, other
 times I will be on a thread that has gone away and info threads does not
 show me associated with any of the active threads.  With 7.8.x I would see:
 
   Id   Target Id Frame
   75   Cannot find thread, Thread ID=101080, no thread to satisfy query
 
 
 Unsure if related, but after stepping through with 7.9, the following
 happens in fbsd_thread_wait():
 
 infrun.c:5530: internal-error: switch_back_to_stepped_thread: Assertion
 `!tp-control.trap_expected' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) y
 
 This is a bug, please report it.  For instructions, see:
 http://www.gnu.org/software/gdb/bugs/.
 
 infrun.c:5530: internal-error: switch_back_to_stepped_thread: Assertion
 `!tp-control.trap_expected' failed.
 A problem internal to GDB has been detected,further debugging may prove
 unreliable.
 Create a core file of GDB? (y or n) n

CC jhb.  Maybe he can help.
___
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: Makefile syntax for disabled NLS still looks for gettext

[Tijl Coosemans]

On Fri, 24 Apr 2015 11:31:18 +0300 Beeblebrox via freebsd-ports 
freebsd-ports@freebsd.org wrote:
 I have found 2 ports that fail to build when OPTIONS_FILE_UNSET+=NLS
 is used. The error is the usual GNU gettext tools not found problem.
 
 The Makefile of both ports have:
 NLS_CONFIGURE_ENABLE= nls  \  NLS_USES= gettext
 This should fix the problem but does not. What does the syntax need to
 be? I have seen examples like NLS_USES= gettext-runtime, but that
 modification did not correct the problem either.

Gettext consists of developer tools and a runtime component.  You can
depend on each separately like this:

USES=gettext-tools
NLS_CONFIGURE_ENABLE=nls
NLS_USES=gettext-runtime
___
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: Makefile syntax for disabled NLS still looks for gettext

[Tijl Coosemans]

On Fri, 24 Apr 2015 18:50:02 +0300 Beeblebrox via freebsd-ports 
freebsd-ports@freebsd.org wrote:
 Well, s**t, I spoke too soon.
 Solution works on host, not in poudriere.

Try the attached patch.Index: net/linphone/Makefile
===
--- net/linphone/Makefile	(revision 384665)
+++ net/linphone/Makefile	(working copy)
@@ -28,7 +28,7 @@ CPPFLAGS+=	-I${LOCALBASE}/include
 LIBS+=		-L${LOCALBASE}/lib
 INSTALLS_ICONS=	yes
 INSTALL_TARGET=	install-strip
-USES=		gmake libtool pathfix pkgconfig readline:port
+USES=		gettext-tools gmake libtool pathfix pkgconfig readline:port
 USE_GNOME=	gtk20 intltool libxml2
 USE_LDCONFIG=	yes
 
@@ -41,7 +41,7 @@ LDAP_LIB_DEPENDS=	libsasl2.so:${PORTSDIR
 LDAP_USE=		OPENLDAP=yes
 
 NLS_CONFIGURE_ENABLE=	nls
-NLS_USES=		gettext
+NLS_USES=		gettext-runtime
 
 NOTIFY_CONFIGURE_ENABLE=notify
 NOTIFY_LIB_DEPENDS=	libnotify.so:${PORTSDIR}/devel/libnotify
___
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: What causes libtool to relink?

[Tijl Coosemans]

On Sun, 22 Feb 2015 20:11:51 + (UTC) Christian Weisgerber 
na...@mips.inka.de wrote:
 I'm completely stuck on a problem report that comes down to this:
 /bin/sh ../../libtool --mode=install for a loadable module triggers
 libtool to attempt to relink the .la file on the reporter's system,
 which eventually fails.  I cannot reproduce this.  No such relinking
 happens here, libtool simply installs the .so file.
 
 What causes libtool to relink a .la file?

When it links to another library in the work directory.  Then it needs
to be relinked so it links to the installed copy of that library.
___
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: [CFT] sysutils/xfce4-power-manager 1.4.2

[Tijl Coosemans]

On Tue, 17 Feb 2015 23:14:34 + Olivier Duchateau olivi...@freebsd.org 
wrote:
 An update of sysutils/xfce4-power-manager is available for some time in
 Xfce devel repo. It's time to test it.  Settings manager and panel were
 rewritten, support of FreeBSD (and DragonFly) was enhanced.

upower 0.99 dropped support for suspend.  It's now supposed to be provided
by systemd or something:
http://cgit.freedesktop.org/upower/commit/?id=1ee642e705a63f5ad56a6b55e4bf5c4a64c959b8

Commands like the following no longer work for instance which means Xfce
no longer supports suspend.
dbus-send --system --print-reply --dest=org.freedesktop.UPower \
  /org/freedesktop/UPower org.freedesktop.UPower.Suspend

Does this update provide alternative dbus methods?  Or should upower be
downgraded to 0.9.x?
___
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: testing the value of ${CXX} in ports Makefile

[Tijl Coosemans]

On Thu, 29 Jan 2015 22:46:32 -0800 (PST) Don Lewis truck...@freebsd.org wrote:
 gcc46, gcc47, gcc48, and probably gcc5 (haven't tested that one yet) all
 work.  gcc49 requires a source patch.

Can't you make the patch work with all versions of gcc?
___
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: INSTALL_TARGET=install-strip runs into permission denied

[Tijl Coosemans]

On Sun, 18 Jan 2015 23:13:56 +0100 (CET) Gerald Pfeifer ger...@pfeifer.com 
wrote:
 On Sunday 2015-01-18 13:01, Tijl Coosemans wrote:
 Here is the build log:
 
 install   -m 555 fixinc.sh 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixinc.sh
 install  -s  -m 555 fixincl 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl
 install   -m 555 mkheaders 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/mkheaders
 test -z 'strip' || strip 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl
 strip: unable to copy file 
 '.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl';
  reason: Permission denied
 Makefile:191: recipe for target 'install-strip' failed
 gmake[3]: *** [install-strip] Error 1
 This strip command seems redundant.  Isn't fixincl already stripped by
 the install -s command above?
 
 Good point.
 
 What does this piece of the log look like outside the ports framework?
 
 /usr/bin/install -c fixinc.sh 
 .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixinc.sh
 /usr/bin/install -c fixincl 
 .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
 /usr/bin/install -c mkheaders 
 .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/mkheaders
 test -z 'strip' || strip 
 .../gcc-ref8-amd64/libexec/gcc/x86_64-unknown-freebsd8.4/5.0.0/install-tools/fixincl
 gmake[2]: Leaving directory '.../OBJ-0118-1528/fixincludes'
 
 (I also tried setting STRIP_CMD to true, alas that is not used by GCC.)

Try adding BINMODE=755 to the port Makefile or STRIP=true to CONFIGURE_ARGS
___
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: INSTALL_TARGET=install-strip runs into permission denied

[Tijl Coosemans]

On Sun, 18 Jan 2015 12:18:27 +0100 (CET) Gerald Pfeifer ger...@pfeifer.com 
wrote:
 The ports q/a framework has been suggesting this for a while, so 
 I added INSTALL_TARGET=install-strip to lang/gcc5/Makefile.
 
 Using install-strip for vanilla GCC builds (from source, outside
 the FreeBSD Ports framework) works just fine.
 
 In the context of Ports this runs into a permission problem since
 install sets binaries to r-x, at which point strip then fails.
 
 Here is the build log:
 
 install   -m 555 fixinc.sh 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixinc.sh
 install  -s  -m 555 fixincl 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl
 install   -m 555 mkheaders 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/mkheaders
 test -z 'strip' || strip 
 .../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl
 strip: unable to copy file 
 '.../prefix/gcc5/libexec/gcc5/gcc/i386-portbld-freebsd10.1/5.0.0/install-tools/fixincl';
  reason: Permission denied
 Makefile:191: recipe for target 'install-strip' failed
 gmake[3]: *** [install-strip] Error 1

This strip command seems redundant.  Isn't fixincl already stripped by
the install -s command above?

What does this piece of the log look like outside the ports framework?
___
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: Installing openssl without gcc or binutils dependents

[Tijl Coosemans]

On Sat, 17 Jan 2015 05:05:48 +1100 Dewayne Geraghty 
dewayne.gerag...@heuristicsystems.com.au wrote:
 I would appreciate advise on the best approach to install openssl that
 has been built with gcc48 without needing to install gcc and binutils
 into the target machine?
 
 Background
 Attempting to run sshd or openssl resulted in
 signal 4, illegal instruction.
 The target systems are i386 boxes running the VIA C3  chipset using 10.1
 Stable and packages built from svnlite update of ports from 2014-12-30.
 
 The suspect file is libcrypto.so.8.
 
 All systems are built using clang and custom compiler directives, in
 this case,
 -march=c3-2 -mtune=c3-2
 and other attempts of building used CPUTYPE=c3-2 which generated the
 same signal 4 when run on the target platform; march=pentium3 had same
 result.  The build occurs within an i386 jail on an amd64 FreeBSD 10.1
 Stable, base system.
 
 Solution
 Inserted into /usr/ports/security/openssl/Makefile
 USE_GCC=yes
 resulted in a successful installation and running of sshd and curl which
 was the objective.  However the openssl now has a dependency on gcc48
 and binutils, which wont fit into the embedded image of 64MB (and isn't
 needed)
 
 I would prefer to use pkg tools to install applications rather than the
 crude workaround of
 tar -xpPf /kits/openssl-1.0.1_16.txz /usr/local/bin /usr/local/lib
 
 I suspect something in /usr/ports/Mk would need a flag ??
 
 Advise appreciated...
 
 Kind regards, Dewayne.
 PS Fortunate aside, geom_eli only requires openssl header files,
 otherwise the base system would also require gcc48 for these target machines

I'm sure toolchain@ would want to know what the faulting instruction
is.  Do you have a core dump that you can examine?

-march=c3-2 enables SSE instructions.  Are you sure your chip supports
that?  Maybe you need -march=c3.
___
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: reports down?

[Tijl Coosemans]

On Wed, 24 Dec 2014 12:41:42 -0800 (PST) Anton Shterenlikht me...@bris.ac.uk 
wrote:
 redports.org times out.
 Is it down?

It's been down for many weeks.  I heard something was misconfigured on
the last visit to the NYI site.
___
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: Removal of XAA acceleration in X.org, and older NVIDIA GeForce

[Tijl Coosemans]

On Mon, 22 Dec 2014 19:45:35 +0100 Mark Martinec mark.martinec+free...@ijs.si 
wrote:
 /usr/ports/UPDATING:
 20141219:
  AFFECTS: users of x11/xorg and all xorg ports
  AUTHOR: dumbb...@freebsd.org
  The X.Org server (x11-servers/xorg-server) is updated to 1.14.
 
 http://blogs.freebsdish.org/graphics/2014/11/19/xserver-1-14-update-ready/
 Changes since xserver 1.12
   The most visible change is the removal of XAA. This is a 2D 
 acceleration
 method which was deprecated some time ago, in favor of EXA or 
 Intel-specific’s
 UXA or SNA. For the end user, this means that some drivers 
 (xf86-video-*)
 are not supported anymore, mostly for older GPUs according to Phoronix.
 If you encounter this case, please let us know.
 
 Ouch!!! Upgrading X -related ports went with no problems (FreeBSD 10.1),
 but I didn't realize the outcome would be so terrible. Scrolling or
 refreshing a full-screen page in a web browser now feels like in the
 good old days of a 19200 bps line and a glass terminal. Even scrolling
 or paging through plain text with 'less' or editor on a KDE konsole
 or xterm feels sluggish. Certainly the size of the display does not
 help in this regards (2560x1600).
 
 The Xorg.0.log reports:
NV: Found NVIDIA GeForce 7300 GT at 02@00:00:0
 
 Now I fear that upgrading ports on my other workstation
 (GeForce 7600 GS) would lead to similar results.
 
 I know these graphics boards are not the latest of breed
 (the CPU and mb are still fairly decent). They were chosen for being
 fan-less, and coping sufficiently well with 2D and text even on
 largish displays.
 
 So is my only choice now replacing graphics with heat- and noise-
 sources I don't really need, or being stuck with frozen ports?
 I wonder if I'm the only one in this situation.

This card is still supported by x11/nvidia-driver-304
___
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: Why was ispell removed?

[Tijl Coosemans]

On Mon, 1 Dec 2014 13:58:04 -0700 Stephen Fisher sfis...@sdf.org wrote:
 I recently noticed that the ispell port has been removed in favor of the 
 aspell-ispell port (ispell compatibility script for aspell).  Does 
 anyone know why it was removed?  All I see on Fresh Ports is that it 
 was deprecated and finally removed in January of this year.  
 
 (The ispell script for aspell doesn't fully replicate ispell 
 functionality such as checking words on the command line as shown below)
 
 Real ispell:
 ispell
 @(#) International Ispell Version 3.3.02 12 Jun 2005
 word: word
 ok
 
 
 word: ^D
 
 
 
 aspell script:
 ispell
 Ispell compatibility script for Aspell.
 Usage: /usr/local/bin/ispell [options] -a|-l|-v[v]|-c|-e[1-4]|file

Give hunspell a try.  It's actively maintained and backed by Mozilla,
OpenOffice, LibreOffice,...

% hunspell -d en_US
Hunspell 1.3.3
Write a sontence here
*
*
 sontence 2 8: sentence, consistence
*
___
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: Why was ispell removed?

[Tijl Coosemans]

On Tue, 2 Dec 2014 10:00:31 -0800 Kevin Oberman rkober...@gmail.com wrote:
 On Tue, Dec 2, 2014 at 12:43 AM, Tijl Coosemans t...@freebsd.org wrote:
 Give hunspell a try.  It's actively maintained and backed by Mozilla,
 OpenOffice, LibreOffice,...

 % hunspell -d en_US
 Hunspell 1.3.3
 Write a sontence here
 *
 *
  sontence 2 8: sentence, consistence
 *
 
 I'll admit that I may just be too lazy to hunt around for it, but:
   hunspell -a en_US
 @(#) International Ispell Version 3.2.06 (but really Hunspell 1.3.3)
 Can't open en_US.
 Exit 1
 
 I looked though the system and found the following en_US dictionaries:
 /usr/local/lib/firefox/dictionaries/
 /usr/local/lib/libxul/dictionaries/
 /usr/local/lib/linux-libgtkembedmoz/components/myspell/
 I tried specifying one as the path (hunspell -p
 /usr/local/lib/firefox/dictionaries/ -d en_US, but it then said:
 Can't open affix or dictionary files for dictionary named en_US. (Got the
 same message for -d en-US)
 
 I have no idea why it can't open these files. They are present and
 readable. In any case, I am at a loss on how to make hunspell work.

Install textproc/en-hunspell
___
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: Tracking Binary Ports/Pkgs Tree

[Tijl Coosemans]

On Sat, 29 Nov 2014 21:58:17 -0700 Reed A. Cartwright cartwri...@asu.edu 
wrote:
 I have been using poudriere for a while to build packages locally.  I
 recently reduced the package server to just the ports that I need to
 have custom options.  I want to rely on the freebsd pkgs as much as I
 can.
 
 However, this has proven difficult because my ports directory is often
 ahead of the one that corresponded to the latest set of binary
 packages.  I read where packages are build off of a snapshot of the
 ports tree on every wednesday.
 
 Is this snapshot saved anywhere?  If so, I would like to be able to
 sync my local ports directory against it.  If not, I would like to
 request such ability.

Package build information is available on http://beefy1.isc.freebsd.org/
and http://beefy2.isc.freebsd.org/ and each package set lists the
port revision that was used.  For instance on
http://beefy1.isc.freebsd.org/build.html?mastername=10i386-defaultbuild=2014-11-26_03h32m47s
it says svn://svn0.us-west.freebsd.org/ports/head@373435

Then you can update your ports tree to that revision with:
svn up -r 373435
___
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: Reducing the size of the ports tree (brainstorm v2)

[Tijl Coosemans]

On Mon, 03 Nov 2014 09:22:09 +0100 Matthias Andree matthias.and...@gmx.de 
wrote:
 Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin:
 Hi all,
 
 tijl@ spotted an interesting point, distinfo and pkg-descr files files
 convenient are taking a lot of space for free, we can reduce the size of 
 the
 while ports tree by a factor 2 by simply merging them into one of the other
 files (Makefile and/or pkg-plist) from my testing it really devides
 significantly the size of the tree.
 
 Problem is how to merge them if we want to.
 
 What we do not want to loose:
 - Easyness of parsing distinfo
 - Easyness to get informations about the description
 
 so far I have not been able to figure out a user friendly way
 
 Ideas I got so far only concerns pkg-descr:
 Adding an entry in the Makefile for the WWW:
 WWW= bla
 or an entry in the plist: @www http...
 
 for the description the Makefile is not suitable as multi line entry in
 Makefiles are painful
 Maybe a new keyword:
 @descr EOD
 mydesc
 in 
 multiline
 EOD
 
 which could easily be added to the plist parser in pkg. But I'm do not
 find that very friendly in particular for make(1) to extract the data.
 
 Concerning the distinfo I have no idea.
 
 so this mail is a call of ideas :), if nothing nice ideas is found we
 will just do nothing here :)
 
 My urgent recommendation is to leave it as is.  Even if it wastes 200
 MB.  Space is so cheap these days it's not worth introducing new
 instabilities, re-train all contributors and all that.
 
 We haven't even shaken off all the staging and pkg fall-out, and now
 we're talking about the next revolution.

The numbers on http://beefy1.isc.freebsd.org/ and
http://beefy2.isc.freebsd.org/ have never been better.

 And if we really decided that we want to change things, we would need
 these things BEFORE the implementation:
 
 1. a clear list of the problems.
 1a. Space does not count, see above.
 1b. Insufficient tools (SVN) do not count.  If the tools are bad, we
 need other tools, not change our way of doing things.

Other tools won't change anything.  It's the file system that would
have to change which is not going to happen.  When the ports tree was
created disks were much smaller and file systems were better (still not
good) at storing small files.  Today disks are much bigger and file
systems have adapted to that.  Now it's time for the ports tree to adapt.

Here's another way to look at it.  Suppose that distinfo never existed
and we always specified file sizes and checksums in the Makefile.  Then
someone would come along and suggest to do just that, put file sizes and
checksums in a separate file named distinfo.  Nobody would support that.
___
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: Reducing the size of the ports tree (brainstorm v2)

[Tijl Coosemans]

On Sun, 2 Nov 2014 18:16:23 + RW rwmailli...@googlemail.com wrote:
 On Sat, 1 Nov 2014 00:07:23 +0100
 Tijl Coosemans wrote: 
 On Fri, 31 Oct 2014 19:56:21 +0100 Baptiste Daroussin
 b...@freebsd.org wrote:
 tijl@ spotted an interesting point, distinfo and pkg-descr files
 files convenient are taking a lot of space for free, we can
 reduce the size of the while ports tree by a factor 2 by simply
 merging them into one of the other files (Makefile and/or
 pkg-plist) from my testing it really devides significantly the size
 of the tree.
 
 Problem is how to merge them if we want to.
 
 What we do not want to loose:
 - Easyness of parsing distinfo
 - Easyness to get informations about the description
 
 I think it's worth remembering that this saves an amount of storage
 that can be had for around 1 penny/cent. The threshold for this being
 more trouble than it's worth is pretty low.

The reason I looked into this is because many subversion operations
are slow on the ports tree.  For me it's about saving time there and
not so much about saving disk space.
___
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: Reducing the size of the ports tree (brainstorm v2)

[Tijl Coosemans]

On Fri, 31 Oct 2014 19:56:21 +0100 Baptiste Daroussin b...@freebsd.org wrote:
 Hi all,
 
 tijl@ spotted an interesting point, distinfo and pkg-descr files files
 convenient are taking a lot of space for free, we can reduce the size of the
 while ports tree by a factor 2 by simply merging them into one of the other
 files (Makefile and/or pkg-plist) from my testing it really devides
 significantly the size of the tree.
 
 Problem is how to merge them if we want to.
 
 What we do not want to loose:
 - Easyness of parsing distinfo
 - Easyness to get informations about the description
 
 so far I have not been able to figure out a user friendly way
 
 Ideas I got so far only concerns pkg-descr:
 Adding an entry in the Makefile for the WWW:
 WWW= bla
 or an entry in the plist: @www http...
 
 for the description the Makefile is not suitable as multi line entry in
 Makefiles are painful
 Maybe a new keyword:
 @descr EOD
 mydesc
 in 
 multiline
 EOD
 
 which could easily be added to the plist parser in pkg. But I'm do not find 
 that
 very friendly in particular for make(1) to extract the data.
 
 Concerning the distinfo I have no idea.
 
 so this mail is a call of ideas :), if nothing nice ideas is found we will 
 just
 do nothing here :)

For distinfo I was thinking about something like this in the Makefile:

DIST_FILES= FOO BAR

FOO_FILE=   foo-1.0
FOO_SITES=  http://www.example.com/foo/
FOO_SIZE=   12345
FOO_SHA256= 0123456789abcdef.

BAR_FILE=   bar-2.0
BAR_SITES=  http://www.example.com/bar/
BAR_SIZE=   54321
BAR_SHA256= .fedcba9876543210

If bsd.port.mk then contained this:
DIST_FILES?=DIST
DIST_FILE?= 
${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}

Then for ports with a single distfile named after PORTNAME (the large
majority), the above would reduce to:

DIST_SITES= http://www.example.com/foo/
DIST_SIZE=  12345
DIST_SHA256=0123456789abcdef.

Also, if BAR_SITES is the same as FOO_SITES you can use somthing like
BAR_SITES=${FOO_SITES} of course.


pkg-descr and pkg-plist will be around for a while I think but maybe pkg
could support an alternative syntax that is similar to the manifest file
included in the package.  This file (named Manifest maybe?) would include
a comment, description, install/deinstall scripts and a list of files and 
directories like this (copied from https://github.com/freebsd/pkg):

comment: Short package description
desc: |-
  Long package description
  goes here
www: http:///www.example.com/
files: |-
  bin/foo
  lib/bar
dirs: |-
  some/dir
scripts:
  post-install: |-
#!/bin/sh
echo post-install
  pre-install: |-
#!/bin/sh
echo pre-install
___
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: compiling non-ports source: how to handle QT3?

[Tijl Coosemans]

On Tue, 21 Oct 2014 11:40:29 -0700 (PDT) Beeblebrox zap...@berentweb.com 
wrote:
 I'm trying to compile pdfedit from github (not in ports tree).
 configure gives this error:
 ./configure --with-t1-library=${LOCALBASE}/lib
 -with-t1-includes=${LOCALBASE}/include
 checking for QT qmake... configure: error: unable to find qmake for QT3
 
 I have devel/qt4-qt3support installed on the system. I assume the problem
 should be something simple like a setenv variable or creating a symlink or
 entry in /etc/libmap.conf.

Install devel/qmake?
___
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: sqlite3 breakage

[Tijl Coosemans]

On Sun, 19 Oct 2014 14:28:08 +0100 John freebsd-po...@potato.growveg.org 
wrote:
 sqlite3 appears to be breaking things in multiple places.
 
 using generic amd64 r273255 and ports 371178
 
 I get errors like this whenever sqlite3 is called as a dependency. So, in 
 /data/ports/devel/libsoup-gnome:
 
 ===  Building for libsoup-gnome-2.40.3_4
 cd /data/ports/devel/libsoup-gnome/work/libsoup-2.40.3/libsoup  gmake 
 libsoup-gnome-2.4.la
 gmake[1]: Entering directory 
 '/data/ports/devel/libsoup-gnome/work/libsoup-2.40.3/libsoup'
   CC   soup-cookie-jar-sqlite.lo
   CC   soup-gnome-features.lo
   CC   soup-proxy-resolver-gnome.lo
   CC   soup-password-manager-gnome.lo
   CCLD libsoup-gnome-2.4.la
 /usr/bin/ld: /usr/local/lib/libsqlite3.a(sqlite3.o): relocation R_X86_64_32S 
 against `a local symbol' can not be used when making a shared object; 
 recompile with -fPIC
 /usr/local/lib/libsqlite3.a: could not read symbols: Bad value
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 Makefile:721: recipe for target 'libsoup-gnome-2.4.la' failed
 gmake[1]: *** [libsoup-gnome-2.4.la] Error 1
 gmake[1]: Leaving directory 
 '/data/ports/devel/libsoup-gnome/work/libsoup-2.40.3/libsoup'
 *** Error code 2
 
 Stop.
 make: stopped in /data/ports/devel/libsoup-gnome
 
 ###
 
 in pidgin:
 
 aking all in cap
 gmake[4]: Entering directory 
 '/data/ports/net-im/pidgin/work/pidgin-2.10.9/pidgin/plugins/cap'
   CC cap.lo
 cap.c:97:9: warning: assigning to 'char *' from 'const char *' discards 
 qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
 sta_id = purple_status_get_id(get_status_for(buddy));
^ ~~~
 1 warning generated.
   CCLD   cap.la
 /usr/bin/ld: /usr/local/lib/libsqlite3.a(sqlite3.o): relocation R_X86_64_32S 
 against `a local symbol' can not be used when making a shared object; 
 recompile with -fPIC
 /usr/local/lib/libsqlite3.a: could not read symbols: Bad value
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 Makefile:482: recipe for target 'cap.la' failed
 gmake[4]: *** [cap.la] Error 1
 gmake[4]: Leaving directory 
 '/data/ports/net-im/pidgin/work/pidgin-2.10.9/pidgin/plugins/cap'
 Makefile:902: recipe for target 'all-recursive' failed
 gmake[3]: *** [all-recursive] Error 1
 gmake[3]: Leaving directory 
 '/data/ports/net-im/pidgin/work/pidgin-2.10.9/pidgin/plugins'
 Makefile:895: recipe for target 'all-recursive' failed
 gmake[2]: *** [all-recursive] Error 1
 gmake[2]: Leaving directory 
 '/data/ports/net-im/pidgin/work/pidgin-2.10.9/pidgin'
 === Compilation failed unexpectedly.
 Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
 the maintainer.
 *** Error code 1
 
 Stop.
 make[1]: stopped in /data/ports/net-im/pidgin
 *** Error code 1
 
 Stop.
 make: stopped in /data/ports/net-im/pidgin
 
 
 
 Rebuilt sqlite3 from the ports, which made no difference.
 There are other ports affected. How can I fix this?

Check that you have these files in /usr/local/lib:

libsqlite3.a
libsqlite3.so
libsqlite3.so.0
libsqlite3.so.0.8.6

If any are missing then make sure you have the latest version of pkg.
It fixes a bug that allowed packages with missing files to be installed.
Then build databases/sqlite3 using 'script build.log make install' and
email us build.log.
___
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: sqlite3 breakage

[Tijl Coosemans]

On Sun, 19 Oct 2014 19:21:38 +0100 John freebsd-li...@potato.growveg.org 
wrote:
 Hello, that was quick! :D
 
  Check that you have these files in /usr/local/lib:
  
  libsqlite3.a
  libsqlite3.so
  libsqlite3.so.0
  libsqlite3.so.0.8.6
  
  If any are missing then make sure you have the latest version of pkg.
  It fixes a bug that allowed packages with missing files to be installed.
  Then build databases/sqlite3 using 'script build.log make install' and
  email us build.log.
 
 root@:/usr/local/lib # pkg -v
 1.3.8
 
 ~ # cd /usr/local/lib
 
 ~ # root@:/usr/local/lib # ls -la libsqlite3.a
 -rw-r--r--  1 root  wheel  1441616 Oct 19 14:47 libsqlite3.a
 
 root@:/usr/local/lib # ls -la libsqlite3.so
 lrwxr-xr-x  1 root  wheel  19 Oct 19 14:47 libsqlite3.so - 
 libsqlite3.so.0.8.6
 
 root@:/usr/local/lib # ls -la libsqlite3.so.0
 lrwxr-xr-x  1 root  wheel  19 Oct 19 14:47 libsqlite3.so.0 - 
 libsqlite3.so.0.8.6
 
 root@:/usr/local/lib # ls -la libsqlite3.so.0.8.6
 -rwxr-xr-x  1 root  wheel  1046592 Oct 19 14:47 libsqlite3.so.0.8.6
 
 root@:/usr/local/lib #
 
 I deinstalled then cleaned, rebuilt again and am attaching the build log as 
 requested (this is 15kb)

Try building the ports without ccache.
___
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: On Docs option and custom build target

[Tijl Coosemans]

On Wed, 24 Sep 2014 23:54:19 +0200 Fernando Apesteguía 
fernando.apesteg...@gmail.com wrote:
 On Wed, Sep 24, 2014 at 8:52 PM, Tijl Coosemans t...@freebsd.org wrote:
 On Tue, 23 Sep 2014 23:23:31 +0200 Fernando Apesteguía 
 fernando.apesteg...@gmail.com wrote:
 I have a Makefile for an application that provides both examples and
 documentation. I created the two options in the Makefile (both enabled
 by default).
 The package doesn't provide any flags stock like --with-docs or
 --with-examples, so I have a custom target like this:

 do-build:
 @cd ${BUILD_WRKSRC}/  ${MAKE}
 .if ${PORT_OPTIONS:MDOCS}
 @cd ${BUILD_WRKSRC}/  ${MAKE_CMD} doc
 .endif

 You don't have to override do-build like this.  You can build the
 documentation from a post-build target.
 
 Thanks. Changed.
 
 However, when I try to run this in poudriere, I get the following error:

 make[1]: don't know how to make doc. Stop

 make[1]: stopped in /wrkdirs/usr/ports/graphics/code-eli/work/.build
 *** Error code 2

 Does the makefile in BUILD_WRKSRC actually have a doc target?  Is doc
 a subdirectory maybe?
 
 Yes it does.
 
 In fact, with port test builds fine with the same code (change
 directory and ${MAKE} doc). There is a doc.dir subdirectory in
 BUILD_WRKSRC/CMakeFiles. The doc target basically gets a Doxygen
 configuration file and runs doxygen on the whole library code.

Poudriere tests the port in a clean environment so check the build log
to see if any dependencies (like doxygen) are missing.
___
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: On Docs option and custom build target

[Tijl Coosemans]

On Tue, 23 Sep 2014 23:23:31 +0200 Fernando Apesteguía 
fernando.apesteg...@gmail.com wrote:
 I have a Makefile for an application that provides both examples and
 documentation. I created the two options in the Makefile (both enabled
 by default).
 The package doesn't provide any flags stock like --with-docs or
 --with-examples, so I have a custom target like this:
 
 do-build:
 @cd ${BUILD_WRKSRC}/  ${MAKE}
 .if ${PORT_OPTIONS:MDOCS}
 @cd ${BUILD_WRKSRC}/  ${MAKE_CMD} doc
 .endif

You don't have to override do-build like this.  You can build the
documentation from a post-build target.

 However, when I try to run this in poudriere, I get the following error:
 
 make[1]: don't know how to make doc. Stop
 
 make[1]: stopped in /wrkdirs/usr/ports/graphics/code-eli/work/.build
 *** Error code 2

Does the makefile in BUILD_WRKSRC actually have a doc target?  Is doc
a subdirectory maybe?
___
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: x11/libXcm: r351936 and using libtool

[Tijl Coosemans]

On Mon, 22 Sep 2014 22:07:58 +0400 Boris Samorodov b...@passap.ru wrote:
 Hi Tijl, All,
 
 The revision 351936 only bumped PORTREVISION. Assume that
 USES=libtool:keepla should be added too.
 
 Now, AFAIK no port uses those *.la file I try to go to
 USES=libtool. However I get:
 -
 libtool: install: /usr/bin/install -c .libs/libXcmEDID.lai
 /usr/ports/x11/libXcm/work/stage/usr/local/lib/libXcmEDID.la
 -
 
 For now I leave USES=libtool:keepla.
 
 Any help is appreciated. Thanks.

The Makefile contains XORG_CAT=lib which causes Mk/bsd.xorg.mk to
add USES=libtool:keepla.  I'm not sure if XORG_CAT is correct for
this port.  It isn't part of the Xorg project is it?
___
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: Can't build lang/gcc port on i386: segmentation fault

[Tijl Coosemans]

On Fri, 12 Sep 2014 17:26:24 +0400 Andrey Chernov a...@freebsd.org wrote:
 On 12.09.2014 17:06, Andrey Chernov wrote:
 On 12.09.2014 16:42, Gerald Pfeifer wrote:
 On Fri, 12 Sep 2014, Andrey Chernov wrote:
 As I just found, it builds with BOOTSTRAP nice, so apparently clang
 makes some damage. You can see CFLAGS in the log. Swap is 4GB I think it
 is large enough. Nothing special otherwise.
 BTW, previous 4.7* as lang/gcc build fine even without BOOTSTRAP.

 I am curious, what happens when you try lang/gcc48?

 My expectation would be both lang/gcc and lang/gcc48 to behave
 the same, since it's a very similar codebase, gcc48 just a bit
 newer on the same branch.

 We could make BOOTSTRAP the default for lang/gcc, though not 
 doing that and thus building a lot faster has been one of the 
 features of lang/gcc. -- Since it does not reproduce for me,
 do others see the same failure?
 
 Segfault is exact the same but comes from strange place - in the middle
 of configure check. I will try with MAKE_JOBS_UNSAFE=yes

 With MAKE_JOBS_UNSAFE error finally shown in proper place, but remains 
 (it was misplaces in original lang/gcc report too, different file compiled 
 in the log, not O2g.gch):

Can you try with NO_CPU_CFLAGS=yes
___
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