UPDATE: devel/p5-Config-IniFiles
Hello,
here's an update for devel/p5-Config-IniFiles, to 2.39. Tested on i386.
The MAINTAINER gives me maintainership.
Index: Makefile
===
RCS file: /cvs/ports/devel/p5-Config-IniFiles/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile23 Nov 2003 20:42:35 - 1.5
+++ Makefile27 Nov 2005 07:11:10 -
@@ -2,12 +2,12 @@
COMMENT= "module for reading .ini-style configuration files"
-DISTNAME= Config-IniFiles-2.38
+DISTNAME= Config-IniFiles-2.39
PKGNAME= p5-${DISTNAME}
CATEGORIES=devel perl5
-MASTER_SITES= ${MASTER_SITE_PERL_CPAN:=Config/}
+MASTER_SITES= http://search.cpan.org/CPAN/authors/id/G/GC/GCARLS/
-MAINTAINER=Sam Smith <[EMAIL PROTECTED]>
+MAINTAINER=Jasper Lievisse Adriaanse <[EMAIL PROTECTED]>
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP=Yes
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-Config-IniFiles/distinfo,v
retrieving revision 1.3
diff -u -r1.3 distinfo
--- distinfo5 Jan 2005 16:22:36 - 1.3
+++ distinfo27 Nov 2005 07:11:10 -
@@ -1,4 +1,4 @@
-MD5 (Config-IniFiles-2.38.tar.gz) = 17e39e4244ede0061939dcb80ab6294e
-RMD160 (Config-IniFiles-2.38.tar.gz) = f2447cc47ba9a184d3b82b349b6397b50840a4f0
-SHA1 (Config-IniFiles-2.38.tar.gz) = cc3d3982e97645bd2f58f6acfd5075a006dedba8
-SIZE (Config-IniFiles-2.38.tar.gz) = 36846
+MD5 (Config-IniFiles-2.39.tar.gz) = af23906e7d4445c4690dafed9b491cc3
+RMD160 (Config-IniFiles-2.39.tar.gz) = f8ad932c6fd90fe2063eec85f4e1f866b07811c0
+SHA1 (Config-IniFiles-2.39.tar.gz) = 8dc4e771bfcdeb85b6c7c939fba43c787f853fbb
+SIZE (Config-IniFiles-2.39.tar.gz) = 38801
Cheers,
Jasper
--
"Security is decided by quality" -- Theo de Raadt
pgpUUsGpYOXBm.pgp
Description: PGP signature
Re: libtool "no symlinked libs" patch
On Wed, Nov 23, 2005 at 05:04:07PM +, Ralf Wildenhues wrote: > Marc Espie nerim.net> writes: > > I'm very annoyed at > > libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la > > expanding into some stuff like: > > cc -L/usr/local/lib -L. -o foo foo.o -lbar > > which gets us the libbar installed under /usr/local/lib instead of the one > > we just built... > > Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption > about which path overrides which. Current branch-1-5 does not do this on > GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD. > > For static libbar, it creates on both systems > gcc -o foo foo.o ./.libs/libbar.a > and for shared libbar it creates > gcc -o .libs/foo foo.o ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst I think you are not understanding Marc's point. what happens with -L/usr/local/lib? anyway, I think a more likely scenerio would be something like: /bin/sh ./libtool --tag=CC --mode=link -L/usr/X11R6/lib -o foo foo-foo.o lib/libbar.la -lX11 the problem is that -L/usr/X11R6/lib will come before -Llib/.libs in the compile_cmd. however, if the command were given as: /bin/sh ./libtool --tag=CC --mode=link -o foo foo-foo.o lib/libbar.la -L/usr/X11R6/lib -lX11 then the library include paths would be -Llib/.libs -L/usr/X11R6/lib, which is the desired order. this can be blamed to some degree on automake. if you have this in a Makefile.am: foo_SOURCES = foo.c foo_LDADD = lib/libbar.la -lX11 -lXv foo_DEPENDENCIES = lib/libbar.la foo_CPPFLAGS = -I/usr/X11R6/include foo_LDFLAGS = -L/usr/X11R6/lib then you will get a link command like so in Makefile: LINK = $(LIBTOOL) --tag=CC --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) -o $@ foo$(EXEEXT): $(foo_OBJECTS) $(foo_DEPENDENCIES) @rm -f foo$(EXEEXT) $(LINK) $(foo_LDFLAGS) $(foo_OBJECTS) $(foo_LDADD) $(LIBS) so you end up with the local, newly created libraries coming after all possible LDFLAGS in the libtool command. at least this is what happens with automake-1.9.6. the real question is, IMO, how would libtool know what are local, new libraries? think of this: /bin/sh ./libtool --tag=CC --mode=link -o foo foo-foo.o /usr/local/lib/libglib-2.0.la $(top_builddir)lib/libbar.la -L/usr/X11R6/lib -lX11 there are two libtool libraries, both with full paths on the command line. how would libtool know the path to one should come before the path to the other? seems to me that straightening this out would require major changes to both libtool and automake. -- <[EMAIL PROTECTED]>
sysutils/stat/ redundant now?
now that stat(1) is in base, couldn't this go away?
Re: What java port for konqueror?
On Saturday 26 November 2005 19:08, steven mestdagh wrote: > On Sat, Nov 26, 2005 at 05:45:37PM -0500, Dave Feustel wrote: > > I finally need to activate Java support for Konqueror, > > but it appears that Java is not by default part of KDE > > or included in OpenBSD. What port/package(s) do I > > need for java to work with konqueror on OpenBSD? > > You are in for some compile time and probably want to start reading > this article: > http://www.openbsd.org/faq/faq13.html#javaflash > > I don't use KDE and did not test konqueror. Note that the info on the > KDE base package says you need to explicitly enable Java. > Let us know if it works... Steve. Thanks very much for the URL. Reading it reminds me why I haven't tried to use Java on OpenBSD before. I have a slow 800MHz system so I'm not sure I want to even bother trying to build Java; I have a lot of other projects to work on that are likely to be more useful. Dave -- Switch to Secure OpenBSD with a KDE desktop!!! NOW with Virtual PC OS support via QEMU and Beowulf clustering using PETSc and MPICH2!
Re: What java port for konqueror?
On Sat, Nov 26, 2005 at 05:45:37PM -0500, Dave Feustel wrote: > I finally need to activate Java support for Konqueror, > but it appears that Java is not by default part of KDE > or included in OpenBSD. What port/package(s) do I > need for java to work with konqueror on OpenBSD? You are in for some compile time and probably want to start reading this article: http://www.openbsd.org/faq/faq13.html#javaflash I don't use KDE and did not test konqueror. Note that the info on the KDE base package says you need to explicitly enable Java. Let us know if it works... -- steven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: What java port for konqueror?
On 11/27/05, Dave Feustel <[EMAIL PROTECTED]> wrote: > I finally need to activate Java support for Konqueror, > but it appears that Java is not by default part of KDE > or included in OpenBSD. What port/package(s) do I > need for java to work with konqueror on OpenBSD? All in /usr/ports/devel/jdk/*. Regards. > Thanks, > Dave Feustel > -- > Switch to Secure OpenBSD with a KDE desktop!!! > NOW with Virtual PC OS support via QEMU and > Beowulf clustering using PETSc and MPICH2! > >
What java port for konqueror?
I finally need to activate Java support for Konqueror, but it appears that Java is not by default part of KDE or included in OpenBSD. What port/package(s) do I need for java to work with konqueror on OpenBSD? Thanks, Dave Feustel -- Switch to Secure OpenBSD with a KDE desktop!!! NOW with Virtual PC OS support via QEMU and Beowulf clustering using PETSc and MPICH2!
Re: teTeX and no_x11
hmm, on Sat, Nov 26, 2005 at 10:45:06PM +0100, Nikolay Sturm said that > > maybe it's just me, i was making incorrect assumptions about > > what no_x11 means. > > Your assumptions are correct. teTeX_base,no_x11 is broken in that regard > and installing xbase is a workaround. > > > and if this is the way it will be, wouldn't it be a good idea to make > > an xlib38.tgz which would hold only the libs and nothing else, after > > all, isn't it the security mantra that don't install anything you > > won't use, and xbase is full of binaries which will be never used on a > > firewall? > > If you have enough disk space on your firewall/server, just install > xbase and be done. If you don't have the space, you are on your own > anyways and can just as well pull tetex/base/Makefile from -current and > build your own package with a correct no_x11 FLAVOR. you put it as if teTeX was(before being fixed) the only case.. and of course teTeX is not really a firewall "required" program. when i said firewall, i rather meant packages like rrdtools (which at one point also need xbase) or other reporting tools needing x11 libs but really needing x11. -f -- sex is not the answer. sex is the question. "yes" is the answer.
Re: teTeX and no_x11
* frantisek holop [2005-11-26]: > call me old fashioned but no_x11 for me means not havint to > install any x*.tgz sets. That's the idea. > now, of course it's not a huge problem for me to install xbase, it's > just that this "consensus" was never really publicized here before, at > least i haven't seen. We don't write reports. I think Alek and Matthieu mentioned it recently as well. > maybe it's just me, i was making incorrect assumptions about > what no_x11 means. Your assumptions are correct. teTeX_base,no_x11 is broken in that regard and installing xbase is a workaround. > and if this is the way it will be, wouldn't it be a good idea to make > an xlib38.tgz which would hold only the libs and nothing else, after > all, isn't it the security mantra that don't install anything you > won't use, and xbase is full of binaries which will be never used on a > firewall? If you have enough disk space on your firewall/server, just install xbase and be done. If you don't have the space, you are on your own anyways and can just as well pull tetex/base/Makefile from -current and build your own package with a correct no_x11 FLAVOR. Now I need to get back to porting... Nikolay
Re: teTeX and no_x11
hmm, on Sat, Nov 26, 2005 at 01:45:45PM +0100, Nikolay Sturm said that > Now for your problem, you can just pull the -current port's Makefile to > your 3.8 machine and it should work. Furthermore it is consensus among > porters that installing xbase on a machine is not a problem, so the > broken FLAVOR is a nuisance, nothing more. that is of the other issues i wanted to talk about later. call me old fashioned but no_x11 for me means not havint to install any x*.tgz sets. now, of course it's not a huge problem for me to install xbase, it's just that this "consensus" was never really publicized here before, at least i haven't seen. maybe it's just me, i was making incorrect assumptions about what no_x11 means. and if this is the way it will be, wouldn't it be a good idea to make an xlib38.tgz which would hold only the libs and nothing else, after all, isn't it the security mantra that don't install anything you won't use, and xbase is full of binaries which will be never used on a firewall? > Feel free to execrate me for not fixing the problem before 3.8 tree > freeze. no need to get angry, it was just a matter of interpreting 'reliability'. -f -- a war put off is not a war avoided. -- c. heston
Re: UPDATE: audio/p5-cddb
On Sat, Nov 26, 2005 at 08:01:11PM +0100, Jasper Lievisse Adriaanse wrote:
> Hello,
>
> this diff brings audio/p5-cddb up to date. Tested on i386.
> Yes, it fails some regression tests, but the in-tree version does this too.
this patch should fix it (patch-t_cddb_t). apparently there are now two
matches for the cddb test disc ID. do you want to maintain this port?
$OpenBSD$
--- t/cddb.t.orig Sat Nov 26 20:19:34 2005
+++ t/cddb.tSat Nov 26 20:55:04 2005
@@ -134,13 +134,13 @@ else {
print "not ok 12\n";
}
-### test looking up discs (one match)
+### test looking up discs (two matches)
my @discs = $cddb->get_discs($id, $track_offsets, $total_seconds);
-(@discs == 1) || print 'not '; print "ok 13\n";
+(@discs == 2) || print 'not '; print "ok 13\n";
-my ($genre, $cddb_id, $title) = @{$discs[0]};
+my ($genre, $cddb_id, $title) = @{$discs[1]};
($genre eq 'misc') || print 'not '; print "ok 14\n";
($cddb_id eq '03015501') || print 'not '; print "ok 15\n";
@@ -153,7 +153,7 @@ $cddb->disconnect();
my @other_discs = $cddb->get_discs_by_toc(@toc);
if (@other_discs) {
- (@other_discs == 1) || print 'not '; print "ok 17\n";
+ (@other_discs == 2) || print 'not '; print "ok 17\n";
($other_discs[0]->[0] eq $discs[0]->[0]) || print 'not '; print "ok 18\n";
($other_discs[0]->[1] eq $discs[0]->[1]) || print 'not '; print "ok 19\n";
($other_discs[0]->[2] eq $discs[0]->[2]) || print 'not '; print "ok 20\n";
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
UPDATE: audio/p5-cddb
Hello,
this diff brings audio/p5-cddb up to date. Tested on i386.
Yes, it fails some regression tests, but the in-tree version does this too.
Index: Makefile
===
RCS file: /cvs/ports/audio/p5-cddb/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile7 Feb 2005 19:01:48 - 1.15
+++ Makefile26 Nov 2005 16:17:19 -
@@ -2,7 +2,7 @@
COMMENT= "Perl5 module for CDDB"
-DISTNAME= CDDB-1.15
+DISTNAME= CDDB-1.16
PKGNAME= p5-${DISTNAME}
CATEGORIES=audio perl5
Index: distinfo
===
RCS file: /cvs/ports/audio/p5-cddb/distinfo,v
retrieving revision 1.6
diff -u -r1.6 distinfo
--- distinfo5 Jan 2005 15:47:08 - 1.6
+++ distinfo26 Nov 2005 16:17:19 -
@@ -1,4 +1,4 @@
-MD5 (CDDB-1.15.tar.gz) = 978aaecd665af4988d33d8f3df392fb7
-RMD160 (CDDB-1.15.tar.gz) = 1c2f00c135b5019753870aa9336f2ce3d1b99858
-SHA1 (CDDB-1.15.tar.gz) = aca1b94d1fb4f046270ac2a3f8e15ac970f1f6d3
-SIZE (CDDB-1.15.tar.gz) = 22009
+MD5 (CDDB-1.16.tar.gz) = 4753c73ac7162ab18d1508ae02d40014
+RMD160 (CDDB-1.16.tar.gz) = 509a52aa11c034bb6bb629e9362ee57facc7715d
+SHA1 (CDDB-1.16.tar.gz) = 212f71d1c22a597cb72df85212ea6e9d0a2f3152
+SIZE (CDDB-1.16.tar.gz) = 22657
Cheers,
Jasper
--
"Security is decided by quality" -- Theo de Raadt
Re: UPDATE: archivers/p5-Archive-Zip
On Sat, 26 Nov 2005 17:57:25 +0100 Aleksander Piotrowski <[EMAIL PROTECTED]> wrote: > Jasper Lievisse Adriaanse <[EMAIL PROTECTED]> wrote: > > > this diff brings archivers/p5-Archive-Zip to the most recent version; 1.16. > > Tested on i386. > > Are you interested in being maintainer of this port? Yes please. > > Alek Cheers, Jasper > -- > - Miro, tak mi przykro. Zawsze litowałam się nad ludźmi, bo mogliście > pomyśleć tylko o jednej rzeczy na raz, wasze wspomnienia były takie nieostre > i... A teraz zrozumiałam, że samo przeżycie całego dnia tak, żeby nikogo nie > zabić, może być osiągnięciem. > - Człowiek się przyzywyczaja. Większość z nas ma na koncie dość niską liczbę > ofiar. Utrzymujemy dobrosąsiedzkie stosunki. > -- Orson Scott Card, Dzieci Umysłu. > -- "Security is decided by quality" -- Theo de Raadt pgpxyyFFBGxeh.pgp Description: PGP signature
Re: UPDATE: archivers/p5-Archive-Zip
Jasper Lievisse Adriaanse <[EMAIL PROTECTED]> wrote: > this diff brings archivers/p5-Archive-Zip to the most recent version; 1.16. > Tested on i386. Are you interested in being maintainer of this port? Alek -- - Miro, tak mi przykro. Zawsze litowałam się nad ludźmi, bo mogliście pomyśleć tylko o jednej rzeczy na raz, wasze wspomnienia były takie nieostre i... A teraz zrozumiałam, że samo przeżycie całego dnia tak, żeby nikogo nie zabić, może być osiągnięciem. - Człowiek się przyzywyczaja. Większość z nas ma na koncie dość niską liczbę ofiar. Utrzymujemy dobrosąsiedzkie stosunki. -- Orson Scott Card, Dzieci Umysłu.
Re: Request for new port: vifm
I have to correct myself, it DOES also work on (just had to copy over parts of a newer automake): hppa (don't know about vax, can't get the ethernet to work right now, still 3.5 on it, long time since I switched it on) Regards, ahb
Re: Request for new port: vifm
Hello ports@ again,
sorry for answering my own mail, but I did some more research:
To make vifm compile you just have to install automake >1.7 (I used 1.9) change
the links in vifm/ to point to
/usr/local/share/automake-1.9/{depcomp,install-sh,missing,mkinstalldirs}
The "patch" I posted before has to be used (still don't know why, older version
of ncurses on openbsd?).
I found about about more niffty features, one is that you can define default
programs for every file type, so vifm will use those programms to open them.
As I said EVERYBODY working with VI[M] and many files should have a look at it,
the ease of use is just impressive.
Since I didn't get any reply so far what could I do to get it adopted as an
official port?
Btw, it works (at least) on:
i386
amd64
(not on hppa and vax (there is no new enough autoconf :))
Regards,
ahb
UPDATE: archivers/p5-Archive-Zip
Hello,
this diff brings archivers/p5-Archive-Zip to the most recent version; 1.16.
Tested on i386.
Index: Makefile
===
RCS file: /cvs/ports/archivers/p5-Archive-Zip/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile6 Jul 2005 23:18:09 - 1.8
+++ Makefile26 Nov 2005 15:58:57 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.8 2005/07/06 23:18:09 jolan Exp $
COMMENT= "perl interface to ZIP files"
-DISTNAME= Archive-Zip-1.14
+DISTNAME= Archive-Zip-1.16
PKGNAME= p5-${DISTNAME}
CATEGORIES=archivers perl5
Index: distinfo
===
RCS file: /cvs/ports/archivers/p5-Archive-Zip/distinfo,v
retrieving revision 1.4
diff -u -r1.4 distinfo
--- distinfo10 Mar 2005 10:55:04 - 1.4
+++ distinfo26 Nov 2005 15:58:57 -
@@ -1,4 +1,4 @@
-MD5 (Archive-Zip-1.14.tar.gz) = 96b2caf19d5aea3adff02c323247e66a
-RMD160 (Archive-Zip-1.14.tar.gz) = 302c15961268ebb173a5133fbb5c3f17d4144642
-SHA1 (Archive-Zip-1.14.tar.gz) = e4eb9af1540039ce60af9be35d27ba354bad0228
-SIZE (Archive-Zip-1.14.tar.gz) = 110330
+MD5 (Archive-Zip-1.16.tar.gz) = e28dff400d07b1659d659d8dde7071f1
+RMD160 (Archive-Zip-1.16.tar.gz) = aeacb97732dd13138405db49acbc851448863f58
+SHA1 (Archive-Zip-1.16.tar.gz) = 5eadeb821341e8491014003694aeb4380f3f39ae
+SIZE (Archive-Zip-1.16.tar.gz) = 111336
Cheers,
Jasper
--
"Security is decided by quality" -- Theo de Raadt
Re: glib2/gnome weirdness
Marc Espie dixit: >646ISO-8859-1 646 ASCII >to /usr/local/lib/charset.alias should fix things (even though it's >slightly incorrect) That looks better to me. //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: glib2/gnome weirdness
On Sat, Nov 26, 2005 at 08:30:58AM -0600, Jolan Luff wrote: > On Sat, Nov 26, 2005 at 01:33:02PM +1100, Damien Miller wrote: > > > > Actually they are fatal - gnome-terminal crashes at start and it is > > impossible to manually run Xterm from the "run application" menu item, it > > gives the same "Conversion from character set..." error as below. > > > > Forgot to mention - I am on i386. > > this is fallout from the CODESET stuff espie did. dvdauthor is also > broken, gqview spews warnings, etc. > > do we have to go through fixing ports or is this a src problem? > > > On Sat, 26 Nov 2005, Damien Miller wrote: > > > > > > > >Hi, > > > > > >I am installing a fresh machine with the Nov 24 os + ports snapshot and I > > >am seeing these warnings as I install gnome-session: > > > > > >>GLib: Cannot convert message: Conversion from character set 'UTF-8' to > > >>'646' is not supported > > >>GLib: Cannot convert message: Conversion from character set 'UTF-8' to > > >>'646' is not supported > > >>WARNING: Failed to parse default value `([binary gibberish[)' for schema > > >>(/schemas/apps/gnome-terminal/global/active_encodings) > > >>gnome-session-2.10.0p0:gnome-terminal-2.10.0p0: complete > > > > > >Any ideas? They look non-fatal so far... > > > > > >-d Looks like the charset.alias file from libiconv needs to be completed with info about what to do with 646... netbsd does not have the issue because it does not use gnu libiconv... Just adding a line like: 646 ISO-8859-1 to /usr/local/lib/charset.alias should fix things (even though it's slightly incorrect)
Re: update: gtkpod
On Sat, Nov 26, 2005 at 12:04:53AM +0100, Nikolay Sturm wrote: > Attached diff updates gtkpod to 0.94.0, the latest stable release. If > someone could test this with an ipod, I'd appreciate it. this doesn't work with my ipod shuffle but the in-tree version does.
Re: glib2/gnome weirdness
On Sat, Nov 26, 2005 at 01:33:02PM +1100, Damien Miller wrote: > > Actually they are fatal - gnome-terminal crashes at start and it is > impossible to manually run Xterm from the "run application" menu item, it > gives the same "Conversion from character set..." error as below. > > Forgot to mention - I am on i386. this is fallout from the CODESET stuff espie did. dvdauthor is also broken, gqview spews warnings, etc. do we have to go through fixing ports or is this a src problem? > On Sat, 26 Nov 2005, Damien Miller wrote: > > > > >Hi, > > > >I am installing a fresh machine with the Nov 24 os + ports snapshot and I > >am seeing these warnings as I install gnome-session: > > > >>GLib: Cannot convert message: Conversion from character set 'UTF-8' to > >>'646' is not supported > >>GLib: Cannot convert message: Conversion from character set 'UTF-8' to > >>'646' is not supported > >>WARNING: Failed to parse default value `([binary gibberish[)' for schema > >>(/schemas/apps/gnome-terminal/global/active_encodings) > >>gnome-session-2.10.0p0:gnome-terminal-2.10.0p0: complete > > > >Any ideas? They look non-fatal so far... > > > >-d > > > >
Re: SIP Soft Phone
On Fri, Nov 25, 2005 at 09:03:45PM -0600, Todd T. Fries wrote: > Nope. > > If anybody wants to suggest anything that I've missed, or take any of > these further, feel free. > > Roy Morris wrote: > >Anyone know of a SIP soft phone that works on Obsd? The > >3.7 ports don't show any. > > [EMAIL PROTECTED]/p8 5175$ ls telephony/ > bayonne/ iax/ iaxcomm/ linphone/ yate/ > gnophone/ iaxclient/ kphone/twinkle/ > [EMAIL PROTECTED]/p8 5176$ there's also shtoom, http://divmod.org/projects/shtoom.
Re: New port: fontforge
On Wed, Nov 23, 2005 at 06:33:05AM -0500, Vladimir Támara Patiño wrote: > Good morning in the Lord > > Fontforge. > > An outline font editor that lets you create your own postscript, > truetype, opentype, cid-keyed, multi-master, cff, svg and bitmap (bdf) > fonts, or edit existing ones. Also lets you convert one format to another. > FontForge has support for many macintosh font formats. - use $OpenBSD$ tag and remove 'An' from COMMENT - you can skip V variable - configure cannot find headers so pass include dirs in CONFIGURE_ENV + remove this /usr/pkg include dir they use no need to patch configure like that, make sure your CFLAGS are passed properly everywhere. - decide on a proper dependency list - this thing uses its own libtool so try USE_LIBTOOL=Yes - try adding 'dest' to CONFIGURE_STYLE instead of patching that makefile ... -- steven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: teTeX and no_x11
* frantisek holop [2005-11-25]: > > > could this be fixed for 3.8 release? > > > > no, only security/reliability issues are fixed in -stable. > > you can try to backport the fixes from current, if you really need this. > > isn't this reliability? In principal we only backport security fixes. If sth else breaks due to this, we fix those ports as well. AFAIK there was only one exception to these rules and that was a port which was completely unusable. Now for your problem, you can just pull the -current port's Makefile to your 3.8 machine and it should work. Furthermore it is consensus among porters that installing xbase on a machine is not a problem, so the broken FLAVOR is a nuisance, nothing more. Feel free to execrate me for not fixing the problem before 3.8 tree freeze. Nikolay
Re: teTeX and no_x11
On Fri, Nov 25, 2005 at 03:56:15PM +0100, frantisek holop wrote: > hmm, on Fri, Nov 25, 2005 at 03:30:26PM +0100, steven mestdagh said that > > On Fri, Nov 25, 2005 at 03:00:44PM +0100, frantisek holop wrote: > > > hi there, > > > > > > i have upgraded my production server to 3.8 release. > > > i have no X there, but as in my previous post about the new > > > rrdtools i sense some shift in what actually no_x11 means > > > or will mean in the future. > > > > > > please note that i am describing a 3.8 release situation, > > > if this is fixed in current, disregard it. > > > > > > first of all here's the log of installing tetex no_x11: > > > > > > integer> sudo pkg_add teTeX_base-3.0p1-no_x11 > > > teTeX_base-3.0p1-no_x11:png-1.2.8: complete > > > teTeX_base-3.0p1-no_x11:t1lib-5.0.0: complete > > > teTeX_base-3.0p1-no_x11:ghostscript-fonts-6.0: complete > > > Can't install ghostscript-7.05p6: lib not found ICE.8.0 > > > Even by looking in the dependency tree: > > > ghostscript-fonts-6.0, png-1.2.8 > > > > this has been fixed in -current, see cvs logs. > > > > > could this be fixed for 3.8 release? > > > > no, only security/reliability issues are fixed in -stable. > > you can try to backport the fixes from current, if you really need this. > > isn't this reliability? has your system become less reliable due to this? i think not. there is simply no time to fix all little port mistakes in the -stable trees. > it's not the problem of the actual software but the port. > > and 3.8 will be supported for 12 months from now on uhu, and in about 5 months, there will be 3.9 with the fix included. -- steven Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Re: sparc64 breakage
* Jolan Luff [2005-11-25]: > > net/gaimcannot find silc > > does anyone know what commit caused gaim not to package correctly? > the following diff makes it package again but i'd like to cure the > disease, not the symptom. All I can say is, that it packaged ok with the bulk build started November 11th, but failed with the one started November 18th. I used regular snapshots, so the offending commit could have happened a few days earlier. I saw other instances, where inter-library dependencies worked for a port on i386 but not on sparc64. I have no idea about the culprit. Nikolay
