finance/aqbanking lost command line tool with update

[Jan Henrik Sylvester]

After ports/129598, finance/aqbanking was recently updated from 2.3.3 to 
3.8.1. This caused a major regression for me, as I was using the command 
line aqbanking-tool (and some shell scripts around it) as the banking 
client. In the 3.X series, that is not included anymore.


There is AqBanking-CLI now, for which a version has been put under GPL 
last week: 
http://sourceforge.net/mailarchive/forum.php?thread_name=200905062348.19839.aquamaniac%40gmx.de&forum_name=aqbanking-devel


It seems to be included in 3.99.12rc6 and 3.99.12rc7 according to the 
version history.


With this loss in functionality, it would have been nicer if the 2.X 
version was kept as finance/aqbanking2 -- at least until 
finance/aqbanking is upgraded to 4.X.


I guess I should try to downgrade the port and hope for 4.X to appear 
soon. I could try to create finance/aqbanking-devel from the rc, but if 
that is nontrivial, I guess I currently do not have the time to do it.


Did I miss something? Any further suggestions? Is anyone else affected? 
Did anyone start to work on the 4.X version?


Cheers,
Jan Henrik
___
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"

More libgmp leftovers due to indirect dependencies

[Jan Henrik Sylvester]

math/libqalculate and print/lilypond both link libgmp.so.X, but have not 
been bumped with the libgmp.so.7->libgmp.so.8 update as they do not list 
the dependency.


math/libqalculate pulls in libgmp via libcln and print/lilypond via 
libguile, thus the default package will always depend on libgmp.


Both should have their PORTREVISION bumped and 
gmp.8:${PORTSDIR}/math/libgmp4 added to LIB_DEPENDS not to be missed 
next time.


Cheers,
Jan Henrik


diff -u math/libqalculate/Makefile~ math/libqalculate/Makefile
--- math/libqalculate/Makefile~ 2008-06-06 15:44:00.0 +0200
+++ math/libqalculate/Makefile  2009-05-16 12:49:18.0 +0200
@@ -7,14 +7,15 @@

 PORTNAME=  libqalculate
 PORTVERSION=   0.9.6
-PORTREVISION=  2
+PORTREVISION=  3
 CATEGORIES=math
 MASTER_SITES=  SF/qalculate

 MAINTAINER=po...@freebsd.org
 COMMENT=   A a multi-purpose desktop calculator (backend library)

-LIB_DEPENDS=   cln.5:${PORTSDIR}/math/cln
+LIB_DEPENDS=   cln.5:${PORTSDIR}/math/cln \
+   gmp.8:${PORTSDIR}/math/libgmp4

 USE_GNOME= glib20 gnomehack gnometarget intlhack libxml2
 USE_GETTEXT=   yes
diff -u print/lilypond/Makefile~ print/lilypond/Makefile
--- print/lilypond/Makefile~2009-01-28 15:46:19.0 +0100
+++ print/lilypond/Makefile 2009-05-16 12:47:32.0 +0200
@@ -9,7 +9,7 @@

 PORTNAME=  lilypond
 PORTVERSION=   2.11.65
-PORTREVISION=  1
+PORTREVISION=  2
 CATEGORIES=print audio
 MASTER_SITES=  http://download.linuxaudio.org/lilypond/sources/v2.11/:src \
${MASTER_SITE_LOCAL}/gahr/:fonts \
@@ -26,7 +26,8 @@
rarian-sk-config:${PORTSDIR}/textproc/rarian \
texi2html:${PORTSDIR}/textproc/texi2html \
texi2dvi:${PORTSDIR}/print/texinfo
-LIB_DEPENDS=   guile.20:${PORTSDIR}/lang/guile
+LIB_DEPENDS=   guile.20:${PORTSDIR}/lang/guile \
+   gmp.8:${PORTSDIR}/math/libgmp4
 RUN_DEPENDS=   latex:${PORTSDIR}/print/teTeX \
mftrace:${PORTSDIR}/print/mftrace

diff -u math/libqalculate/Makefile~ math/libqalculate/Makefile
--- math/libqalculate/Makefile~ 2008-06-06 15:44:00.0 +0200
+++ math/libqalculate/Makefile  2009-05-16 12:49:18.0 +0200
@@ -7,14 +7,15 @@
 
 PORTNAME=  libqalculate
 PORTVERSION=   0.9.6
-PORTREVISION=  2
+PORTREVISION=  3
 CATEGORIES=math
 MASTER_SITES=  SF/qalculate
 
 MAINTAINER=po...@freebsd.org
 COMMENT=   A a multi-purpose desktop calculator (backend library)
 
-LIB_DEPENDS=   cln.5:${PORTSDIR}/math/cln
+LIB_DEPENDS=   cln.5:${PORTSDIR}/math/cln \
+   gmp.8:${PORTSDIR}/math/libgmp4
 
 USE_GNOME= glib20 gnomehack gnometarget intlhack libxml2
 USE_GETTEXT=   yes
diff -u print/lilypond/Makefile~ print/lilypond/Makefile
--- print/lilypond/Makefile~2009-01-28 15:46:19.0 +0100
+++ print/lilypond/Makefile 2009-05-16 12:47:32.0 +0200
@@ -9,7 +9,7 @@
 
 PORTNAME=  lilypond
 PORTVERSION=   2.11.65
-PORTREVISION=  1
+PORTREVISION=  2
 CATEGORIES=print audio
 MASTER_SITES=  http://download.linuxaudio.org/lilypond/sources/v2.11/:src \
${MASTER_SITE_LOCAL}/gahr/:fonts \
@@ -26,7 +26,8 @@
rarian-sk-config:${PORTSDIR}/textproc/rarian \
texi2html:${PORTSDIR}/textproc/texi2html \
texi2dvi:${PORTSDIR}/print/texinfo
-LIB_DEPENDS=   guile.20:${PORTSDIR}/lang/guile
+LIB_DEPENDS=   guile.20:${PORTSDIR}/lang/guile \
+   gmp.8:${PORTSDIR}/math/libgmp4
 RUN_DEPENDS=   latex:${PORTSDIR}/print/teTeX \
mftrace:${PORTSDIR}/print/mftrace
 
___
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"

Help test aqbanking-4.0.0 (especially with gnucash)

[Jan Henrik Sylvester]

As I wrote two weeks ago, the aqbanking-2.3.3 to 3.8.1 update took away 
the command line banking client I use. Thus, I am eager to get 4.0.0, 
which includes a new one.


I made a patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=135161

I need someone using gnucash with aqbanking to check the functionality 
of aqbanking-4.0.0 -- both do compile.


I cannot use the new aqbanking-cli, yet. Knowing if gnucash works would 
help me to narrow down the cause.


Converting the configuration from 2.X did not work out completely 
(aqbanking-cli and aqhbci-tool4 show no accounts), and I fail to 
communicate with my bank using a new configuration.


Thanks for any help!

Cheers,
Jan Henrik
___
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: kdeedu-4.2.4 to 4.2.4_1 facile.cmxa compile error

[Jan Henrik Sylvester]

Troy wrote:

I was just upgrading from kdeedu-4.2.4 to 4.2.4_1 and the following error
occurred.  


[ 12%] Generating solver.o
File "_none_", line 1, characters 0-1:
Error: Files /usr/local/lib/ocaml/facile/facile.cmxa
   and /usr/local/lib/ocaml/stdlib.cmxa
   make inconsistent assumptions over implementation Printf


I rebuild both facile and ocaml and the error went away. I suspect it 
was ocaml.


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

Re: FreeBSD Port: octave-3.2.2_5

[Jan Henrik Sylvester]

Maho NAKATA wrote:

From: Joey Mingrone 



I'm having some trouble upgrading this port.

% uname -a
FreeBSD ... 7.2-RELEASE FreeBSD 7.2-RELEASE #1: Wed May  6 12:48:08 ...  i386

Here's the error in the build:
making gendoc.cc
g++44 -O2 -fno-strict-aliasing -pipe -I/usr/local/include
-I/usr/local/include -o gendoc gendoc.cc -L/usr/local/lib -pthread
making DOCSTRINGS
/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11
required by ./gendoc not found



Hi Joey, I also noticed that Gerald has updated GCC43 to GCC44.
you should recompile all ports...
thanks


I hit the same error on 7.2-RELEASE. I did recompile all Fortran 
dependencies with gcc44 and removed gcc43, still the error persists.


Having recompiled just gendoc.cc with gcc42 from base, I was able to 
finish the build, but running octave does not work, either:


/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 
required by /usr/local/lib/octave-3.2.2/liboctinterp.so not found


Since liboctinterp.so was compiled with gcc44 and not with gcc from 
base, I guess it should not try to load /usr/lib/libstdc++.so.6 but 
/usr/local/lib/gcc44/libstdc++.so.6 -- or am I wrong?


Any idea besides recompiling "all ports"? I really do not see the point 
in that, since nothing but the Fortran ports should use gcc44. Maybe, I 
do not understand the dynamic linking with multiple gcc versions 
involved after all.


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

Re: FreeBSD Port: octave-3.2.2_5

[Jan Henrik Sylvester]

Maho NAKATA wrote:

From: Jan Henrik Sylvester 

Maho NAKATA wrote:

From: Joey Mingrone 

I'm having some trouble upgrading this port.
% uname -a
FreeBSD ... 7.2-RELEASE FreeBSD 7.2-RELEASE #1: Wed May 6 12:48:08 ...
i386
Here's the error in the build:
making gendoc.cc
g++44 -O2 -fno-strict-aliasing -pipe -I/usr/local/include
-I/usr/local/include -o gendoc gendoc.cc -L/usr/local/lib -pthread
making DOCSTRINGS
/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11
required by ./gendoc not found

Hi Joey, I also noticed that Gerald has updated GCC43 to GCC44.
you should recompile all ports...
thanks

I hit the same error on 7.2-RELEASE. I did recompile all Fortran
dependencies with gcc44 and removed gcc43, still the error persists.

Having recompiled just gendoc.cc with gcc42 from base, I was able to
finish the build, but running octave does not work, either:

/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11
required by /usr/local/lib/octave-3.2.2/liboctinterp.so not found

Since liboctinterp.so was compiled with gcc44 and not with gcc from
base, I guess it should not try to load /usr/lib/libstdc++.so.6 but
/usr/local/lib/gcc44/libstdc++.so.6 -- or am I wrong?

Any idea besides recompiling "all ports"? I really do not see the
point in that, since nothing but the Fortran ports should use
gcc44. Maybe, I do not understand the dynamic linking with multiple
gcc versions involved after all.



I think there is no better way to do recomple whole ports :-O
I guess that's why gerald@ did before the ports freeze and we will
have a newer (better bug free, I believe) FORTRAN compiler.


After running 'ldconfig /usr/local/lib/gcc44/ /usr/local/lib/', I was 
able to run octave. Actually, I am really not sure what I am doing here. 
Do you really think recompiling all ports would cure my system or is 
octave simply looking at the wrong directories for libraries?


Thanks,
Jan Henrik
___
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"

RESTRICTED among 8.0-release packages (Sep-23 set)

[Jan Henrik Sylvester]

Comparing the INDEX of the 8.0-release package set from Sep-23 to my 
installed packages, I found some oddities.


Many RESTRICTED packages are included, for example: print/acroread8, 
net/skype, www/linux-flashplugin9, astro/google-earth, 
multimedia/win32-codecs, audio/lame, print/pdflib, audio/eawpats, 
audio/faac, multimedia/mencoder, and audio/libamrnb.


Moreover, some more packages are missing that were included at the 
beginning of the month: multimedia/libdvdcss, net/liveMedia 
(=>multimedia/vlc), audio/sdl_sound (=>emulators/dosbox), math/octave 
(=>math/koctave). Most of them just build for me. Only octave is marked 
BROKEN for which a fix was suggested: 
http://lists.freebsd.org/pipermail/freebsd-ports/2009-September/057067.html


