Re: JDK 1.6 Broken
On Tue, Dec 31, 2013 at 12:14:26PM -0800, Scott Vanderbilt wrote: > So I see that the jdk-1.6 port has been marked as broken, > unfortunately, only after upgrading to the latest snapshot (i386). > > Might anyone have any idea when this will be working again? No. It's actually been broken for a while. jdk 1.6 has been very flaky on i386 for quite a few months. Building packages snapshots has been very trying, as java ports started breaking very randomly. A few weeks ago, it took a turn for the worse. Now, java ports exit with the same thread error in a predictable way. "guarantee(get_thread() == thread) failed" This is probably not true if you don't run GENERIC.MP, but then building snapshots on SP kernels won't happen. There's obviously something that changed in the handling of threads, and it broke java. It's quite likely to be something related to atomic operations. That's about everything we know. But rest assured that the breakage is not new, it was already there around 5.4, but in a less obvious way. Having it be actually completely broken is probably a good thing, as it means that some people will take notice and might fix it eventually.
[RFC] graphics/pysane
Hi, could you please: * have a look at port as itself * (if you have a scanner) to test it? pysane is needed as deps for ocrfeeder, which I'm working on. We don't have any OCR gui in our ports :( jirib pysane.tar.gz Description: application/tar-gz
Re: JDK 1.6 Broken
On 1/1/2014 6:41 AM, Marc Espie wrote: On Tue, Dec 31, 2013 at 12:14:26PM -0800, Scott Vanderbilt wrote: So I see that the jdk-1.6 port has been marked as broken, unfortunately, only after upgrading to the latest snapshot (i386). Might anyone have any idea when this will be working again? No. It's actually been broken for a while. jdk 1.6 has been very flaky on i386 for quite a few months. Building packages snapshots has been very trying, as java ports started breaking very randomly. A few weeks ago, it took a turn for the worse. Now, java ports exit with the same thread error in a predictable way. "guarantee(get_thread() == thread) failed" This is probably not true if you don't run GENERIC.MP, but then building snapshots on SP kernels won't happen. There's obviously something that changed in the handling of threads, and it broke java. It's quite likely to be something related to atomic operations. That's about everything we know. But rest assured that the breakage is not new, it was already there around 5.4, but in a less obvious way. Having it be actually completely broken is probably a good thing, as it means that some people will take notice and might fix it eventually. Thanks very much for your response. While I have no doubt the port may have been broken for some time, it was working reliably in my particular use case as of the Dec. 7 snapshot. (I'm running Apache Solr 4.6.) It was only after I updated to the Dec. 28 snapshot that the breakage manifested itself. Following up on your suggestion about GENERIC.MP, I switched to bsd.sp in the belief that this might get the JRE running again. However, it failed in the same way as under the bsd.mp kernel. Do you have any other suggestions to get the JRE limping along? Failing that, I will have to roll back to the Dec. 7 snapshot. A working JRE on this host is imperative for me. FWIW, I have submitted a bug report to http://bugreport.sun.com/. Thanks again for your assistance, and Happy New Year.
Re: JDK 1.6 Broken
> While I have no doubt the port may have been broken for some time, it > was working reliably in my particular use case as of the Dec. 7 > snapshot. (I'm running Apache Solr 4.6.) It was only after I updated to > the Dec. 28 snapshot that the breakage manifested itself. > > Following up on your suggestion about GENERIC.MP, I switched to bsd.sp > in the belief that this might get the JRE running again. However, it > failed in the same way as under the bsd.mp kernel. Do you have any other > suggestions to get the JRE limping along? Failing that, I will have to > roll back to the Dec. 7 snapshot. A working JRE on this host is > imperative for me. > > FWIW, I have submitted a bug report to http://bugreport.sun.com/. Given that Java 6 has been EOL'd by Oracle for almost a year (Feb 2013, as announced in Feb 2011), and it's on an operating system they don't even know about, your bug report will most likely be ignored. Sorry you wasted time there. Given the situation with Java 6 being broken, it would probably make sense to work on correcting/updating apps to work on Java 7. Java 8 is just around the corner, btw. March 2014.
Re: JDK 1.6 Broken
On 1/1/2014 10:00 AM, Ian Darwin wrote: Given that Java 6 has been EOL'd by Oracle for almost a year (Feb 2013, as announced in Feb 2011), and it's on an operating system they don't even know about, your bug report will most likely be ignored. Sorry you wasted time there. Given the situation with Java 6 being broken, it would probably make sense to work on correcting/updating apps to work on Java 7. Thanks for that, Ian. I should have made clear that I'm not actually running JDK 1.6, but rather 1.7.0_21 (from ports current). And my bug report to Sun indicated that as well. I know nothing about JDK internals, so I can't even begin to speculate. All I know is the bug occurred while running 1.7, yet 1.6 is the port now marked as broken. I do know that JDK 1.6 is a dependency for building 1.7, so it probably has something to do with that linkage.
Re: UPDATE: fonts/dina-fonts
On Tue Dec 31, 2013 at 07:26:28PM +0100, Tobias Ulmer wrote:
> On Sun, Dec 29, 2013 at 10:24:39PM +0100, Rafael Sadowski wrote:
> > On Sun Dec 29, 2013 at 09:16:10PM +, Mikolaj Kucharski wrote:
> > > On Sun, Dec 29, 2013 at 06:33:27PM +0100, Rafael Sadowski wrote:
> > > > +SHA256 (Dina.zip) = H1G7pT91pk0ti9A36OD4S2+AZOUKcu6VQDO+3hc1CM8=
> > > > +SIZE (Dina.zip) = 68023
> > >
> > > You should make distfile name more unique, in case you update the port
> > > in the future.
> > >
> > > --
> > > best regards
> > > q#
> >
> > yeah, thanks! New patch:
> >
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/fonts/dina-fonts/Makefile,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 Makefile
> > --- Makefile11 Mar 2013 11:06:05 - 1.3
> > +++ Makefile29 Dec 2013 21:24:02 -
> > @@ -2,9 +2,9 @@
> >
> > COMMENT = monospace bitmap font, primarily aimed at programmers
> >
> > -V =2.89
> > +V =2.92
> > PKGNAME = dina-fonts-$V
> > -DISTNAME = dina-pcf-$V
> > +DISTFILES= dina-fonts-${V}.zip{Dina.zip}
>
> Too clever for my taste
>
> > CATEGORIES = fonts
> >
> > HOMEPAGE = http://www.donationcoder.com/Software/Jibz/Dina/
> > @@ -12,21 +12,39 @@ HOMEPAGE = http://www.donationcoder.com
> > MAINTAINER = Rafael Sadowski
> >
> > # FREE (c) Jorgen Ibsen (Though no license included in distribution)
>
> The zip file now contains a license. It should be installed and the
> permit markers updated. License looks good (MIT). You can drop all lines but
> the CDROM one now (check bsd.port.mk(5)).
>
> > -PERMIT_PACKAGE_CDROM = No
> > -PERMIT_PACKAGE_FTP = No
> > -PERMIT_DISTFILES_FTP = No
> > +PERMIT_PACKAGE_CDROM = No
> > +PERMIT_PACKAGE_FTP = No
> > +PERMIT_DISTFILES_FTP = No
>
> If you can't help re-formating those lines, at least use proper tabs ;)
>
> >
> > -MASTER_SITES = http://ftp.fi.debian.org/gentoo/distfiles/
> > +EXTRACT_SUFX = .zip
> > +MASTER_SITES =
> > http://www.donationcoder.com/Software/Jibz/Dina/downloads/
>
> This will break once the author updates his "Dina.zip". The Debian
> distfiles mirror had proper versioning. If you need a place to host
> "dina-2.92.zip", ask here.. Even better if you can convince the author
> to start releasing versioned zip files.
>
> >
> > -NO_BUILD = Yes
> > -NO_TEST = Yes
> > +NO_BUILD = Yes
> > +NO_TEST = Yes
> > USE_X11 = Yes
> >
> > FONTDIR= ${PREFIX}/lib/X11/fonts/dina
> >
> > -WRKSRC = ${WRKDIR}/Dina-PCF
> > +WRKSRC = ${WRKDIST}/BDF
> > +
> > +do-extract:
> > + mkdir -p ${WRKDIST}
> > + unzip -oq -d ${WRKDIST} ${FULLDISTDIR}/${EXTRACT_ONLY}
> > +
> >
> > do-install:
> > + bdftopcf -t -o ${WRKSRC}/DinaItalic10.pcf ${WRKSRC}/Dina_i400-10.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaItalic8.pcf ${WRKSRC}/Dina_i400-8.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaItalic9.pcf ${WRKSRC}/Dina_i400-9.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaBoldItalic10.pcf ${WRKSRC}/Dina_i700-10.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaBoldItalic8.pcf ${WRKSRC}/Dina_i700-8.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaBoldItalic9.pcf ${WRKSRC}/Dina_i700-9.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaMedium10.pcf ${WRKSRC}/Dina_r400-10.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaMedium8.pcf ${WRKSRC}/Dina_r400-8.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaMedium9.pcf ${WRKSRC}/Dina_r400-9.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaBold10.pcf ${WRKSRC}/Dina_r700-10.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaBold8.pcf ${WRKSRC}/Dina_r700-8.bdf
> > + bdftopcf -t -o ${WRKSRC}/DinaBold9.pcf ${WRKSRC}/Dina_r700-9.bdf
> > ${GZIP_CMD} ${WRKSRC}/*.pcf
> > ${X11BASE}/bin/mkfontdir ${WRKSRC}
> > egrep '\.pcf\.gz' ${WRKSRC}/fonts.dir | \
>
> Dina_r400-6.bdf is missing.
>
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/fonts/dina-fonts/distinfo,v
> > retrieving revision 1.1.1.1
> > diff -u -p -r1.1.1.1 distinfo
> > --- distinfo7 Dec 2011 09:27:16 - 1.1.1.1
> > +++ distinfo29 Dec 2013 21:24:02 -
> > @@ -1,5 +1,2 @@
> > -MD5 (dina-pcf-2.89.tar.gz) = 1sQlwAeppXa0u4jIjPVwdg==
> > -RMD160 (dina-pcf-2.89.tar.gz) = bQLzN2RIzzKstI5LpGS3Pmc3Ek8=
> > -SHA1 (dina-pcf-2.89.tar.gz) = dw8YqDJJCiLMjKWfCS7EAe72uEA=
> > -SHA256 (dina-pcf-2.89.tar.gz) =
> > KYnGi8Tm8xQ1/nwnMNluZO8xlLEiNl8p+vBsS6xwGaY=
> > -SIZE (dina-pcf-2.89.tar.gz) = 36442
> > +SHA256 (dina-fonts-2.92.zip) = H1G7pT91pk0ti9A36OD4S2+AZOUKcu6VQDO+3hc1CM8=
> > +SIZE (dina-fonts-2.92.zip) = 68023
> >
Thanks Tobias Ulmer, new try:
Index: Makefile
===
RCS file: /cvs/ports/fonts/dina-fonts/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefil
Help needed - a WIP port for ocrfeeder
Hi all, I've thought it would be not so difficult to make ocrfeeder (port[1]) running on OpenBSD but... Well, it core dumps. I would appreciate any help, as it seems to be one of few OSS OCR application available. I submitted a BZ[2] for upstream but I'm not even sure if it is an OpenBSD issue or an upstream one. My skills are limited :( (gdb) bt #0 0x10d5270e521a in kill () at :2 #1 0x10d52714565a in abort () at /usr/src/lib/libc/stdlib/abort.c:70 #2 0x10d5279bd325 in pthread_mutex_unlock (mutexp=Variable "mutexp" is not available. ) at /usr/src/lib/librthread/rthread_sync.c:219 #3 0x10d532538c11 in g_mutex_unlock () from /usr/local/lib/libglib-2.0.so.3800.0 #4 0x10d53a98c13b in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.2400.0 #5 0x10d53490875d in _wrap_gtk_main () from /usr/local/lib/python2.7/site-packages/gtk-2.0/gtk/_gtk.so #6 0x10d5285f18d9 in PyEval_EvalFrameEx () from /usr/local/lib/libpython2.7.so.0.0 #7 0x10d5285f20f5 in PyEval_EvalFrameEx () from /usr/local/lib/libpython2.7.so.0.0 #8 0x10d5285f32cd in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.7.so.0.0 #9 0x10d5285f33c2 in PyEval_EvalCode () from /usr/local/lib/libpython2.7.so.0.0 #10 0x10d52860ef92 in run_mod () from /usr/local/lib/libpython2.7.so.0.0 #11 0x10d52860f066 in PyRun_FileExFlags () from /usr/local/lib/libpython2.7.so.0.0 #12 0x10d52861069d in PyRun_SimpleFileExFlags () from /usr/local/lib/libpython2.7.so.0.0 #13 0x10d52862140d in Py_Main () from /usr/local/lib/libpython2.7.so.0.0 #14 0x10d31c800cb1 in _start () from /usr/local/bin/python2.7 #15 0x in ?? () [1] https://github.com/jirib/openbsd-mystuff/tree/master/x11/gnome/ocrfeeder [2] https://bugzilla.gnome.org/show_bug.cgi?id=721313 PS: You can of course point me to some reading, so I could improve skills :) jirib
Re: Help needed - a WIP port for ocrfeeder
On Wed, Jan 01, 2014 at 03:48:10PM -0500, Jiri B wrote: > Hi all, > > I've thought it would be not so difficult to make ocrfeeder > (port[1]) running on OpenBSD but... Well, it core dumps. WIP ocrfeeder port and its (new) deps in attachment. jirib ocrfeeder.tar.gz Description: application/tar-gz
Re: JDK 1.6 Broken
On 2014/01/01 10:11, Scott Vanderbilt wrote: > On 1/1/2014 10:00 AM, Ian Darwin wrote: > > >Given that Java 6 has been EOL'd by Oracle for almost a year (Feb 2013, > >as announced in Feb 2011), and it's on an operating system they > >don't even know about, your bug report will most likely be ignored. > >Sorry you wasted time there. > > > >Given the situation with Java 6 being broken, it would probably > >make sense to work on correcting/updating apps to work on Java 7. > > Thanks for that, Ian. > > I should have made clear that I'm not actually running JDK 1.6, but rather > 1.7.0_21 (from ports current). And my bug report to Sun indicated that as > well. > > I know nothing about JDK internals, so I can't even begin to speculate. All > I know is the bug occurred while running 1.7, yet 1.6 is the port now marked > as broken. I do know that JDK 1.6 is a dependency for building 1.7, so it > probably has something to do with that linkage. > The problem is that JDK 1.6 itself quite often builds, but produces a package which does not work. Previously they used to fail intermittently and in many cases after 6 or 7 attempts to rebuild things, sometimes also needing a reboot onto an SP kernel, I've been able to get a full bulk build done eventually. But this is far too time-consuming to do regularly. It has now changed such that I am unable to get any working builds so marking jdk broken saves many hours dealing with failures in bulk builds. Your current options are: - move to amd64. - move back to code from a month or two ago. If anyone is able to help track down the timeframe this got broken (or even pin it to a particular commit in base), that would be extremely helpful...
i386 bulk build failures
Quick summary of the failures in the last i386 bulk build. Java ports are now broken on i386 as a result of JDK problems. www/chromium,proprietary: 'chrome/common/extensions/api/runtime.h' file not found - this is possibly the missing interdependency that espie just fixed. Following are PIE-related, in some cases use of -fomit-frame-pointer for i386 may help, others will need more. devel/hasktags: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' devel/hs-ghc-paths: unhandled ELF relocation(Rel) type 10, ghc: unable to load package `integer-gmp' emulators/dosbox: PIC register '%ebx' clobbered in 'asm' emulators/mupen64plus/core: now uses PIC #ifdef in src/r4300/x86/rjump.c:104 which needs newer GCC (about to send diff for this). emulators/openmsx: out of reg's emulators/xnp2: PIC register 'ebx' clobbered in 'asm' games/eduke32: out of reg's games/megaglest/base: out of reg's games/openarena: out of reg's graphics/cqcam: PIC register 'bx' clobbered in 'asm' graphics/rawstudio: out of reg's multimedia/avidemux: out of reg's sysutils/grub: GRUB requires a working absolute objcopy x11/mplayer: out of reg's x11/xdesktopwaves: PIC register 'ebx' clobbered in 'asm' Not sure about cause yet, some may be PIE-related too: lang/gcc/4.8: gcj: fatal error: can't specify '-D' without '--main' lang/gprolog: segfault when running "gplc -c --fast-math fd2c.pl" lang/nhc98: segfaults in build lang/petite-chez: undefined reference to `__guard' mail/zarafa/zarafa: 'SWIG_From_long' was not declared in this scope textproc/redland-bindings: -php4 is no longer supported. This is with the committed PIE changes only, there is a diff around to enable PIE in ports compilers too, which may expose further problems.
Re: JDK 1.6 Broken
On 1/1/2014 1:21 PM, Stuart Henderson wrote: If anyone is able to help track down the timeframe this got broken (or even pin it to a particular commit in base), that would be extremely helpful... I was previously running a snapshot from Dec. 7 that did not exhibit the error. Sorry I can't be more specific than that.
Re: i386 bulk build failures
On Wed, Jan 01, 2014 at 09:38:48PM +, Stuart Henderson wrote: > Quick summary of the failures in the last i386 bulk build. > Java ports are now broken on i386 as a result of JDK problems. > > www/chromium,proprietary: 'chrome/common/extensions/api/runtime.h' file not > found > - this is possibly the missing interdependency that espie just fixed. Yes it is.
Drop USE_GROFF from Makefile.template
"Drop USE_GROFF since groff and mandoc produce identical output." cheers Rafael Index: Makefile.template === RCS file: /cvs/ports/infrastructure/templates/Makefile.template,v retrieving revision 1.68 diff -u -p -r1.68 Makefile.template --- Makefile.template 2 Oct 2013 07:34:45 - 1.68 +++ Makefile.template 1 Jan 2014 23:17:42 - @@ -102,7 +102,6 @@ MASTER_SITES = ??? #SEPARATE_BUILD = Yes (build in a directory other than WRKSRC) #SEPARATE_BUILD = flavored (distinct flavors may share a common WRKSRC) #USE_GMAKE = Yes -#USE_GROFF = Yes # Programs that require GNU libtool to build instead of the OpenBSD one # should use this option. #USE_LIBTOOL= gnu
Re: Drop USE_GROFF from Makefile.template
Rafael Sadowski writes: > "Drop USE_GROFF since groff and mandoc produce identical output." > > cheers Rafael I don't think this is a good idea. Lots of ports still need USE_GROFF, and having this in the template reminds people to look at the groff and mandoc produced output. shannon ~$ sqlite3 /usr/local/share/sqlports SQLite version 3.8.0.2 OpenBSD Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> select count (1) from ports where USE_GROFF = 1; 1744 > Index: Makefile.template > === > RCS file: /cvs/ports/infrastructure/templates/Makefile.template,v > retrieving revision 1.68 > diff -u -p -r1.68 Makefile.template > --- Makefile.template 2 Oct 2013 07:34:45 - 1.68 > +++ Makefile.template 1 Jan 2014 23:17:42 - > @@ -102,7 +102,6 @@ MASTER_SITES = ??? > #SEPARATE_BUILD = Yes (build in a directory other than WRKSRC) > #SEPARATE_BUILD = flavored (distinct flavors may share a common WRKSRC) > #USE_GMAKE = Yes > -#USE_GROFF = Yes > # Programs that require GNU libtool to build instead of the OpenBSD one > # should use this option. > #USE_LIBTOOL= gnu > -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: Drop USE_GROFF from Makefile.template
On 01/01/14 6:19 PM, Rafael Sadowski wrote: "Drop USE_GROFF since groff and mandoc produce identical output." The quoted comment is without context and isn't always true yet. cheers Rafael Index: Makefile.template === RCS file: /cvs/ports/infrastructure/templates/Makefile.template,v retrieving revision 1.68 diff -u -p -r1.68 Makefile.template --- Makefile.template 2 Oct 2013 07:34:45 - 1.68 +++ Makefile.template 1 Jan 2014 23:17:42 - @@ -102,7 +102,6 @@ MASTER_SITES = ??? #SEPARATE_BUILD = Yes (build in a directory other than WRKSRC) #SEPARATE_BUILD = flavored (distinct flavors may share a common WRKSRC) #USE_GMAKE = Yes -#USE_GROFF = Yes # Programs that require GNU libtool to build instead of the OpenBSD one # should use this option. #USE_LIBTOOL= gnu -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Drop USE_GROFF from Makefile.template
Hi, Jérémie Courrèges-Anglas wrote on Thu, Jan 02, 2014 at 12:42:51AM +0100: > Rafael Sadowski writes: >> "Drop USE_GROFF since groff and mandoc produce identical output." > I don't think this is a good idea. + 1 > Lots of ports still need USE_GROFF, and having this in the template > reminds people to look at the groff and mandoc produced output. Exactly. Deciding whether a port must USE_GROFF may have become easier over time, mostly because many porters have collected experience, but it is still a non-trivial task that cannot even be fully automated, see http://www.openbsd.org/faq/ports/specialtopics.html#Mandoc for details. > shannon ~$ sqlite3 /usr/local/share/sqlports > SQLite version 3.8.0.2 OpenBSD > Enter ".help" for instructions > Enter SQL statements terminated with a ";" > sqlite> select count (1) from ports where USE_GROFF = 1; > 1744 There are probably some in there that don't strictly require USE_GROFF, but there are definitely still lots that do. What naddy@ has been doing lately is the harvesting of low-hanging fruit, removing USE_GROFF in cases where it's most definitly useless, with a strong bias of leaning towards the safe side, avoiding to touch anything by multiport commits that isn't 100% clean and safe. Yours, Ingo >> Index: Makefile.template >> === >> RCS file: /cvs/ports/infrastructure/templates/Makefile.template,v >> retrieving revision 1.68 >> diff -u -p -r1.68 Makefile.template >> --- Makefile.template 2 Oct 2013 07:34:45 - 1.68 >> +++ Makefile.template 1 Jan 2014 23:17:42 - >> @@ -102,7 +102,6 @@ MASTER_SITES = ??? >> #SEPARATE_BUILD = Yes (build in a directory other than WRKSRC) >> #SEPARATE_BUILD = flavored (distinct flavors may share a common WRKSRC) >> #USE_GMAKE = Yes >> -#USE_GROFF = Yes >> # Programs that require GNU libtool to build instead of the OpenBSD one >> # should use this option. >> #USE_LIBTOOL= gnu
Update net/tintin++ to 2.00.9
This diff was run against -current. It updates net/tintin++ to 2.00.9.
MASTER_SITES now grabs from MASTER_SITE_SOURCEFORGE.
Licensing has been changed to GPLv2.
WANTLIB has been updated to reflect pcre dependency.
Source files are modified as follows:
Makefile.in: include ${LOCALBASE}/include
parse.c: initialize ptoo (this patch submitted upstream)
Index: Makefile
===
RCS file: /cvs/ports/net/tintin++/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile10 Dec 2013 23:42:29 - 1.18
+++ Makefile2 Jan 2014 04:17:26 -
@@ -2,28 +2,29 @@
COMMENT= client program to help playing muds
-DISTNAME= tintin++v1.5pl6
-PKGNAME= tintin-1.5.6
-REVISION= 1
+DISTNAME= tintin-2.00.9
+PKGNAME= tintin-2.00.9
+REVISION= 0
CATEGORIES= net games
-MASTER_SITES= http://ftp.kiae.su/pub/unix/games/
-EXTRACT_SUFX= .tar.Z
+MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=tintin/}
-# Public Domain
+# GPLv2
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB += c
+CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
+LDFLAGS="-L${LOCALBASE}/lib"
-CONFIGURE_STYLE= gnu old
+LIB_DEPENDS= devel/pcre
-WRKDIST= ${WRKDIR}/tintin++/src
+WANTLIB += pcre
+CONFIGURE_STYLE=gnu
+
+WRKDIST= ${WRKDIR}/tt/src
NO_TEST= Yes
do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/lib/tintin
${INSTALL_PROGRAM} ${WRKSRC}/tt++ ${PREFIX}/bin
- ${INSTALL_DATA} ${WRKSRC}/support/.tt_help.txt.Z ${PREFIX}/lib/tintin
.include
Index: distinfo
===
RCS file: /cvs/ports/net/tintin++/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo5 Apr 2007 16:20:16 - 1.3
+++ distinfo2 Jan 2014 04:17:26 -
@@ -1,5 +1,2 @@
-MD5 (tintin++v1.5pl6.tar.Z) = NeU9ZhYG0DXD6SoknkQWDw==
-RMD160 (tintin++v1.5pl6.tar.Z) = iyDVrnwyTOt4Gj5eXeWKvld/Cks=
-SHA1 (tintin++v1.5pl6.tar.Z) = aybfgVFdRTk6aMoOW9FxKHu3ezQ=
-SHA256 (tintin++v1.5pl6.tar.Z) = mpU9NhEUm+g0/IEmXjwTJNhdy9r8ZsbvuEDa+o8zSi8=
-SIZE (tintin++v1.5pl6.tar.Z) = 176477
+SHA256 (tintin-2.00.9.tar.gz) = yv7um2DeOdlX3vV4L7T4yymgWvadyW0+WAfC0/tUEnU=
+SIZE (tintin-2.00.9.tar.gz) = 276024
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/net/tintin++/patches/patch-Makefile_in,v
retrieving revision 1.1
diff -u -p -r1.1 patch-Makefile_in
--- patches/patch-Makefile_in 26 Oct 2007 22:10:06 - 1.1
+++ patches/patch-Makefile_in 2 Jan 2014 04:17:26 -
@@ -1,45 +1,11 @@
-$OpenBSD: patch-Makefile_in,v 1.1 2007/10/26 22:10:06 ajacoutot Exp $
Makefile.in.orig Fri Sep 9 17:35:20 1994
-+++ Makefile.inSat Oct 27 00:05:07 2007
-@@ -10,8 +10,7 @@
- # try uncommenting the 'gcc' line and commenting the 'cc' one.
- # Tintin++ doesn't *need* an ANSI compiler anymore, but gcc
- # is still better than cc on many platforms...
--CC = @CC@ -O
--CFLAGS = @DEFS@
-+CFLAGS += @DEFS@
- LIBS = @LIBS@
- PIPE = @PIPE@
- # If you plan on doing debugging (with gdb), it is very helpful to turn all
-@@ -22,10 +21,10 @@ PIPE = @PIPE@
+--- Makefile.in.orig Wed Jan 1 19:17:57 2014
Makefile.inWed Jan 1 19:18:44 2014
+@@ -35,7 +35,7 @@
- # BINDIR is the directory you wish tt++ to be placed if you wish to use
- # make install.
--BINDIR = ..
-+BINDIR = /usr/local/bin
+ LDFLAGS = @LDFLAGS@
- # DEFAULT_FILE_DIR is the path to tintin files.
--DEFAULT_FILE_DIR = @HOME@
-+DEFAULT_FILE_DIR = /usr/local/lib/tintin
+-INCS = @MYINCLUDE@
++INCS += -I${LOCALBASE}/include @MYINCLUDE@
- #
- # You shouldn't need to change anything #
-@@ -41,14 +40,15 @@ CFILES = main.c parse.c action.c alias.c substitute.c
- variables.c highlight.c antisub.c ivars.c help.c text.c glob.c
- OFILES = $(CFILES:.c=.o)
+ LIBS = @MYLIB@ @LIBS@
--all: tintin++ install
-+all: tintin++
-
- tintin++: $(OFILES) tintin.h
- @echo "Linking..."
- $(CC) $(CFLAGS) $(FFLAGS) $(LFLAGS) -o tt++ $(OFILES) $(LIBS)
-
--install: all
-- @./install.sh $(BINDIR) $(DEFAULT_FILE_DIR) $(COMPRESSED_HELP)
-+install:
-+ @mkdir -p $(DEFAULT_FILE_DIR)
-+ @./install.sh $(BINDIR) $(DEFAULT_FILE_DIR) Ok
-
- # Autocompile all .c files into .o files using this rule:
- .c.o:
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 7 Dec 2013 22:37:14 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,69 +0,0 @@
-$OpenBSD: patch-configure,v 1.2 2013/12/07 22:37:14 jca Exp $
configure.orig Sun Aug 28 12:06:38 1994
-+++ configure Fri Dec 6 15:14:46 2013
-@@ -474,17 +474,20 @@ fi
- OLD_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS -pipe"
-
--echo "Do you want the helpfile t
Re: Update net/tintin++ to 2.00.9
On 1/1/2014 11:35 PM, Ted Roby wrote:
This diff was run against -current. It updates net/tintin++ to 2.00.9.
Any reason not to have updated to 2.01.0?
MASTER_SITES now grabs from MASTER_SITE_SOURCEFORGE.
Licensing has been changed to GPLv2.
Pedantic nit: the license is actually GPLv2+
WANTLIB has been updated to reflect pcre dependency.
Source files are modified as follows:
Makefile.in: include ${LOCALBASE}/include
parse.c: initialize ptoo (this patch submitted upstream)
Index: Makefile
===
RCS file: /cvs/ports/net/tintin++/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile10 Dec 2013 23:42:29 - 1.18
+++ Makefile2 Jan 2014 04:17:26 -
@@ -2,28 +2,29 @@
COMMENT= client program to help playing muds
-DISTNAME= tintin++v1.5pl6
-PKGNAME= tintin-1.5.6
-REVISION= 1
+DISTNAME= tintin-2.00.9
+PKGNAME= tintin-2.00.9
+REVISION= 0
CATEGORIES= net games
-MASTER_SITES= http://ftp.kiae.su/pub/unix/games/
-EXTRACT_SUFX= .tar.Z
+MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=tintin/}
-# Public Domain
+# GPLv2
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB += c
+CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
+LDFLAGS="-L${LOCALBASE}/lib"
-CONFIGURE_STYLE= gnu old
+LIB_DEPENDS= devel/pcre
-WRKDIST= ${WRKDIR}/tintin++/src
+WANTLIB += pcre
+CONFIGURE_STYLE=gnu
+
+WRKDIST= ${WRKDIR}/tt/src
NO_TEST= Yes
do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/lib/tintin
${INSTALL_PROGRAM} ${WRKSRC}/tt++ ${PREFIX}/bin
- ${INSTALL_DATA} ${WRKSRC}/support/.tt_help.txt.Z ${PREFIX}/lib/tintin
.include
Index: distinfo
===
RCS file: /cvs/ports/net/tintin++/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo5 Apr 2007 16:20:16 - 1.3
+++ distinfo2 Jan 2014 04:17:26 -
@@ -1,5 +1,2 @@
-MD5 (tintin++v1.5pl6.tar.Z) = NeU9ZhYG0DXD6SoknkQWDw==
-RMD160 (tintin++v1.5pl6.tar.Z) = iyDVrnwyTOt4Gj5eXeWKvld/Cks=
-SHA1 (tintin++v1.5pl6.tar.Z) = aybfgVFdRTk6aMoOW9FxKHu3ezQ=
-SHA256 (tintin++v1.5pl6.tar.Z) = mpU9NhEUm+g0/IEmXjwTJNhdy9r8ZsbvuEDa+o8zSi8=
-SIZE (tintin++v1.5pl6.tar.Z) = 176477
+SHA256 (tintin-2.00.9.tar.gz) = yv7um2DeOdlX3vV4L7T4yymgWvadyW0+WAfC0/tUEnU=
+SIZE (tintin-2.00.9.tar.gz) = 276024
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/net/tintin++/patches/patch-Makefile_in,v
retrieving revision 1.1
diff -u -p -r1.1 patch-Makefile_in
--- patches/patch-Makefile_in 26 Oct 2007 22:10:06 - 1.1
+++ patches/patch-Makefile_in 2 Jan 2014 04:17:26 -
@@ -1,45 +1,11 @@
-$OpenBSD: patch-Makefile_in,v 1.1 2007/10/26 22:10:06 ajacoutot Exp $
Makefile.in.orig Fri Sep 9 17:35:20 1994
-+++ Makefile.inSat Oct 27 00:05:07 2007
-@@ -10,8 +10,7 @@
- # try uncommenting the 'gcc' line and commenting the 'cc' one.
- # Tintin++ doesn't *need* an ANSI compiler anymore, but gcc
- # is still better than cc on many platforms...
--CC = @CC@ -O
--CFLAGS = @DEFS@
-+CFLAGS += @DEFS@
- LIBS = @LIBS@
- PIPE = @PIPE@
- # If you plan on doing debugging (with gdb), it is very helpful to turn all
-@@ -22,10 +21,10 @@ PIPE = @PIPE@
+--- Makefile.in.orig Wed Jan 1 19:17:57 2014
Makefile.inWed Jan 1 19:18:44 2014
+@@ -35,7 +35,7 @@
- # BINDIR is the directory you wish tt++ to be placed if you wish to use
- # make install.
--BINDIR = ..
-+BINDIR = /usr/local/bin
+ LDFLAGS = @LDFLAGS@
- # DEFAULT_FILE_DIR is the path to tintin files.
--DEFAULT_FILE_DIR = @HOME@
-+DEFAULT_FILE_DIR = /usr/local/lib/tintin
+-INCS = @MYINCLUDE@
++INCS += -I${LOCALBASE}/include @MYINCLUDE@
- #
- # You shouldn't need to change anything #
-@@ -41,14 +40,15 @@ CFILES = main.c parse.c action.c alias.c substitute.c
- variables.c highlight.c antisub.c ivars.c help.c text.c glob.c
- OFILES = $(CFILES:.c=.o)
+ LIBS = @MYLIB@ @LIBS@
--all: tintin++ install
-+all: tintin++
-
- tintin++: $(OFILES) tintin.h
- @echo "Linking..."
- $(CC) $(CFLAGS) $(FFLAGS) $(LFLAGS) -o tt++ $(OFILES) $(LIBS)
-
--install: all
-- @./install.sh $(BINDIR) $(DEFAULT_FILE_DIR) $(COMPRESSED_HELP)
-+install:
-+ @mkdir -p $(DEFAULT_FILE_DIR)
-+ @./install.sh $(BINDIR) $(DEFAULT_FILE_DIR) Ok
-
- # Autocompile all .c files into .o files using this rule:
- .c.o:
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- patches/patch-configure 7 Dec 2013 22:37:14 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,69 +0,0 @@
-$OpenBSD: patch-configure,v 1.2 2013/12/07 22:37:14 jca Exp $
configure.orig Sun Aug 28 12:06:38 1994
-+++ configure Fri Dec 6 15:14:46 201