Since java/diablo-jdk16 now builds with misc/compat7x, is there a reason 
packages with java dependencies are missing? (For me: devel/apache-ant, 
sysutils/jdiskreport, multimedia/projectx, and 
editors/openoffice.org-3.) Especially not having openoffice.org packages 
is a bit unfortunate, since it only build depends on java.


For some of the missing packages that build for me, I was looking for 
pointyhat logs to see what is broken, but could not find them. Are the 
error logs for the preliminary release sets somewhere?


Cheers,
Jan Henrik
___
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"

RESTRICTED packages on FTP not a problem?

[Jan Henrik Sylvester]

http://lists.freebsd.org/pipermail/freebsd-ports/2009-September/057182.html

I wonder why I got no reply to my posting and the new 8.0-RELEASE 
package set on FTP still contains RESTRICTED packages... not a problem 
or overlooked?


For example: 
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/audio/lame-3.98.2_2.tbz 
Or: 
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/print/acroread8-8.1.6.tbz


Cheers,
Jan Henrik
___
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: Issue with inkscape port

[Jan Henrik Sylvester]

Guy Brand wrote:

Am I the only one having severe issue with inkscape from the ports?
I'm using 0.46_6, without a config option and its 129 dependancies
(see attached output of pkg_info) on a FreeBSD 9.0-CURRENT r198491.
Adding a layer is simply impossible, inkscape freezes and there is
no other way to kill the process. truss doesn't say anything more:
when inkscape becomes unresponsive the process appears dead. Such a
problem turns the fantastic inkscape into an unusable application.

AFAIR I have this problem for over a year now! To reproduce it open
any document inside inkscape and add a new layer, you're done.


I could not reproduce the freeze opening a random svg document and 
adding a few layers. I am on 8.0-RC2 with all ports up to date.


Your ports seem not to be up to date. At least for 15 of the 
dependencies you listed, I have got newer versions installed. Moreover, 
22 of your dependencies are not listed as dependencies for me.


Opening http://www.freebsd.org/cgi/ports.cgi?query=inkscape&stype=all 
confirms that your dependencies do not match the ones of the current 
ports tree.


Cheers,
Jan Henrik
___
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: [patch] switch to Emacs 23

[Jan Henrik Sylvester]

Boris Samorodov wrote:

here is a patch to switch to Emacs 23 as a default. There are
50 affected ports. Tests were done at tinderbox. Please give
this patch a try. I'm going to fire up an exp run after some
testing. The patch is relative to PORTSDIR:


You already know that I have been running emacs23 (with auctex, cedet, 
elib, and jde) for a while with patches that are practically the same, 
but in case you are waiting for more success reports with your current 
patch, I rebuild my *emacs*-ports on two different 8.0-RELEASE machines 
(i386 and amd64), created packages, moved them on to another machine, 
and tried emacs (with auctex) there. Everything seems to be fine.


Thanks for all your effort!

Cheers,
Jan Henrik
___
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: ntfsprogs

[Jan Henrik Sylvester]

As you are working on ntfsprogs, are you able to use ntfsresize at all?

For me, ntfsresize never worked in ntfsprogs-2.0.0, but it did in 
ntfsprogs-1.13.1. We had a discussion about ntfsprogs on 
freebsd-questions almost a year ago:


http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/thread.html#196207

I still do not know more than I stated in there:

http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196252.html

I still would like to create an ports/ntfsprogs1 (back)port to get 
ntfsprogs-1.13.1 back. Unfortunately, I have not had time to do this 
since then.


Maybe you want to check yourself, if 1.13.1 gives less problems than 
2.0.0...


Although ntfsprogs is not maintained anymore, mkntfs and ntfsresize are 
still useful -- thus picking the best last release and fixing that on 
current FreeBSD may be worse it.


Cheers,
Jan Henrik
___
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"

Direct or indirect libdependencies (using the libintl.so.8 case)

[Jan Henrik Sylvester]

The general argument follows below, I just need some anecdotal evidence 
first:


Yesterday, I was chasing libintl.so.8, rebuilding all ports that got 
bumped, checking with libchk for other libintl.so.8 dependencies, and 
forcing a rebuild of all these packages: All but two of them had an 
indirect dependency on devel/gettext (and I did email the maintainers of 
devel/ccrtp and textproc/gsed linking without a dependency).


Then I did a complete scan for libintl.so.8 and found one file linking 
libintl.so.8 that was outside the path that libchk scans (
share/examples/telepathy-qt4/call/.libs/call from net-im/telepathy-qt4). 
Yes, 'portupgrade -fr' would have been better as suggested in UPDATING.


So far, no surprise.

Now, many ports got bumped adding a direct dependency that already have 
an indirect one. These got rebuild yesterday, either by checking with 
libchk or by following UPDATING and rebuilding all (indirect) 
dependencies, and now have to be rebuild, again. To me, the new bump 
seems to be a waste, since AFAIU indirect and direct dependencies are 
not listed in the package any different.


If bumping portrevisions would be done consequently -- for example by 
the build cluster recording libdependencies somehow that can be used as 
a basis for bumps -- it would help updating, but currently, bumping some 
portrevisions does not seem to help and only causes rebuilds being 
wasted as in this case.


Moreover, there does not seem to be an agreement, if direct 
libdependencies should be listed with indirect already existing. Several 
just got them added for gettext, but when I asked for one to be 
introduced on another occasion, it got removed shortly afterward again 
with pav@ explaining to me that they are not desirable: "We should not 
explicitly state any indirect dependencies of any kinds. For the sake of 
simplicity." This was the commit: 
http://lists.freebsd.org/pipermail/cvs-all/2009-May/288801.html -- I do 
not see a difference to the current case.


I think that libdependencies should be recorded for making portrevision 
bumps consistent -- either by trying to introduce direct 
libdenpendencies for every port that links a shared library or by 
recording real shared library dependencies externally (maybe by the 
build cluster).


Currently, sometimes all direct and indirect portrevisions are bumped, 
sometimes only the direct ones, and sometimes none at all -- in the 
second and third case with instructions in UPDATING to rebuild 
recursively. For one of my machines, I can use libchk to occasionally 
check if something is left behind, but for all of the machines I 
transfer packages to, I keep recording lists of packages that need a 
forced rebuild. I somehow feel that that should be an automated task 
(done by the ports framework itself).


Strictly following UPDATING seems to me not always to be save, either: 
If I waited a few weeks and I am told to do two recursive rebuilds (that 
are not forced), the second one could miss some portrevision bumps, 
because the first one already produced up-to-date ports. If the second 
one was due to a shared library bump, I would be in an inconsistent 
state. Sometimes, I really wonder about the order in which to follow 
instructions in UPDATING -- and I am pretty sure that there is not 
always an order that gives a save result: the example I just gave with 
several portrevision bumps due to shared library bumps not depending on 
each other but with common ports dependent on them cannot be solved, I 
guess. Then tools like libchk (or bsdadminscripts) are the only help, 
but since they cannot find all libdependencies (dlopen), they are not an 
universal solution, either (but seem to have a high rate of success).


My first argument is for portrevision bumps, my second one seems to be 
against them. Both approaches seem to have trade-offs, I wish one would 
be followed consistently. I know that the decisions are made on a 
case-by-case basis, but for my taste, it is too much case-by-case.


Cheers,
Jan Henrik
___
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: Direct or indirect libdependencies (using the libintl.so.8 case)

[Jan Henrik Sylvester]

On 01/-10/63 20:59, Alexander Leidinger wrote:

Quoting Peter Jeremy  (from Thu, 3 Jun 2010
22:37:28 +1000):


On 2010-Jun-01 10:54:02 +0200, Jan Henrik Sylvester  wrote:

Yesterday, I was chasing libintl.so.8, rebuilding all ports that got
bumped, checking with libchk for other libintl.so.8 dependencies, and
forcing a rebuild of all these packages: All but two of them had an
indirect dependency on devel/gettext (and I did email the maintainers of
devel/ccrtp and textproc/gsed linking without a dependency).


This might be unrealistic but, IMHO, these "indirect dependencies" should
not exist. IMHO, there should only be two situations:

1) Port X directly links against or dlopen's libY.so from port Y.

In this case, port Y should be listed in LIB_DEPENDS or equivalent
for port X and port X will need a portrevision bump and rebuild if
the port Y ABI changes (eg a .so version bump)

2) Port X directly links against or dlopen's libZ.so and libZ.so pulls
in libY.so from port Y.

In this case, port X should not be directly accessing any symbols in
libY.so. If the libY.so ABI changes, libZ.so will need to be rebuilt
but unless the libZ.so ABI changes, there should be no need to rebuild
port X.

Are there any other situations that have to be considered?


The problem is a little bit more complex if you have a look at the big
picture.

Indirect dependencies get hardcoded into binaries in several cases(*1),
except you use a compiler switch which tells the compile-time-linker to
not record library dependencies when no symbols of those libs are
reference directly(*2).

If you want to know which libs are linked into binaries of a port, I
suggest you have a look at my
/usr/ports/Tools/scripts/explicit_lib_depends.sh script (note that its
name starts with "explicit", not with "direct", this is on purpose as
those two descriptions have a different semantic which is important for
this discussion).

(*1) Either by libtool as it does not has some hint enabled on FreeBSD,
or by pkg-config listing them directly even if the corresponding library
does not reference symbols of such a dependency in its API.

(*2) This is used by some gnome ports (not all), and can not be enabled
globally, as some programs may depend upon this (e.g. when loading
plugins which are not linked correctly).


Thanks for your reply and blog posting. With direct and indirect, I was 
refering to package dependencies and not library dependencies.


I have checked one of the missing dependencies with 
explicit_lib_depends.sh, but it did not show up, because 
explicit_lib_depends.sh makes some assumptions upon were binaries reside 
that are not true in this case:


%objdump -x /usr/local/share/examples/telepathy-qt4/call/.libs/call | 
grep NEEDED | grep intl

  NEEDED  libintl.so.9
%pkg_info -W /usr/local/share/examples/telepathy-qt4/call/.libs/call
/usr/local/share/examples/telepathy-qt4/call/.libs/call was installed by 
package telepathy-qt4-0.3.2

%/usr/ports/Tools/scripts/explicit_lib_depends.sh telepathy-qt4-0.3.2
WARNING: your libtool records dependencies recursively, you can not
trust the following output.
QtCore:${PORTSDIR}/devel/qt4-corelib
QtDBus:${PORTSDIR}/devel/dbus-qt4
QtNetwork:${PORTSDIR}/net/qt4-network
QtXml:${PORTSDIR}/textproc/qt4-xml
USE_GNOME+= _glib20 (devel/glib20)
USE_GNOME+= libxml2 (textproc/libxml2)
gstinterfaces-0.10:${PORTSDIR}/multimedia/gstreamer-plugins
gstreamer-0.10:${PORTSDIR}/multimedia/gstreamer
telepathy-farsight:${PORTSDIR}/net-im/telepathy-farsight
telepathy-glib:${PORTSDIR}/net-im/telepathy-glib

Thus, explicit_lib_depends.sh cannot be relied upon what to rebuild, 
either -- it missed the same that libchk does. Anyhow, this does not 
matter at all to the main point I tried to raise:


Should _all_ explicit and direct dependencies (to use your vocabulary) 
be accounted for in the LIBDEPENDS of a port? The LIBDEPENDS are used to 
bump PORTREVISIONs to trigger rebuilds. Not having all explicit and 
direct dependencies listed there, reduces the use of PORTREVISION bumps 
so much that their negative side effect (at least when they are not done 
at the same moment as the original commit) becomes dominant (people 
relying on libchk, bsdadminscripts, or the like are forced to rebuild 
ports that are already consistent).


Peter seems to be of my opinion by what he said above, marcus@ did 
introduce USE_GETTEXT for many ports that already have indirect port 
dependencies, so I assume that he agrees, too. On the other hand, pav@ 
(who is among portmgr) seems to disagree (at least a year ago), as I 
stated in my first mail: 
http://lists.freebsd.org/pipermail/cvs-ports/2009-May/172173.html And he 
is not the only one with that opinion.


Yes, the architecture of ports is insufficient for a good solution of 
any kind, but as long as there is not even an agreement, what LIBDEPENDS 
are supposed to contain, following port updates is harder than it should 
be, bec

Removal of java/jde: There is a pr for an update

[Jan Henrik Sylvester]

Hi Doug!

You just removed java/jde, but you forgot to look at prs for a fix. 
There is one (author Cced) with an update to a version that does fetch: 
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/158204


Since the new version is called jdee, maybe java/jde is really obsolete, 
but not before it is repocopied to java/jdee and the pr applied.


I have not used jde(e) in a while and do not currently care too much, 
but I guess it is still useful.


Cheers,
Jan Henrik
___
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"

Xournal: Please, help me with my first port

[Jan Henrik Sylvester]

al/Makefile
sed 's/^X//' >graphics/xournal/Makefile << '7b6ea3301597bf7d5161b3f76878ae21'
X# New ports collection makefile for:   xournal
X# Date created:21 Jan 2011
X# Whom:Jan Henrik Sylvester 
X#
X# $FreeBSD$
X#
X
XPORTNAME=  xournal
XPORTVERSION=   0.4.5
XCATEGORIES=graphics
XMASTER_SITES=  SF
X
XMAINTAINER=m...@janh.de
XCOMMENT=   A notetaking application that can annotate PDFs
X
XLIB_DEPENDS=   poppler-glib.5:${PORTSDIR}/graphics/poppler-gtk
X
XMAKE_JOBS_SAFE=yes
XUSE_GNOME= desktopfileutils libgnomecanvas
XGNU_CONFIGURE= yes
XINSTALLS_ICONS=yes
X
XOPTIONS=   GHOSTSCRIPT "Install ghostscript (PS/PDF as bitmap bg)" on
X
X.include 
X
X.if !defined(WITHOUT_GHOSTSCRIPT)
XUSE_GHOSTSCRIPT_RUN=   yes
X.endif
X
Xpost-patch:
X   @${REINPLACE_CMD} -e 
's|$$(DESTDIR)/usr/share/|$$(DESTDIR)desktopdir/|g' -e 
's|/usr/local/share|"$$(datadir)"|' ${WRKSRC}/Makefile.in
X
Xpost-install:
X   @cd ${WRKSRC} && ${MAKE} desktop-install
X
X.include 
7b6ea3301597bf7d5161b3f76878ae21
exit

___
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: Xournal: Please, help me with my first port

[Jan Henrik Sylvester]

On 01/22/2011 14:04, Chris Rees wrote:

On 22 January 2011 12:53, Chris Rees  wrote:

On 21 January 2011 21:46, Jan Henrik Sylvester  wrote:

Finally, I found an application worse having that is not in ports and looked
simple enough to try: Xournal is my first attempt to create a new port.

I followed the handbook and did the basic testing with porttools: There are
warnings about considering to use DATADIR if the port was DATADIR-safe, but
I do not assume it to be.

Moreover, there is a warning about my post-patch line. I think the warning
is wrong, but I am unsure about that line anyhow. The desktop-install target
in Makefile.in is wrong for FreeBSD, but there is probably a better way to
fix it.

Is my attempt to use the desktop-install target via post-install correct?

Do all the files installed by the post-install target go to the correct
locations?

Is there anything else I should fix before submitting the port as pr?

In case the attachment does not make it to the list, I have placed a copy
here: http://www.math.uni-hamburg.de/home/sylvester/xournal.shar



The DATADIR whines are addressed in this patch, have a look:

http://www.bayofrum.net/~chris/patches/xournal-pkg-plist.diff


Thanks, but since the port does not honor DATADIR, it should not be 
there -- or the DATADIR case must be fixed first.



That's all I had time to look at at the moment, perhaps others can help!



Alright, came back and now the patch has the desktop-install target
defined instead of using the post-install. This is reflected in the
patch linked above ^^^


Thanks, I was looking for something like that, but it should be 
"INSTALL_TARGET= install desktop-install", because desktop-install does 
not include install.



I've stuck it in my Tinderbox for testing, follow it here:
http://tinderbox.bayofrum.net/index.php?action=describe_port&id=196


Thanks!

I do not know Tinderbox enough to understand, why your mkfontscale build 
tried to install an outdated version of freetype2.


Cheers,
Jan Henrik
___
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: Xournal: Please, help me with my first port

[Jan Henrik Sylvester]

On 01/23/2011 11:42, Chris Rees wrote:

Take a look at the new patch so far; I'm still working on Busybox at
the moment, so I'm afraid I can't step too much more through it, but


Just a question about what you did so far: Why the 
"CONFIGURE_ARGS+=--prefix=${PREFIX}"? I have tested with a different 
PREFIX before and it was successful -- that is what the second part of 
the REINPLACE accomplished. What does your line improve?


Or is it a first step, if I wanted to make the port DATADIR-safe?


it should give you a little more to work on. I've tidied the REINPLACE
lines for you too.


Thanks, that is better to read.


http://www.bayofrum.net/~chris/patches/xournal.diff

DATADIR-safe appears unnecessary according to the conversation
http://www.mailinglistarchive.com/freebsd-ports@freebsd.org/msg08234.html
, so I think that this port should be fine as is right now. Try
submitting it, it should be fine.


That is what I thought and since I would have to patch the source (at 
least main.c) and the Mafile(s), I did not consider it to be worse it, 
since I do not believe anyone will ever use a different DATADIR for this 
port.


That leads to my second question: Is your proposal to replace the 
"share/xournal" in pkg-plist by "%%DATADIR%%" correct although the port 
is not DATADIR-safe? Currently, if DATADIR is set the port ends up to be 
installed with wrong +CONTENTS, since the installation ignores DATADIR 
being set, but +CONTENTS uses it.


I believe that it is correct what portlint says: "If and only if your 
port is DATADIR-safe (that is, a user can override DATADIR when building 
this port and the port will still work correctly) consider using DATADIR 
macro; if you are unsure if this port is DATADIR-safe, then ignore this 
warning". Thus, there should not be DATADIR in my pkg-plist as long as 
the port is not DATADIR-safe.


Cheers,
Jan Henrik
___
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: Xournal: Please, help me with my first port

[Jan Henrik Sylvester]

On 01/23/2011 17:35, Chris Rees wrote:

On 23 January 2011 16:24, Jan Henrik Sylvester  wrote:

On 01/23/2011 11:42, Chris Rees wrote:


Take a look at the new patch so far; I'm still working on Busybox at
the moment, so I'm afraid I can't step too much more through it, but


Just a question about what you did so far: Why the
"CONFIGURE_ARGS+=--prefix=${PREFIX}"? I have tested with a different PREFIX
before and it was successful -- that is what the second part of the
REINPLACE accomplished. What does your line improve?

Or is it a first step, if I wanted to make the port DATADIR-safe?


Should I include that line?

(I have just retested: The port installs to the correct PREFIX without 
that line and seems to be working fine.)



I believe that it is correct what portlint says: "If and only if your port
is DATADIR-safe (that is, a user can override DATADIR when building this
port and the port will still work correctly) consider using DATADIR macro;
if you are unsure if this port is DATADIR-safe, then ignore this warning".
Thus, there should not be DATADIR in my pkg-plist as long as the port is not
DATADIR-safe.



Perhaps you should ignore the portlint warnings and leave it as
share/xournal then.


Thanks.

BTW: I am going to ignore your capitalization of "makefile" in the first 
line, too, since it is non-capitalized in the porters handbook and 20210 
over 240 ports go for the non-capitalized variant.


Cheers,
Jan Henrik
___
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: Xournal: Please, help me with my first port

[Jan Henrik Sylvester]

Thanks for all your suggestions!

Cheers,
Jan Henrik
___
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"

Cannot open MS Word file with libreoffice-3.3.0_3

[Jan Henrik Sylvester]

I just did a portupgrade to libreoffice-3.3.0_3 (amd64) -- with a 
package created on another machine that I did the portupgrade on before 
and that also had libreoffice-3.3.0_1 installed during make.


In contrast to portrevisions 0 and 1, I cannot open MS Word files 
anymore. I get a window with this message:


General Error.
General input/output error.

In the terminal, I get the message "javaPathHelper: not found", but I do 
get the same opening OpenDocument files, which happen to work fine, and 
I got the same message with the earlier portrevisions that worked.


I know that there are mainly pkg-plist changes since the initial 
portrevision, but the behavior is still different. I also build the the 
earlier portrevisions on the other machine and transferred via package. 
As far as I remember, for portrevision 1 there was also the previous 
version installed during make.


Cheers,
Jan Henrik
___
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"

Onesided conflict: editors/openoffice.org-3 with devel/cppunit (=> editors/libreoffice)

[Jan Henrik Sylvester]

I just tried to reinstall editors/openoffice.org-3 after recently 
installing editors/libreoffice that pulled in devel/cppunit -- I could 
not, since editors/openoffice.org-3 conflicts with devel/cppunit.


Why is there a one-sided conflict? If editors/openoffice.org-3 and 
devel/cppunit really install files to the same location, both should 
conflict each other.


Which files are installed by both ports? Looking in 
/var/db/pkg/cppunit-1.12.1/+CONTENTS and 
/var/db/pkg/openoffice.org-3.3.0/+CONTENTS on a machine that I still 
have both installed on, I cannot find any common files. Both ports are 
installed with default options. I only find the commit message from 
2010-Apr-1 of OOo adding the conflict, but it does not say which files 
and since pkg-plist is generated, I cannot find out if the conflict was 
resolved in the meantime.


It would make testing of editors/libreoffice difficult if you could not 
have it installed with editors/openoffice.org-3 at the same time.


Cheers,
Jan Henrik
___
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"

sysutils/cdrtools in i386 chroot on amd64

[Jan Henrik Sylvester]

I am trying to build all ports that I have installed in an i386 chroot 
environment on an amd64 machine. All work except for sysutils/cdrtools.


I have installed an i386 system to some directory, mounted a devfs to 
the devfs subdirectory, set "MACHINE=i386 ; UNAME_p=i386 ; UNAME_m=i386" 
and exported them, chrooted to the directory, and called 
"/etc/rc.d/ldconfig start".


sysutils/cdrtools fails with many errors as it still builds for amd64.

Is this expected? Should I do more to get an i386 environment? (I have 
tried to set ARCH and MACHINE_ARCH with no change.)


sysutils/cdrtools/Makefile mentions: "Hack to allow building with TARGET 
and TARGET_ARCH set in the environment as done by the release building 
scripts." This seems to be the problem as all the variables I set cannot 
have an effect. How can I work around that hack except for changing the 
Makefile?


Could the port detect if it is called from the release building scripts 
and only apply the hack in that case?


Cheers,
Jan Henrik
___
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: sysutils/cdrtools in i386 chroot on amd64

[Jan Henrik Sylvester]

On 02/11/2011 18:27, Marius Strobl wrote:

On Fri, Feb 11, 2011 at 02:34:02PM +0100, Jan Henrik Sylvester wrote:

I am trying to build all ports that I have installed in an i386 chroot
environment on an amd64 machine. All work except for sysutils/cdrtools.

I have installed an i386 system to some directory, mounted a devfs to
the devfs subdirectory, set "MACHINE=i386 ; UNAME_p=i386 ; UNAME_m=i386"
and exported them, chrooted to the directory, and called
"/etc/rc.d/ldconfig start".

sysutils/cdrtools fails with many errors as it still builds for amd64.

Is this expected? Should I do more to get an i386 environment? (I have
tried to set ARCH and MACHINE_ARCH with no change.)



Yes, that approach isn't expected to generally work for cross-building
ports for i386 on amd64. What is expected to work is compiling them in
an i386 environment on amd64 running a kernel with r210369/rev. 1.103
of sys/kern/kern_mib.c (r210855/rev. 1.98.2.5 for 8-STABLE) in place
so the i386 binaries act as if they are running on native i386 without
hacks like MACHINE, UNAME_* etc being set. The cdrtools port is known
to be buildable for i386 in an i386 jail on amd64 that way.


Thanks for the explanation!

I did not know about that change and was still using "MACHINE=i386 ; 
UNAME_p=i386 ; UNAME_m=i386" on my 8.2-RC3 laptop, on which I just 
verified it not to be necessary anymore (and sysutils/cdrtools to build).


Since I got about 1200 ports building the old way on 8.1-RELEASE, I 
thought the unconditional hack in sysutils/cdrtools hindering me could 
be wrong, but with the situation really fixed in 8.2, it will not affect 
me anymore as I am going to upgrade my 8.1 package building machine 
pretty soon.


Cheers,
Jan Henrik
___
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: fixing the vulnerability in linux-f10-pango-1.22.3_1

[Jan Henrik Sylvester]

On 01/-10/-28163 20:59, Matthias Andree wrote:

Am 13.02.2011 22:53, schrieb Tom Uffner:

is there any point in trying to update linux-f10-pango to address this
vulnerability?

Affected package: linux-f10-pango-1.22.3_1
Type of problem: pango -- integer overflow.
Reference:


I realize that I can install it w/ DISABLE_VULNERABILITIES. but I hate
having known exploits on my system&  not installing it breaks flashplugin
and acroread (among others).

I've never tried to create or modify a linux emulation port before; so I'm
wondering just how annoying&  tedious it's going to be?

it looks like there are no Fedora 10 RPMs of pango>  1.24 so it would
probably involve finding an F10 box and building one from source.


Fedora 10 hasn't been supported for over a year now (EOL Mid December
2009), chances are, however, that newer versions of the system can build
an RPM that would fit F10.

There are online build services (for instance by/for openSUSE, starts
with Fedora 12 however), if you find a release that is close enough in
other shared library versions, that might help.

Backporting just a security fix, if a reliable and reasonable patch
exists, might be an easier option because you can take F10's 1.22.3
*source* RPM, add the security patch, and rebuild (see below).


This is how far I have looked into it: RHEL/CentOS 5 has an even older 
version of pango. Of course, there is a patch for that vulnerability in 
the src-rpm of RHEL 5. If you use --ignore-whitespace for patch, the 
RHEL 5 patch applies to the pango version in Fedora 10. Except for 
whitespace changes, the code in question has not changed much between 
the RHEL 5 and the Fedora 10 version. Probably, the patch fixes the 
vulnerability for us, too.


The easiest way would probably be:

- Take the src-rpm of the pango version in RHEL 5.
- Extract the patch from it: pango-glyphstring.patch-1.14.9-5.el5_3
- Extract the src-rpm of pango-1.22.3 from Fedora 10.
- Apply the RHEL 5 patch with --ignore-whitespace.
- Diff for creating a patch that applies without --ignore-whitespace.
- Bump version number and repackge a src-rpm for Fedora 10 with the new 
patch.

- Build it on a clean Fedora 10 system.

There is one more problem to solve: 
http://lists.freebsd.org/pipermail/freebsd-emulation/2010-December/008264.html


That mail go unanswered (at least as far as the mailing list archive 
goes). Probably, the procedure above would have to be put into a shell 
script for a willing commiter to repeat. Every time this vulnerability 
comes up at ports@ or emulation@, some commitor ask for a (trusted) rpm 
to fix it. Thus, there might be one.


For me, the real question is: Considering the age of Fedora 10 and the 
time it has not been supported anymore, it is likely that there are more 
vulnerabilities in our Linux-f10 framework that are not documented in 
our vulnerability database. Does fixing the pango vulnerability really 
make the Linux emulation save? (Is it worse the it?)


Cheers,
Jan Henrik
___
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"

Maintainer timeout for port destroying itself (multimedia/dvdauthor)

[Jan Henrik Sylvester]

I have been poking the maintainer of multimedia/dvdauthor three times 
since the beginning of this year about multimedia/dvdauthor applying a 
patch to the port itself and thus destroying the port after the second use.


Instead of being applied to the port, a patch for the port itself seems 
to have been copied to the files directory of the port instead.


It was later that I found that someone else did report it independently: 
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154065


Please, could some committer enforce the maintainer timeout for that pr?

Thanks,
Jan Henrik
___
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"

pkg_add fusefs-kmod-0.3.9.p1_1.tbz fails on 6.2

[Jan Henrik Sylvester]

After a 'portupgrade -f fusefs-kmod' (to make sure the port is installed 
correctly), I have created a package that now fails.


# pkg_create -b fusefs-kmod-0.3.9.p1_1
# pkg_delete -f fusefs-kmod-0.3.9.p1_1
pkg_delete: package 'fusefs-kmod-0.3.9.p1_1' is required by these other 
packages

and may not be deinstalled (but I'll delete it anyway):
fusefs-ntfs-1.1004
# pkg_add fusefs-kmod-0.3.9.p1_1.tbz
tar: sbin/mount_fusefs: Cannot stat: No such file or directory
tar: Error opening archive: Empty input file: Inappropriate file type or 
format
pkg_add: extract_plist: can not invoke 73 byte tar pipeline: 
/usr/bin/tar cf - sbin/mount\_fusefs|/usr/bin/tar --unlink -xpf - -C /usr


System is 6.2-RELEASE-p7 with all ports up to date.

Anyone else sees this? What is wrong?

Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

fusefs-kmod package broken on 7.0 (was: pkg_add fusefs-kmod-0.3.9.p1_1.tbz fails on 6.2)

[Jan Henrik Sylvester]

Jan Henrik Sylvester wrote:
After a 'portupgrade -f fusefs-kmod' (to make sure the port is installed 
correctly), I have created a package that now fails.


# pkg_create -b fusefs-kmod-0.3.9.p1_1
# pkg_delete -f fusefs-kmod-0.3.9.p1_1
pkg_delete: package 'fusefs-kmod-0.3.9.p1_1' is required by these other 
packages

and may not be deinstalled (but I'll delete it anyway):
fusefs-ntfs-1.1004
# pkg_add fusefs-kmod-0.3.9.p1_1.tbz
tar: sbin/mount_fusefs: Cannot stat: No such file or directory
tar: Error opening archive: Empty input file: Inappropriate file type or 
format
pkg_add: extract_plist: can not invoke 73 byte tar pipeline: 
/usr/bin/tar cf - sbin/mount\_fusefs|/usr/bin/tar --unlink -xpf - -C /usr


System is 6.2-RELEASE-p7 with all ports up to date.


On 7.0-BETA1 with the package from 
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-7-current/sysutils/fusefs-kmod-0.3.9.p1_1.tbz 
pkg_add gives:


tar: sbin/mount_fusefs: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.

In contrast to 6.2, the package is registered, but as with 6.2 it 
creates this symlink overwriting (?) the file:


/usr/local/sbin/mount_fusefs -> /usr/local/sbin/mount_fusefs

Of course, pkg_delete does not remove it (without -f), since it expects:

/usr/sbin/mount_fusefs -> /usr/local/sbin/mount_fusefs

The same happens if I build the port and create a package myself.

The port seems to be broken and should be fixed today (before the 
RELEASE_7_0_0 tag), since the official package created is broken.


Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

misc/compat5x package installs with weird messages

[Jan Henrik Sylvester]

Installing the 7.0-RELEASE package of graphics/xnview, I got some weird 
messages that seem to come from the misc/compat5x dependency:


rm: /var/tmp/instmp.qdjoSl/lib/compat/libc.so.5: Operation not permitted
rm: /var/tmp/instmp.qdjoSl/lib/compat/libc_r.so.5: Operation not permitted
rm: /var/tmp/instmp.qdjoSl/lib/compat/libcrypt.so.2: Operation not permitted
rm: /var/tmp/instmp.qdjoSl/lib/compat/libpthread.so.1: Operation not 
permitted

rm: /var/tmp/instmp.qdjoSl/lib/compat/libthr.so.1: Operation not permitted
rm: /var/tmp/instmp.qdjoSl/lib/compat: Directory not empty
rm: /var/tmp/instmp.qdjoSl/lib: Directory not empty
rm: /var/tmp/instmp.qdjoSl: Directory not empty
pkg_add: couldn't remove temporary dir '/var/tmp/instmp.qdjoSl'

What has happened?

Regards,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: misc/compat5x package installs with weird messages

[Jan Henrik Sylvester]

Norikatsu Shigemura wrote:

On Fri, 14 Dec 2007 18:32:22 -0600
Stephen Montgomery-Smith <[EMAIL PROTECTED]> wrote:

My bets are on noschg flag.
Pav, you are exactly right.  I have experienced this many times myself. 
  After installing the compat5x package you need to do "chflags -R 
noschg /var/tmp/inst* && rm -rf /var/tmp/inst*" or something like that.
I think it is a bug in pkg_install, that it doesn't check for the schg 
flag being set in its temporary file area.  Or maybe it should set the 
flags in the first place.


I knew this issue.  So I fixed it with rev#1.16 on make clean.
But my work was not enough:-(.  How about following patch?


I did a portupgrade to the new version. It ended with:

===>  Cleaning for compat5x-i386-5.4.0.8_9
--->  Cleaning out obsolete shared libraries
[Updating the pkgdb  in /var/db/pkg ... - 787 packages 
found (-0 +1) . done]

Operation not permitted - /usr/local/lib/compat/pkg/libc.so.5
Operation not permitted - /usr/local/lib/compat/pkg/libc_r.so.5
Operation not permitted - /usr/local/lib/compat/pkg/libcrypt.so.2
Operation not permitted - /usr/local/lib/compat/pkg/libpthread.so.1
Operation not permitted - /usr/local/lib/compat/pkg/libthr.so.1

I do not know what was not permitted. portupgrade did backup the shared 
libs with their schg flag. Whatever should have happened then...


I guess since nothing has changed with the libs, I can safely removed 
everything from /usr/local/lib/compat/pkg/ that came from this update 
(pam_*.so.2, snmp_*.so.2, and the files mentioned in the error message). 
Is that correct?


BTW: Creating a compat5x-i386-5.4.0.8_9 package with pkg_create, 
removing it, and readding it all went without error messages.


Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

libnjb pkg-plist incorrect?

[Jan Henrik Sylvester]

%%PORTDOCS%%share/doc/libnjb-%%PORTVERSION%%/html/dir_d03f56ed3ef2c0e11ac283c787a57d7a.html

is in pkg-plist of libnjb, but I got this file: 
dir_517a6f2c7427bc36231829858e370602.html


Therefore package creation fails.

Does this weird filename have something to do with my configuration? Is 
pkg-plist incorrect?


Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

portupgrade: complete failure due to devel/apr-svn

[Jan Henrik Sylvester]

After refreshing all packages in /usr/ports/packages/All, I tried to 
upgrade all ports on a machine that had the last 'portupgrade -a' a few 
month (?) ago. I got:


# portupgrade --batch -PP -x openoffice.org -a
** Port marked as IGNORE: devel/apr-svn:
 at line 1115 (evaluated to true)
** Proceeding anyway since NO_IGNORE is defined
/usr/local/lib/ruby/site_ruby/1.8/pkgversion.rb:41:in `initialize': : 
Not in due form: '[_][,]'. (ArgumentError)

from /usr/local/sbin/portupgrade:638:in `new'
from /usr/local/sbin/portupgrade:638:in `main'
from /usr/local/sbin/portupgrade:613:in `each'
from /usr/local/sbin/portupgrade:613:in `main'
from /usr/local/sbin/portupgrade:588:in `catch'
from /usr/local/sbin/portupgrade:588:in `main'
from /usr/local/lib/ruby/1.8/optparse.rb:1303:in `call'
from /usr/local/lib/ruby/1.8/optparse.rb:1303:in `parse_in_order'
 ... 7 levels...
from /usr/local/lib/ruby/1.8/optparse.rb:785:in `initialize'
from /usr/local/sbin/portupgrade:229:in `new'
from /usr/local/sbin/portupgrade:229:in `main'
from /usr/local/sbin/portupgrade:2173

Examining the ports, I do not see where the IGNORE of devel/apr-svn 
comes from. Moreover, I have not found a clue about the cause of the 
second error message searching for it.


I did "upgrade" devel/apr-svn manually with 'pkg_delete -f 
apr-db42-1.2.8_2', 'pkg_add apr-gdbm-db42-1.2.8_3.tbz', and 'pkgdb -s 
/apr-db42-1.2.8_2/apr-gdbm-db42-1.2.8_3/'. That did not change the 
outcome. '-x devel/apr-svn' did not help portupgrade, either.


portupgrade was current (portupgrade-2.4.3_2,2) and ruby, too 
(ruby-1.8.6.111_1,1).


Any idea what is wrong or how to fix it?

Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ImageMagick-6.4.1-3_1 selftest fails

[Jan Henrik Sylvester]

ImageMagick fails to build for me. I guess it is because I do the build 
as root while a different user "owns the display". (I do use kdm for 
login and start the build after su in a Konsole.)


Although it sounds like interactive building, IMHO, building a port with 
default options should not fail at that scenario, because it might cause 
an overnight "portupgrade --batch -a" to skip quite a few ports 
unnecessarily.


Or is my practice inadvisable in general?

Jan Henrik


All 697 tests passed

cd PerlMagick && make CC='cc' test
/bin/sh ../magick.sh PERL_DL_NONLAZY=1 /usr/local/bin/perl5.8.8 
"-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 
'blib/arch')" t/*.t t/bzlib/*.t t/fpx/*.t t/jbig/*.t t/jpeg/*.t 
t/jp2/*.t t/png/*.t t/tiff/*.t t/x11/*.t t/zlib/*.t

t/blob..ok
[...]
t/write.ok
t/x11/read..Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

t/x11/read..ok
t/x11/write.1/2 Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

t/x11/write. Failed 1/2 subtests
t/zlib/read.ok
t/zlib/writeok

Test Summary Report
---
t/x11/write.t   (Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  1
Files=27, Tests=345, 15 wallclock secs ( 0.30 usr  0.07 sys +  9.91 cusr 
 1.17 csys = 11.45 CPU)

Result: FAIL
Failed 1/27 test programs. 1/345 subtests failed.
*** Error code 255

Stop in /usr/ports/graphics/ImageMagick/work/ImageMagick-6.4.1/PerlMagick.
*** Error code 1

Stop in /usr/ports/graphics/ImageMagick/work/ImageMagick-6.4.1.
*** Error code 1

Stop in /usr/ports/graphics/ImageMagick/work/ImageMagick-6.4.1.
*** Error code 1

Stop in /usr/ports/graphics/ImageMagick/work/ImageMagick-6.4.1.
*** Error code 1

Stop in /usr/ports/graphics/ImageMagick.

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

Re: ImageMagick-6.4.1-3_1 selftest fails

[Jan Henrik Sylvester]

Robert Huff wrote:

Jan Henrik Sylvester writes:


 ImageMagick fails to build for me. I guess it is because I do the
 build as root while a different user "owns the display". (I do
 use kdm for login and start the build after su in a Konsole.)


Built just fine for me, about an hour ago, on -CURRENT with no
KDE involved.  OPTIONS screen worked fine.


Thanks. As I said, I tried to build with root while root was not allowed 
to use the display. Granting root access with 'xhost +local:' or 'setenv 
XAUTHORITY /usr/home/USER/.Xauthority' fixes the problem. Having to do 
that was kind of unexpected for me...


Maybe I was just wrong trying this with 'su' as root instead of properly 
being logged in with 'su -'. Having a DISPLAY=:0 set but being 
disallowed from using it, may not be expected.


Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ImageMagick-6.4.1-3_1 selftest fails

[Jan Henrik Sylvester]

David Wolfskill wrote:

On Sat, May 24, 2008 at 04:38:02PM +0200, Jan Henrik Sylvester wrote:

...

ImageMagick fails to build for me. I guess it is because I do the
build as root while a different user "owns the display". (I do
use kdm for login and start the build after su in a Konsole.)

Built just fine for me, about an hour ago, on -CURRENT with no
KDE involved.  OPTIONS screen worked fine.
Thanks. As I said, I tried to build with root while root was not allowed 
to use the display. Granting root access with 'xhost +local:' or 'setenv 
XAUTHORITY /usr/home/USER/.Xauthority' fixes the problem. Having to do 
that was kind of unexpected for me...


Maybe I was just wrong trying this with 'su' as root instead of properly 
being logged in with 'su -'. Having a DISPLAY=:0 set but being 
disallowed from using it, may not be expected.


I don't use KDE, but I do use xdm(1), so if I understand correctly, I
have a similar $DISPLAY ownership situation as yours.

ImageMagick just built for me under 6.3-STABLE (also freshly built
today).  (Although I track RELENG_6, RELENG_7, and HEAD daily, I only
build ports under RELENG_6, as that's what I actually mostly use.)


Since only with the last commit to ImageMagick, IMAGEMAGICK_TESTS was 
turned back on by default, you may have saved OPTIONS with off being 
reused for the tests.


Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ImageMagick-6.4.1-3_1 selftest fails

[Jan Henrik Sylvester]

Kitche wrote:

David Wolfskill wrote:
My experience was that ImageMagick did build, but it also put up a
little window with a message on it.  So my feeling is that the OP is
correct, and that at least on some versions of FreeBSD (in my case 7.0)
that access to an X11 environment is required for the port to install.


ImageMagick port does not require X to build for the user that is building
it. Sounds like either your ports is corrupted or something deeper on your
system is causing this issue.


As you can see from my original log, X is used.

X is not required, since it is not used, if I build with 'su -' instead 
of 'su' (and thus have a clear environment without DISPLAY being set). 
If the build tries to use X and is denied, the test fails.


The port is not corrupted... just have a look at these two tests:

/usr/ports/graphics/ImageMagick/work/ImageMagick-6.4.1/PerlMagick/t/x11/read.t
/usr/ports/graphics/ImageMagick/work/ImageMagick-6.4.1/PerlMagick/t/x11/write.t

Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ImageMagick-6.4.1-3_1 selftest fails

[Jan Henrik Sylvester]

Matthew Donovan wrote:

On Sat, May 24, 2008 at 03:47:51PM -0400, Kitche wrote:

As you can see from my original log, X is used.

X is not required, since it is not used, if I build with 'su -' instead
of 'su' (and thus have a clear environment without DISPLAY being set).
If the build tries to use X and is denied, the test fails.

the whole Su and su - is not related to this it seems considering I can su
to my root account and it works.

I'll try compiling ImageMagick on X to see if an error occurs.


Passes all tests in X on 7.0 for me 


Not that this really adds anything to this discussion, but I did test again:

With DISPLAY=:0.0 being set but no access to the display (XAUTHORITY 
unset) being owned by a different user, the PerlMagick tests x11/read 
and x11/write do fail.


Without DISPLAY being set, these tests do run and report 'ok', although 
they do not do anything (window does not appear). (Of course, this is 
the case if I do 'su -' in my Konsole instead of 'su'.)


With DISPLAY and XAUTHORITY both being set properly, a window appears 
during the tests and they both report 'ok'.


(This is all for 6.4.1-3_1 with all OPTIONS to default on 7.0.)

If I did not make this clear earlier, in contrast to my very first post, 
I now consider this behavior ok, since it does not really make sense to 
have DISPLAY set to something that is not accessible. (Not that it 
really makes sense to have the build fail if access to the display is 
being denied, but have it succeed, if no X is present at all...)


Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Wine 1.0-rc3 failed build

[Jan Henrik Sylvester]

Naram wrote:
> I just updated my ports tree which included the update of Wine to
> 1.0-rc3.  I attempted to build it and it failed at this point:

This is: http://bugs.winehq.org/show_bug.cgi?id=13561

The build with openssl-0.9.8h can be fixed as I described there.

Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

libchk, lib/compat/pkg, indirect dependencies, revision bumps

[Jan Henrik Sylvester]

Trying to clean lib/compat/pkg from old portupgrade leftovers, I used 
libchk to check which are still needed.


I thought with regular portupgrades for all ports, none of them should 
be needed, since recompiles due to PORTREVISION bumps should have taken 
care of these.


Quite a few were needed. Only one was a direct dependency.

Should indirect dependencies that are linked be listed as LIB_DEPENDS?

What about dependencies that only get linked, if the library is present? 
Explicit ones? Ones that autoconf picked up?


For example, koffice did not get bumped with the recent poppler upgrade, 
since it only depends on poppler-qt and not poppler itself. Still, 
libpoppler.so.2 is needed by libkritapdfimport.so and the application 
cannot import pdf files if libpoppler.so.2 is missing. (I tested that.)


Below is a list of more.

Should the PORTREVISION always be bumped, if a library version changes? 
Does this only apply for "clean" builds in a tinderbox without autoconf 
picking up more dependencies than needed? (Mine are not clean.)


Or can libchk pick up false positives? (In case of koffice that I 
tested, it did not.)


I wonder if I should report my findings to the maintainers or if I 
simply misunderstood something about library and PORTREVISION bumps.


I often copy packages from this machine to other ones. Obviously, 
lib/compat/pkg dependencies are missing afterwards.


Regards,
Jan Henrik


jackit-0.103.0_1 /usr/local/bin/jackrec 2008-Mar-26
->libFLAC.so.7 (libFLAC.so.10 flac-1.2.1 2008-Apr-7)
  [requires it indirectly via libsndfile, does not require it directly 
anymore]

libsamplerate-0.1.3 /usr/local/bin/sndfile-resample 2008-Mar-25
->libFLAC.so.7 (libFLAC.so.10 flac-1.2.1 2008-Apr-7)
  [requires it indirectly via libsndfile]
dvdauthor-0.6.14_1 /usr/local/bin/spumux 2007-Oct-17
->libMagick.so.10 (/ /)
->libWand.so.10 (/ /)
  [uses it if it exists]
opal-2.2.11 /usr/local/lib/libopal_r.so.2.2.11 2008-Mar-6
->libSDL.so.11 (libSDL-1.2.so.11 sdl-1.2.13_1,2 2008-Mar-13)
  [does not require it]
ccrtp-1.6.0 /usr/local/lib/libccrtp1-1.6.so.0 2007-Dec-22
->libgcrypt.so.13 (libgcrypt.so.15 libgcrypt-1.4.1_1 2008-Feb-28)
  [does not require it]
libzrtpcpp-1.0.0 /usr/local/lib/libzrtpcpp.so.0 2007-Dec-22
->libgcrypt.so.13 (libgcrypt.so.15 libgcrypt-1.4.1_1 2008-Feb-28)
  [does not require it]
kdeutils-3.5.8 /usr/local/lib/kde3/ksim_snmp.so 2008-Oct-29
->libnetsnmp.so.10 (libnetsnmp.so.16 net-snmp-5.4.1_5 2008-Mar-27)
  [does require it (without version)]
kdegraphics-3.5.8_2 /usr/local/lib/kde3/kfile_pdf.so 2008-Jun-6
->libpoppler.so.2 (libpoppler.so.3 poppler-0.8.3_1 2008-Jun-30)
  [requires it indirectly via poppler-qt]
koffice-1.6.3_5,2 /usr/local/lib/kde3/libkritapdfimport.so 2008-Jun-28
->libpoppler.so.2 (libpoppler.so.3 poppler-0.8.3_1 2008-Jun-30)
  [requires it indirectly via poppler-qt]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [CFT] editors/emacs to 24.1

[Jan Henrik Sylvester]

On 07/23/2012 10:04, Ashish SHUKLA wrote:

Any feedback would be greatly appreciated.


As you already know, it works! Thanks!

Specifically, I added 24.1 to bsd.emacs.mk, made it the default, and 
removed all ports depending on emacs-23.4.


I installed print/auctex and java/jde (from the attic) depending on 
devel/cedet and devel/elib, created packages, installed them on a 
different machine, and ran Emacs. Everything ports related seems to work.


I do not know, if you (asking for any feedback) really want anecdotal 
feedback about functionality, but here it is anyhow:


Arabic, which is finally displayed from right-to-left, works in windowed 
mode, but for me, it does not work correctly with "-nw": While it is 
displayed correctly in a LANG=en_US.UTF-8 Konsole (KDE terminal), the 
order of the letters is changed just by moving the cursor through Arabic 
text. I do not think this is a problem with the port, but either with my 
setup or with emacs-24.1 in general.


auctex works including the Emacs server for forward and inverse search 
with a PDF viewer. Unfortunately as a regression to auctex on 
emacs-23.4, all buttons have labels and are really wide -- including the 
"Separator". Hence, important buttons only show up in wide Emacs 
windows. Anyhow, this is probably not a problem with the port, but a 
problem with auctex, which has not made a release for over two years.


For my use, I would be happy, if emacs-24.1 was the default in ports, soon.

Thanks again,
Jan Henrik
___
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] editors/emacs to 24.1

[Jan Henrik Sylvester]

On 07/23/2012 13:39, Ashish SHUKLA wrote:

On Mon, 23 Jul 2012 13:32:34 +0200, Jan Henrik Sylvester  said:

Arabic, which is finally displayed from right-to-left, works in
windowed mode, but for me, it does not work correctly with "-nw":
While it is displayed correctly in a LANG=en_US.UTF-8 Konsole (KDE
terminal), the order of the letters is changed just by moving the
cursor through Arabic text. I do not think this is a problem with the
port, but either with my setup or with emacs-24.1 in general.


Did you try other terminal, like mrxvt ? I think it's problem with terminal,
and not Emacs, but I might be wrong.


mrxvt and mrxvt-devel both do not display utf-8 at all. I tried 
rxvt-unicode: While only some of the Arabic characters where displayed 
correctly, the cursor was moving properly and it did not reorder the 
characters. Emacs and the Emacs port seem to be fine. Finding and 
setting up a terminal that works properly with Arabic seems to be the 
problem.


My curiosity ends here. I cannot even read Arabic myself. I just happen 
to know someone, who would like to use Arabic in Emacs with auctex, but 
that person does not ever use "-nw".



For my use, I would be happy, if emacs-24.1 was the default in ports, soon.


Sure, it will be. I'd some personal issues over past weeks which are not
rectified so less slacking, more hacking.


Sorry, if my statement sounded demanding. It was not meant to be at all. 
I just wanted to summarize that the issues I found are not with the 
port, I consider them extremely minor, and I will use emacs-24.1 from 
now on.


Thanks,
Jan Henrik
___
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] editors/emacs to 24.1

[Jan Henrik Sylvester]

On 07/23/2012 16:26, Ashish SHUKLA wrote:

On Mon, 23 Jul 2012 14:20:43 +0200, Jan Henrik Sylvester  said:

On 07/23/2012 13:39, Ashish SHUKLA wrote:

On Mon, 23 Jul 2012 13:32:34 +0200, Jan Henrik Sylvester  said:

Arabic, which is finally displayed from right-to-left, works in
windowed mode, but for me, it does not work correctly with "-nw":
While it is displayed correctly in a LANG=en_US.UTF-8 Konsole (KDE
terminal), the order of the letters is changed just by moving the
cursor through Arabic text. I do not think this is a problem with the
port, but either with my setup or with emacs-24.1 in general.


Did you try other terminal, like mrxvt ? I think it's problem with terminal,
and not Emacs, but I might be wrong.



mrxvt and mrxvt-devel both do not display utf-8 at all. I tried
rxvt-unicode: While only some of the Arabic characters where displayed
correctly, the cursor was moving properly and it did not reorder the
characters. Emacs and the Emacs port seem to be fine. Finding and
setting up a terminal that works properly with Arabic seems to be the
problem.


Sorry, I was talking about mlterm[1].


Just for the record: x11/mlterm WITH_FRIBIDI does correct editing of 
Arabic in a shell and in "emacs -nw". Otherwise, "emacs -nw" does not 
work very well in mlterm: Backspace does not work, while it works 
outside Emacs, and combinations using the  key do not work, but 
they work properly in both konsole and rxvt-unicode.


Anyhow, the shortcomings of different terminal emulators are really OT 
and the only conclusion should be that there really seems to be no 
problem with either Emacs or the Emacs port.


Thanks,
Jan Henrik
___
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"

sysutils/testdisk: WITH_NTFS3G in ports.conf nonfunctional

[Jan Henrik Sylvester]

Since you converted sysutils/testdisk to the new options framework, it
does not depend on sysutils/fusefs-ntfs anymore, although I have this
line in /usr/local/etc/ports.conf:

sysutils/testdisk: WITH_NTFS3G

I thought the new options framework was backwards compatible and
ports-mgmt/portconf does not seem to be deprecated. I think some other
settings I have in ports.conf are still honored, although the respective
ports have been converted to the new options framework.

Is there anything wrong with sysutils/testdisk or my use of ports.conf?

Thanks,
Jan Henrik
___
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"

ports-mgmt/portconf with new options framework

[Jan Henrik Sylvester]

On 10/27/2012 21:32, Baptiste Daroussin wrote:
> On Sat, Oct 27, 2012 at 09:26:17PM +0200, Jan Henrik Sylvester wrote:
>> Since you converted sysutils/testdisk to the new options framework, it
>> does not depend on sysutils/fusefs-ntfs anymore, although I have this
>> line in /usr/local/etc/ports.conf:
>>
>> sysutils/testdisk: WITH_NTFS3G
>>
>> I thought the new options framework was backwards compatible and
>> ports-mgmt/portconf does not seem to be deprecated. I think some other
>> settings I have in ports.conf are still honored, although the respective
>> ports have been converted to the new options framework.
>>
>> Is there anything wrong with sysutils/testdisk or my use of ports.conf?
>>
>> Thanks,
>> Jan Henrik
> 
> The use of ports.conf has completely change with pkgng, btw it has more more
> interest anymore and could be replaced by make.conf directly like this
> OPTIONS_SET=  NTFS3G
> 
> or just to testdisk:
> testdisk_SET= NTFS3G
> 
> regards,
> Bapt

I know that I can use other means than ports.conf now, but if I am not
mistaken, ports-mgmt/portconf has not been deprecated, there is nothing
in UPDATING about the use of ports.conf having completely changed, and I
do not see anything in the documentation of ports-mgmt/portconf, either.

Could you please point me to the documentation of the complete change of
behavior of ports-mgmt/portconf you are mentioning?

For certain ports I see notes in UPDATING that due to the new options
framework the old WITH_* options do not work anymore, but there is
nothing on sysutils/testdisk.

Or is it wrong that the new options framework is backwards compatible
unless mentioned in UPDATING for certain ports?

I got the impression that I could not use the new syntax you mention
above for ports that have not been converted, yet. Since I like my
consistent set of options I have collected in ports.conf and kept
synchronized on all my machines, I have not tried to convert it, yet.
Neither in the porters handbook nor in the wiki, I find what kind of
backward and forward(?) compatibility I can expect and what has been
broken (or changed). Am I missing something?

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

Re: FreeBSD Port: bison-3.7.5,1 core dumped

[Jan Henrik Sylvester]

On 2/7/21 2:52 AM, Alex V. Petrov wrote:

I have problem with bison.
During build some ports.


during doxygen build:
/usr/bin/make  -f src/CMakeFiles/doxymain.dir/build.make
src/CMakeFiles/doxymain.dir/depend
[ 31%] [BISON][constexp] Building parser with bison 3.7.5
cd /usr/ports/devel/doxygen/work/doxygen-1.9.0/src &&
/usr/local/bin/bison  -d -o
/usr/ports/devel/doxygen/work/.build/generated_src/ce_parse.cpp
/usr/ports/devel/doxygen/work/doxygen-1.9.0/src/constexp.y
/usr/ports/devel/doxygen/work/doxygen-1.9.0/src/constexp.y:38.1-25:
warning: deprecated directive: '%name-prefix "constexpYY"', use '%define
api.prefix {constexpYY}' [


I have seen this for many ports on 13.0-BETA2/amd64, too.

To be able to build other ports, I worked around this by downgrading 
devel/bison to 3.6.4,1 (as 3.7.5,1 and 3.7.4,1 both produced coredumps).


Best,
Jan Henrik
___
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"

djbfft, daemontools, ezmlm RESTRICTED -> public domain

[Jan Henrik Sylvester]

D. J. Berstein has put his work into public domain: 
http://cr.yp.to/distributors.html


qmail, djbdns, and ucspi-tcp already have their RESTRICTED removed.

djbfft, daemontools, and ezmlm are still RESTRICTED:

multimedia/djbfft RESTRICTED= Forbidden to redistribute - we have 
patches to the distribution.

sysutils/daemontools RESTRICTED= Unsure of the license of djb software
mail/ezmlm RESTRICTED= Unsure of DJB license

The md5 in the distinfo of all three ports match with the announcement.

Only daemontools has an additional man distfile that is not mentioned in 
the announcement. (Neither is daemontools53.)


Cheers,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

redland build failure

[Jan Henrik Sylvester]

Trying to build kde4, I got stuck at redland:

mkdir .libs
cc -DLIBRDF_INTERNAL=1 -O2 -fno-strict-aliasing -pipe 
-DLIBRDF_INTERNAL=1 -O2 -fno-strict-aliasing -pipe -rpath=/usr/local/lib 
-o .libs/redland-db-upgrade db_upgrade.o -rpath=/usr/local/lib 
-L/usr/local/lib ../librdf/.libs/librdf.so -L/usr/local/lib/mysql 
/usr/ports/textproc/redland/work/redland-1.0.7/rasqal/src/.libs/librasqal.so 
/usr/local/lib/libraptor.so /usr/local/lib/libcurl.so -lssl 
/usr/local/lib/libxslt.so /usr/local/lib/libxml2.so 
/usr/local/lib/libiconv.so /usr/local/lib/libmpfr.so 
/usr/local/lib/libgmp.so -ldb-4.2 -lcrypto 
/usr/local/lib/mysql/libmysqlclient.so -lz -lcrypt -lm 
/usr/local/lib/libsqlite3.so -pthread -lpq  -Wl,--rpath 
-Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib/mysql

../librdf/.libs/librdf.so: undefined reference to `db_create'
../librdf/.libs/librdf.so: undefined reference to `db_strerror'
gmake[1]: *** [redland-db-upgrade] Error 1
gmake[1]: Leaving directory 
`/usr/ports/textproc/redland/work/redland-1.0.7/utils'

gmake: *** [all-recursive] Error 1
*** Error code 2

I am on 7.0 with all ports up to date. I have no nonstandard OPTIONS for 
any dependencies.


It seems to have picked up mysql-client although I did not have 
WITH_MYSQL on.


Do I miss anything?

Cheers,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ntfsprogs vs. fusefs-ntfs (ntfs-3g) reliability?

[Jan Henrik Sylvester]

Is there a particular reason our ntfsprogs port did not get updated for 
a year but now it has?


So far I did use ntfs-3g for mounting and ntfsprogs for resizing etc. 
with very few problems. Once on copying many files, two of them were 
only partially written with error messages "Bad address" and "No such 
file or directory". On the second attempt, I was able to copy them. 
(Moreover, using qemu volumes residing on ntfs-3g does not work, but I 
guess that is more of a fuse issue than an ntfs-3g one.)


Today, our ntfsprogs port got updated to 2.0.0. On ntfs-3g.org, it is 
stated that "[they] warn against the usage of ntfsprogs-2.0.0 because of 
major reliability issues (write failure, sparse file corruption, utility 
hang, etc). Use an earlier version instead until they get fixed."


Some google search shows that former ntfsprogs developer(s) are now 
working on ntfs-3g and the authors of both projects have some 
discrepancies: http://forum.linux-ntfs.org/viewtopic.php?t=741 
http://www.nabble.com/Re:-ntfsprogs-2.0.0-released-p12958587.html


All I can tell is that ntfsprogs really has not been updated for a year 
and ntfs-3g seems to be actively developed.


Either the ntfs-3g developer is correct and using ntfsprogs 2.0.0 is 
dangerous, or he is incorrect, which would make using ntfs-3g a little 
dubious.


Do you have any information from a third party? Do you think that both 
FreeBSD ports ntfs-3g and ntfsprogs 2.0.0 are reliable?


Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kdesdk3

[Jan Henrik Sylvester]

Mitja wrote:
> kdesdk3 doesn't want to update:
>
> pofiles.cc:450:5: warning: "YY_STACK_USED" is not defined
> pofiles.cc:1518:5: warning: "YY_MAIN" is not defined
> In file included from pofiles.cc:249:
> /usr/local/include/FlexLexer.h:130: error: expected unqualified-id
> before numeric constant
> pofiles.cc: In member function 'virtual int
> GettextBaseFlexLexer::yylex()':
> pofiles.cc:575: error: 'yy_current_buffer' was not declared in this
> scope

It was reported twice on kde-freebsd in August: 
http://mail.kde.org/pipermail/kde-freebsd/2008-August/thread.html


It is ports/115912 -- which is closed

kdesdk3 does not build with textproc/flex installed.

(textproc/flex is a build dependency of gstreamer since Jul-26.)

Lilipond recently had the same problem. Maybe the same fix applies.

Cheers,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

audio/akode PORTREVISION went backwards

[Jan Henrik Sylvester]

At 2008/08/18, audio/akode went from 2.0.2_1,1 to 2.0.2,1 and it is 
still there. (2.0.2_1,1 had existed since 2008/05/27.)


No change with default OPTIONS, though.

Cheers,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Found CONFLICTS: teTeX-base/texinfo emacs/texinfo open-motif/tcl84 coreutils/firebird2-server

[Jan Henrik Sylvester]

Playing a little with /var/db/pkg/*/+CONTENTS, I found some CONFLICTS, 
for example:


pkg_info: both coreutils-6.9_3 and firebird-server-2.0.3_2 claim to have 
installed /usr/local/bin/gstat
pkg_info: both teTeX-base-3.0_14 and texinfo-4.11 claim to have 
installed /usr/local/bin/texi2dvi
pkg_info: both teTeX-base-3.0_14 and texinfo-4.11 claim to have 
installed /usr/local/bin/texi2pdf
pkg_info: both emacs-22.2_1 and texinfo-4.11 claim to have installed 
/usr/local/info/info.info
pkg_info: both open-motif-2.2.3_5 and tcl-8.4.19,1 claim to have 
installed /usr/local/man/man3/Object.3.gz


CONFLICTS could be introduced for:
sysutils/coreutils and databases/firebird2-server
print/teTeX-base and print/texinfo
editors/emacs and print/texinfo
x11-toolkits/open-motif and lang/tcl84

Anyhow, this would break a few things -- at least:
math/maxima depends on x11-toolkits/open-motif and lang/tcl84
print/lilypond builddepends on print/teTeX-base and print/texinfo

I think I have found more in my installed packages, especially with 
links. Before I investigate them, I wonder if it is worse it:


Should all CONFLICTS be documented?

Should I report my findings to the maintainers (directly)?

Cheers,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: devel/kdesdk3 (kdesdk-3.5.10) not compiling

[Jan Henrik Sylvester]

Guill. Moreno-Socias wrote:
>I am trying to install x11/kde3 using portupgrade, but it fails
> when making devel/kdesdk3 (kdesdk-3.5.10).
[...]
> In file included from pofiles.cc:249:
> /usr/local/include/FlexLexer.h:130: error: expected unqualified-id
> before numeric constant
> pofiles.cc:450:5: warning: "YY_STACK_USED" is not defined

kdesdk3 cannot be build with textproc/flex installed (since it picks up 
part of it instead of the flex from base). You might have gotten 
textproc/flex as a build dependency to gstreamer, which is required by 
kde4 and many gnome applications.


There are discussions on the kde-freebsd mailing list about it and at 
least one bug report that got closed, because flex should be installed 
to a different directory, which did not happen. (This is the situation 
for five month already...)


pkg_create -b flex-2.5.35
pkg_delete flex-2.5.35
portupgrade devel/kdesdk3
pkg_add flex-2.5.35.tbz

Cheers,
Jan Henrik
___
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: devel/kdesdk3 (kdesdk-3.5.10) not compiling

[Jan Henrik Sylvester]

Max Brazhnikov wrote:

On Sat, 03 Jan 2009 17:28:35 +0100, Jan Henrik Sylvester wrote:

Guill. Moreno-Socias wrote:
 >I am trying to install x11/kde3 using portupgrade, but it fails
 > when making devel/kdesdk3 (kdesdk-3.5.10).



kdesdk3 cannot be build with textproc/flex installed (since it picks up



Fix for ports flex will be committed as soon as ports slush over.


And you meant it... just a few hours after the end of the slush. Thanks!

Jan Henrik
___
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"

OpenLDAP induced PORTREVISION bumps

[Jan Henrik Sylvester]

I just face many large ports requiring updates, although mine depend on 
openldap23-client, which have not been updated. Thus, I decided to 
investigate changing openldap23-client to openldap24-client.


According to 'libchk -v', only 10 of 29 of my ports bumped actually link 
to one of the openldap libraries. (For example kdesdk3 does not link to 
it.) Do I miss something? Why have all these ports been bumped?


devel/gconf2 did not get bumped, although it automatically picks up the 
dependency if openldap*-client is installed, which probably affects many 
people. Why? Because it does not affect the default package?


If I update openldap23-client to openldap24-client, is it advisable to 
rebuild all packages depending on it (81) or just the 29 that got bumped 
plus gconf2? (According to UPDATING, it probably should be all. 
According to 'libchk -v', 10+1 should be enough.)


Thanks,
Jan Henrik
___
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"

libtasn1 shlib bump fallout

[Jan Henrik Sylvester]

I know that some people do not agree with the PORTREVISION bumping at 
all. Anyhow, after the libtasn1 shlib bump there were some ports bumped, 
but many got missed that have files linking against libtasn1.so.3 
according to 'libchk -v'.


I found these:
cups-pstoraster-8.15.4_2
ekiga-2.0.11_5
ghostscript8-8.63
gnome-control-center-2.24.0.1
gnome-panel-2.24.3
gtk-2.14.7
gvfs-1.0.3
kdelibs-3.5.10
libpurple-2.5.4
pidgin-2.5.4
wireshark-1.0.5

I build these ports with standard options, but not in a tinderbox. Thus, 
I am not really sure if default packages from a tinderbox are affected.


At least some of the ports mentioned above do not have a dependency 
listed, but depend indirectly on libtasn1 installed.


Anyhow, bumping recursively seems to be a little too much, since most 
indirect dependencies do not link directly -- on my system, according to 
'libchk -v' there are many big packages (kde, openoffice.org, 
thunderbird, firefox, ...) unaffected. Thus, there should probably be 
only a note about it in UPDATING.


I am still not sure, if relying on the 'libchk -v' output is any good 
for removing stuff from lib/compat/pkg, but I do not know a better way 
to ensure packages build not depending on old libs.


Cheers,
Jan Henrik
___
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: Ports required to rebuild after upgrading Xorg to 7.4

[Jan Henrik Sylvester]

Christoph Moench-Tegeder wrote:

Did you run portupgrade -rf libxcb?


On a related note: I ran above command _before_ doing a full
"portupgrade -a". A whole bunch of ports failed to upgrade because


A mixture of -rf and a -a upgrade is always problematic, unless you were 
up-to-date before the library in question got updated.


If you do -rf before -a, some of the dependencies might be updated too 
early, expecting other ports to have been updated before that are only 
due in the -a phase. For example, port X depending on libxcb might also 
depend on libYYY, which does not depend on libxcb but got upgraded in 
the meantime. Thus, the new X depends on the new libxcb, but on the old 
libYYY. It will not be upgraded again and you will probably run into 
trouble at some time later.


If you do -a before -rf, it might be possible that some dependency might 
not be working during the -a, since it will only be repaired during the 
-rf, but something depending on this working is already upgraded during 
the -a stage. This is far less likely to cause problems, especially 
since portupgrade puts old libraries in /usr/local/lib/compat/pkg/ and 
thus, usually nothing is really broken. Moreover, linking against a 
currently broken library of the same version is not a problem, since the 
fixed one will later have the same version and (probably) same symbols.


It should be possible to do "portupgrade -a -rf libxcb -rf libgcrypt", 
but this will result in all packages being rebuild as far as I 
understand the portupgrade manpage.


I do not know how portmaster solves this, since without saving the old 
shared libraries, any build dependency that is broken in step one can 
cause trouble in step two.


BTW: Doing -rf is usually a lot more compile(!) time consuming than 
necessary, since indirect dependencies of a port usually (but only 
usually) do not link against the library in question. If you (think you) 
know what you are doing, you can try to find the ports that actually 
link against an old library using 'libchk -v' (or pkg_libchk as 
mentioned above). For example, 121 of my packages are directly or 
indirectly  dependent on libxcb, but only 31 seem to actually link 
against it.


Cheers,
Jan Henrik
___
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"

xorg 7.2 upgrade (using packages) -- some problems

[Jan Henrik Sylvester]

Hello!

Why does mergebase.sh not compare files that cause conflicts and 
deletes, if they are the same? "./lib/X11/fonts/local/fonts.dir" was the 
same for me in local and X11R6.


And then portupgrade with "-P" installed some conflicting ports, because 
it uses "-f" for package installs:


Following UPDATING, I changed portupgrade to portupgrade-devel, but 
portupgrade reinstalled the non-devel version, probably as a dependency 
to desktopbsd-tools that got upgraded.


gutenprint-base / gimp-gutenprint got installed over gimp-print as a 
dependency to gimp.


Luckily, there was no ghostscript-gpl-8.56_4 package, otherwise it 
probably would have overwritten ghostscript-gnu. "make install" was wise 
enough not to do so. This way, there were only many complains about 
ghostscript-gpl missing.


I had both hplip and hpijs installed, because only hplip lists hpijs as 
conflict but not vice-versa. Of course, portupgrade upgraded both.


Not really an issue: portupgrade would not install portaudit over the 
same version but in a different category. Thus, I still have it in 
security and not ports-mgmt. I only got some error messages.


Regards,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Portupgrade lynx2.-8-6 compile failure

[Jan Henrik Sylvester]

David Southwell wrote:
>Compile failure

>./LYCharSets.c: In function `HTMLGetEntityUCValue':
>./LYCharSets.c:878: error: `unicode_entities' undeclared (first use in 
>this function)


>Stop in /usr/ports/www/lynx/work/lynx2-8-6/src.

I had this problem, too.

Though, I have the latest ports tree (via portsnap), I am missing 
patch-LYCharSets (from 12 hours ago). With that, the port builds and 
installs fine.


My Makefile is not the latest, either.

Maybe it is because the last update of the port did not change the 
PORTREVISION (or PORTVERSION)? That should not interfere with portsnap 
updating the port, or should it? Or does portsnap have a "hiccup"?


Rather clueless
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

failure: portupgrade -f 'autoconf*' 'automake*'

[Jan Henrik Sylvester]

===>   autoconf-2.61_1 is already installed
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of devel/autoconf261
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1

Stop in /usr/ports/devel/autoconf261.
*** Error code 1

Stop in /usr/ports/devel/automake19.
** Command failed [exit code 1]: /usr/bin/script -qa 
/tmp/portupgrade.3481.0 env UPGRADE_TOOL=portupgrade 
UPGRADE_PORT=automake-1.9.6_1 UPGRADE_PORT_VER=1.9.6_1 make

** Fix the problem and try again.
** Listing the failed packages (*:skipped / !:failed)
! devel/automake14 (automake-1.4.6_3)   (unknown build error)
! devel/automake19 (automake-1.9.6_1)   (unknown build error)
--->  Packages processed: 4 done, 0 ignored, 0 skipped and 2 failed
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

failure: portupgrade -f 'autoconf*' 'automake*'

[Jan Henrik Sylvester]

Alex Dupre wrote:
> Jan Henrik Sylvester wrote:
> > ===>   autoconf-2.61_1 is already installed
> >   You may wish to ``make deinstall'' and install this port again
> >   by ``make reinstall'' to upgrade it properly.
> >   If you really wish to overwrite the old port of devel/autoconf261
> >   without deleting it first, set the variable "FORCE_PKG_REGISTER"
> >   in your environment or the "make install" command line.
> > *** Error code 1
>
> I think it's missing a '-' in the --program-suffix of autoconf261.

I think, there should be a '-' in front of every ${BUILD_VERSION}.

Additionally to the one at --program-suffix, there are three more missing.

Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

failure: portupgrade -f 'autoconf*' 'automake*'

[Jan Henrik Sylvester]

Ade wrote:
> On Jul 28, 2007, at 03:03 , Jan Henrik Sylvester wrote:
> > I think, there should be a '-' in front of every ${BUILD_VERSION}.
> >
> > Additionally to the one at --program-suffix, there are three more
> > missing.
>
> The appropriate fix has already been committed.  Given the very small
> window of things being broken, I'm not planning on bumping PORTREVISION.

You only fixed the --program-suffix=-${BUILD_VERSION}.

Was I wrong that in contrast to 259, in 261 there should not be a '-' in 
front of the 3 ${BUILD_VERSION} in post-patch?


From 259 (rev=1.65):
post-patch:
	@(cd ${WRKSRC} && ${REINPLACE_CMD} -E 
's,(PACKAGE=autoconf),\1-${BUILD_VERSION},' configure)

@(cd ${WRKSRC}/man && \
for file in *.[1x]; do \
			${REINPLACE_CMD} -E 
's,([^-]auto)(conf|make|reconf|update|header|scan),\1\2-${BUILD_VERSION},g 
; \
		s,(config\.guess|config\.sub|ifnames),\1-${BUILD_VERSION},g' 
$$file ; \

done)

From 261 (rev=1.69):
post-patch:
	@(cd ${WRKSRC} && ${REINPLACE_CMD} -E 
's,(PACKAGE=autoconf),\1${BUILD_VERSION},' configure)

@(cd ${WRKSRC}/man && \
for file in *.[1x]; do \
			${REINPLACE_CMD} -E 
's,([^-]auto)(conf|make|reconf|update|header|scan),\1\2${BUILD_VERSION},g 
; \


s,(config\.guess|config\.sub|ifnames),\1${BUILD_VERSION},g' $$file ; \
done)

Just wondering,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

libmtp-0.2.0 does not compile on 6.2

[Jan Henrik Sylvester]

I just tried to portupgrade libmtp, but it runs into a syntax error:

Making all in examples
cc -DHAVE_CONFIG_H -I. -I..-I/usr/local/include -I../src -O2 
-fno-strict-aliasing -pipe  -Wall -Wmissing-prototypes -MT connect.o -MD 
-MP -MF .deps/connect.Tpo -c -o connect.o connect.c

connect.c: In function `main':
connect.c:100: error: syntax error before "LIBMTP_VERSION_STRING"
*** Error code 1

The line in question is:

  fprintf(stdout, "libmtp version: " LIBMTP_VERSION_STRING "\n\n");

I currently do not find the definition of LIBMTP_VERSION_STRING... weird.

Any idea what is wrong?

Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

autoconf removal / Build error: KDE requires autoconf 2.53 or newer (kmastermind)

[Jan Henrik Sylvester]

portupgrade kmastermind-2.2_1 to kmastermind-2.2_2 failed:

*** AUTOCONF NOT FOUND!.
*** KDE requires autoconf 2.53 or newer

What should I do about it?

Moreover, portupgrade does not deal with this:

autoconf-2.53_4 <  needs updating (port has 2.61_2)
autoconf-2.59_3 <  needs updating (port has 2.61_2)
autoconf-2.61_2 =  up-to-date with port

/usr/ports/UPDATING has no instructions what to do with the obsolete 
autoconf versions. Shall I remove them although autotools-20070905, 
kde-3.5.7, and kdevelop-3.4.1_2 still "require" them? Can I do that 
without rebuilding kdevelop?


I thought about:

pkgdb -s /autoconf-2.53_4/autoconf-2.61_2/
pkgdb -s /autoconf-2.59_3/autoconf-2.61_2/
pkg_remove -f autoconf-2.53_4
pkg_remove -f autoconf-2.59_3
pkgdb -F

Would this do it? Or would I have trouble later on?

Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: aqbanking update?

[Jan Henrik Sylvester]

How is the effort bringing the aqbanking port up to date going?

Thanks,
Jan Henrik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

guile vs. guile2

[Jan Henrik Sylvester]

Now that autogen is at 5.18.10, it really does not build with guile
anymore and I cannot cheat and revert the change to guile2.

Anyhow, lilypond still has a library dependency on guile and from the
discussion on the lilypond mailing list (and other lists), I do not
think this is likely going to change, soon.

This means, I cannot build for example audacity on a system with
lilypond installed and anjuta and lilypond cannot even be installed
together.

Has anyone tried to make guile and guile2 coexist? They share files:
bin/guile* man/man1/guile.1.gz share/aclocal/guile.m4 -- but as far as I
see nothing in include or lib.

Thoughts?

Cheers,
Jan Henrik
___
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"

Incomplete origin in pkg db after: make -C /usr/ports/any/origin/

[Jan Henrik Sylvester]

"make -C /usr/ports/any/origin/ install clean" registers an incomplete 
origin ("any/" instead of "any/origin") in the package database for most 
ports or fails completely for ports-mgmt/pkg (on 11.1-RELEASE/amd64).


"make -C /usr/ports/any/origin install clean" works fine.

I am not sure, if the trailing slash is allowed in general, but it used 
to work for many years until a few weeks ago and I have several scripts 
that depends on that behavior. Maybe it was the upgrade from 11.0 to 
11.1. Otherwise something in the ports tree or in pkg changed around the 
same time.


Here are some examples:

# make -C /usr/ports/ports-mgmt/pkg/ install clean
...
make[1]: don't know how to make /usr/ports/ports-mgmt/pkg//work. Stop
...
# make -C /usr/ports/ports-mgmt/pkg install clean
... [everything works fine]
# make -C /usr/ports/ports-mgmt/dialog4ports/ install clean
...
# pkg query '%n %o'
dialog4ports ports-mgmt/
pkg ports-mgmt/pkg
# pkg delete dialog4ports
...
# make -C /usr/ports/ports-mgmt/dialog4ports install clean
...
# pkg query '%n %o'
dialog4ports ports-mgmt/dialog4ports
pkg ports-mgmt/pkg

Is it a bug or is the syntax for the directory with the trailing slash 
wrong?


Any idea if it is in make, in pkg, or in the ports tree?

Thanks,
Jan Henrik
___
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"

Maintainer timeout to fix 4 ports on 10.0?

[Jan Henrik Sylvester]

In December, I fixed a few ports to compile on 10.0:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185032
submitted: 2013-12-20 (mail to maintainer: 2013-12-06)

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185033
submitted: 2013-12-20 (mail to maintainer: 2013-12-06)

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185401
submitted: 2014-01-01 (mail to maho@: 2014-01-01)

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185558
submitted: 2014-01-07 (mail to maintainer: 2013-12-31)

I have just verified that all 4 ports are still broken on 10.0-RELEASE
(amd64) and my patches still fix the build for all of them.

They would all qualify for maintainer timeouts.

I know that there are ports waiting to be fixed on 10.0. The patches
mentioned above are pretty simple.

Cheers,
Jan Henrik
___
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"

Circular dependency, because x264 links ffmpeg

[Jan Henrik Sylvester]

# pkg info -r ffmpeg
ffmpeg-2.1.1_1,1:
libxine-1.2.4_5
vlc-2.1.2_2,4
libstreamanalyzer-0.7.8_3
x264-0.136.2358_3
# pkg info -r x264
x264-0.136.2358_3:
ffmpeg-2.1.1_1,1
ffmpeg0-0.7.16_1,1
opal-3.10.10_2
vlc-2.1.2_2,4

Not good. Since multimedia/ffmpeg depends on multimedia/x264 by default
(the option X264 is enabled by default), my x264 installation must be
broken.

After forcibly deleting x264 and rebuilding the port, it still depends
on ffmpeg:

# pkg which /usr/local/bin/x264
/usr/local/bin/x264 was installed by package x264-0.136.2358_3
# readelf -d /usr/local/bin/x264 | grep libav
 0x0001 (NEEDED) Shared library: [libavutil.so.52]
# pkg which /usr/local/lib/libavutil.so.52
/usr/local/lib/libavutil.so.52 was installed by package ffmpeg-2.1.1_1,1

The x264 port is doing something wrong (in the presence of ffmpeg).

This will probably only happening building ports in an unclean
environment, but I would have expected pkg to detect this and warn while
registering the pkg, while creating a package from it, or while this
package is installed on another machine. I never saw a warning.

Cheers,
Jan Henrik
___
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"

astro/wcslib fails to install

[Jan Henrik Sylvester]

My latest port upgrade (from source via portmaster) on
10.0-RELEASE/amd64 fails at astro/wcslib, which has been bumped after
the astro/cfitsio update. It fails to install with:

pkg-static:
lstat(/usr/ports/astro/wcslib/work/stage/usr/local/bin/HPXcvt): No such
file or directory

Building astro/wcslib does not fail, but there are numerous segfaults
starting with these:

make[2]: *** [libwcs-4.13.4.a(lin.o)] Segmentation fault (core dumped)
gmake[2]: *** Archive member `libwcs-4.13.4.a(lin.o)' may be bogus; not
deleted

cc -DHAVE_CONFIG_H -I. -I.. -O2 -pipe -fno-strict-aliasing -c sph.c
ar r libwcs-4.13.4.a sph.o
ar: warning: Incorrect file header signature
gmake[2]: *** [libwcs-4.13.4.a(sph.o)] Segmentation fault (core dumped)

What is happening here?

I do not have anything in make.conf that should be related (only
WITH_NEW_XORG=yes, TEX_DEFAULT=texlive, and some port specific options
of unrelated ports).

Cheers,
Jan Henrik
___
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: astro/wcslib fails to install

[Jan Henrik Sylvester]

Hi,

On 05/08/2014 13:56, Shin-ya Murakami wrote:
> Please try with the attached patch.
> I had successfully installed HPXcvt with this patch.

I can confirm that r353239 only fixes the segfaults during the build but
does not give bin/HPXcvt in staging, which still makes the install fail.

Since the first patch does not make too much sense, removing all files
that actually link libcfitsio.so.2 from the package with the default
option CFITSIO turned on, I tried the one by Shin-ya Murakami. The port
builds and installs and bin/HPXcvt and bin/wcsware are installed linking
libcfitsio.so.2 as intended.

Thanks,
Jan Henrik
___
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"