CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 00:56:37 Modified files: misc/fileutils : Makefile misc/fileutils/patches: patch-configure patch-src_Makefile_in patch-src_dircolors_c patch-src_ls_c patch-src_ls_h patch-src_mv_c patch-src_remove_c patch-src_rm_c Log message: - regen patches, add missing rcs id's
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 01:00:01 Modified files: misc/fileutils : Makefile Log message: - it's disappearing from more and more gnu mirrors, so add another mirror
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/11/03 01:12:41 Modified files: misc/redshift : Makefile distinfo misc/redshift/pkg: PLIST Log message: Update to redshift-1.6. Use MODPY_ADJ_FILES. prodded by Remi Pointel on ports@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 01:20:50 Modified files: benchmarks/xengine: Makefile Log message: - add working master site
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 01:27:26 Modified files: devel/cppcheck : Makefile distinfo devel/cppcheck/pkg: DESCR PLIST Log message: - update cppcheck to 1.45 - improve DESCR from maintainer igor zinovik ok steven@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 01:34:51 Modified files: productivity/googlecl: Makefile Log message: it should be run dependency, not lib dependency.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2010/11/03 03:17:57 Modified files: infrastructure/db: systrace.filter Log message: permit native-ogetdirentries, ok aja
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 03:21:00 Modified files: audio/p5-Audio-MPD-Common: Makefile distinfo audio/p5-Audio-MPD-Common/pkg: PLIST Log message: - update to 1.100430
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 04:23:24 Modified files: net/ushare : Makefile net/ushare/pkg : MESSAGE PLIST Added files: net/ushare/pkg : ushare.rc Log message: - add an rc file for ushare. ok aja@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/11/03 04:55:30 Modified files: net/ushare : Makefile net/ushare/pkg : ushare.rc Log message: Missing rcs id.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/11/03 05:57:16 Modified files: mail/zarafa/zarafa: Makefile mail/zarafa/zarafa/pkg: zarafa.rc Log message: Fix rc scripts name.
Bureau Commercial De Documention Et De R, retrouvez vos photos de classe sur Trombi.com
Pour voir la version graphique.Merci de suivre ce lien : http://mailing.dni01.com/display.php?M=2856584C=4d70e11b71b68df477f4f6c04455c438S=57L=2N=16 Trombi - Retrouver vos amis d'C)cole Ecole primaire - CollC(ge - LycC)e http://mailing.dni01.com/link.php?M=2856584N=57L=51F=T Pour vous dC)sinscrire, merci d'utiliser ce lien:http://mailing.dni01.com/unsubscribe.php?M=2856584C=4d70e11b71b68df477f4f6c04455c438L=2N=57
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 10:37:47 Modified files: devel/uthash : Makefile distinfo devel/uthash/patches: patch-tests_Makefile devel/uthash/pkg: PLIST Log message: - update uthash to 1.9.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 11:30:14 Modified files: devel/fossil : Makefile distinfo devel/fossil/patches: patch-src_main_mk devel/fossil/pkg: DESCR Log message: - update fossil to 20101101142335 from james turner (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2010/11/03 12:18:51 Modified files: audio/mpd : Makefile audio/mpd/pkg : PLIST Log message: - tweak
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 13:23:05 Modified files: devel/hs-ghc-paths/pkg: PLIST Log message: @comment the LICENSE stuff, because it's the only documentation stuff in this port. I'm skipping the bump because there'll be another sweep over all hs-* ports soon.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2010/11/03 14:10:59 Modified files: net/zsync : Makefile distinfo Log message: update zsync to 0.6.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 15:32:08 Modified files: lang/ghc : Makefile ghc.port.mk Added files: lang/ghc/patches: patch-libraries_Cabal_Distribution_InstalledPackageInfo_hs patch-libraries_Cabal_Distribution_Simple_Register_hs patch-libraries_Cabal_Distribution_Simple_Setup_hs patch-libraries_bin-package-db_Distribution_InstalledPackageInfo_Binary_hs Log message: Add a `pkgpath' field to installed GHC libraries. Only applies to libraries not coming together with ghc. This allows for looking up a library's PKGPATH by running ghc-pkg field $pkgname pkgpath where $pkgname is the GHC library name without the `hs-' prefix, for example `ghc-paths'. looks good to jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:12:02 Modified files: archivers/hs-zlib: Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:12:52 Modified files: databases/hs-HDBC: Makefile databases/hs-HDBC-sqlite3: Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:13:39 Modified files: devel/cpphs: Makefile devel/haddock : Makefile devel/hs-ConfigFile: Makefile devel/hs-FindBin: Makefile devel/hs-HUnit : Makefile devel/hs-HsSyck: Makefile devel/hs-List : Makefile devel/hs-ListLike: Makefile devel/hs-MetaObject: Makefile devel/hs-MissingH: Makefile devel/hs-MonadCatchIO-transformers: Makefile devel/hs-PSQueue: Makefile devel/hs-QuickCheck: Makefile devel/hs-binary: Makefile devel/hs-cereal: Makefile devel/hs-control-timeout: Makefile devel/hs-convertible: Makefile devel/hs-dataenc: Makefile devel/hs-deepseq: Makefile devel/hs-directory-tree: Makefile devel/hs-dlist : Makefile devel/hs-fgl : Makefile devel/hs-ghc-paths: Makefile devel/hs-gio : Makefile devel/hs-glade : Makefile devel/hs-glib : Makefile devel/hs-hashed-storage: Makefile devel/hs-hlint : Makefile devel/hs-hood : Makefile devel/hs-hslogger: Makefile devel/hs-iteratee: Makefile devel/hs-language-c: Makefile devel/hs-mmap : Makefile devel/hs-monads-fd: Makefile devel/hs-murmur-hash: Makefile devel/hs-network: Makefile devel/hs-pango : Makefile devel/hs-parallel: Makefile devel/hs-parsec: Makefile devel/hs-primitive: Makefile devel/hs-pugs-DrIFT: Makefile devel/hs-pugs-compat: Makefile devel/hs-readline: Makefile devel/hs-regex-base: Makefile devel/hs-regex-compat: Makefile devel/hs-regex-pcre-builtin: Makefile devel/hs-regex-posix: Makefile devel/hs-sendfile: Makefile devel/hs-stm : Makefile devel/hs-stringtable-atom: Makefile devel/hs-tar : Makefile devel/hs-text : Makefile devel/hs-transformers: Makefile devel/hs-uniplate: Makefile devel/hs-unix-compat: Makefile devel/hs-vector: Makefile devel/hscolour : Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:16:39 Modified files: graphics/hs-GLUT: Makefile graphics/hs-OpenGL: Makefile graphics/hs-cairo: Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:17:40 Modified files: net/hs-HTTP: Makefile net/hs-network-bytestring: Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:17:15 Modified files: lang/hs-HsParrot: Makefile lang/hs-haskell-src: Makefile lang/hs-haskell-src-exts: Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:18:39 Modified files: www/hs-cgi : Makefile www/hs-html: Makefile www/hs-snap-core: Makefile www/hs-snap-server: Makefile www/hs-xhtml : Makefile www/hs-xhtml-combinators: Makefile Log message: w bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:18:16 Modified files: textproc/hs-HaXml: Makefile textproc/hs-attoparsec: Makefile textproc/hs-attoparsec-iteratee: Makefile textproc/hs-bytestring-nums: Makefile textproc/hs-bytestring-show: Makefile textproc/hs-heist: Makefile textproc/hs-hexpat: Makefile textproc/hs-xml: Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2010/11/03 16:19:02 Modified files: x11/hs-X11 : Makefile x11/hs-X11-xft : Makefile x11/hs-gtk : Makefile x11/hs-xmonad-contrib: Makefile x11/xmonad : Makefile Log message: bumpski
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2010/11/03 19:41:11 Modified files: www/nginx : Makefile distinfo www/nginx/pkg : PLIST Log message: update nginx to 0.8.53. the main flavor builds and works fine. the passenger build works, but i havent got a test case for it. ok william@
Re: [New] gnupg2
2010/11/3 Olivier Mehani sht...@ssji.net: On Tue, Jun 01, 2010 at 01:52:40PM +0200, Pierre-Emmanuel André wrote: This is a port for gnupg2 It builds and works on 4.7 GENERIC#112 amd64 after manually installing CURRENT ports for libassuan and libgpg-error. The following diff for gnupg1 is needed to permit the installation of both 1 2 at the same time. I didn't try this part. It could be fun if someone could test this port with a gnupg smartcard. Hum, I actually have a card reader that I just set up under Linux [0]. My 4.7 is on a remote machine, but I'll try to track down a spare machine and put a fresh 4.8 on it to try it all. [0] http://www.narf.ssji.net/~shtrom/wiki/tips/openpgpsmartcard It doesn't work. At least the OpenPGP SmartCard V2 I have. This card requires pcsc-lite and ccid. I've ported both and they worked. My work stopped trying to make scdaemon working: threading issues made me give up. ciao, david
Re: devel/metaauto return code
On Sun, Oct 31, 2010 at 12:33:46PM +0100, Marc Espie wrote: On Mon, Oct 25, 2010 at 11:27:25PM +0200, Tobias Ulmer wrote: Hi Marc, metaauto should IMHO return an error code instead of failing silently. We've now tested this in a bulk buil. It doesn't quite work, so it won't go in until errors in the corresponding ports are fixed... ;-( which ports are those? -- Cheers, Jasper Stay Hungry. Stay Foolish.
Re: UPDATE: graphics/gimp/stable
On 11/02/10 21:12, Stuart Henderson wrote:
This one is better but `make update-plist` replaces 2.6 with
${MODPY_VERSION}, any ideas on how to prevent this ?
You just have to be careful.
aja@ suggested this diff and it worked, we need more tests to see if it
will break something else.
Cheers
Giovanni
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.39
diff -u -p -r1.39 python.port.mk
--- python.port.mk 26 Oct 2010 14:29:26 - 1.39
+++ python.port.mk 3 Nov 2010 08:19:43 -
@@ -100,7 +100,7 @@ CONFIGURE_ENV+= PYTHON=${MODPY_BIN}
_MODPY_CMD=@cd ${WRKSRC} ${SETENV} ${MAKE_ENV} \
${MODPY_BIN} ./${MODPY_SETUP}
-SUBST_VARS:= MODPY_BIN MODPY_EGG_VERSION MODPY_VERSION ${SUBST_VARS}
+SUBST_VARS:= MODPY_BIN MODPY_EGG_VERSION ^MODPY_VERSION ${SUBST_VARS}
# set MODPY_BIN for executable scripts
MODPY_BIN_ADJ= perl -pi \
Re: UPDATE: graphics/gimp/stable
On 2010/11/03 09:21, Giovanni Bechis wrote:
On 11/02/10 21:12, Stuart Henderson wrote:
This one is better but `make update-plist` replaces 2.6 with
${MODPY_VERSION}, any ideas on how to prevent this ?
You just have to be careful.
aja@ suggested this diff and it worked, we need more tests to see if it
will break something else.
-SUBST_VARS:= MODPY_BIN MODPY_EGG_VERSION MODPY_VERSION ${SUBST_VARS}
+SUBST_VARS:= MODPY_BIN MODPY_EGG_VERSION ^MODPY_VERSION ${SUBST_VARS}
Sorry that's not going to work.
lib/python${MODPY_VERSION}/site-packages/...
- lib/python2.6/site-packages/...
systrace.filter update for ogetdirentries
Only useful for a short time until people get updated packages, but still I think we should have this. Ok? Index: systrace.filter === RCS file: /cvs/ports/infrastructure/db/systrace.filter,v retrieving revision 1.27 diff -u -p -r1.27 systrace.filter --- systrace.filter 14 Jan 2010 17:23:28 - 1.27 +++ systrace.filter 3 Nov 2010 08:24:41 - @@ -123,6 +123,7 @@ native-msync: permit native-munmap: permit native-nanosleep: permit + native-ogetdirentries: permit native-osigaltstack: permit native-pathconf: permit native-pipe: permit
Re: style rule: space around variables
On 2010/11/03 00:19, Antoine Jacoutot wrote: On Tue, 2 Nov 2010, Steven Mestdagh wrote: Marc Espie [2010-10-31, 12:26:43]: I finally made up my mind about it. Those are the rules. Don't commit new ports without proper spacing. Whenever you update ports, if you have the time, please add the spacing. I don't have a problem with this, but I notice people send in diffs which mix updates with spacing, and a simple update diff quickly becomes really long and harder to read. So I suggest we don't intermix this too much. I cannot agree more. Stop the madness please. Absolutely. I would suggest also that we don't do this port by port. If we have to do this I think the usual method of changing a category at a time is the only sane way, we really don't want hundreds of space conversion diffs for individual ports cluttering po...@. Also suggestions welcome for how to make the PERMIT_* variables not look totally awful.
Re: style rule: space around variables
On Wed, 3 Nov 2010, Stuart Henderson wrote: On 2010/11/03 00:19, Antoine Jacoutot wrote: On Tue, 2 Nov 2010, Steven Mestdagh wrote: Marc Espie [2010-10-31, 12:26:43]: I finally made up my mind about it. Those are the rules. Don't commit new ports without proper spacing. Whenever you update ports, if you have the time, please add the spacing. I don't have a problem with this, but I notice people send in diffs which mix updates with spacing, and a simple update diff quickly becomes really long and harder to read. So I suggest we don't intermix this too much. I cannot agree more. Stop the madness please. Absolutely. I would suggest also that we don't do this port by port. If we have to do this I think the usual method of changing a category at a time is the only sane way, we really don't want hundreds of space conversion diffs for individual ports cluttering po...@. I think it should be up to the people maintaining the port. This space thing is just unreadable to me. As right as it may be, it looks just wrong to my eyes and makes thel bleed... Also suggestions welcome for how to make the PERMIT_* variables not look totally awful. Oh yeah... -- Antoine
Re: [New] gnupg2
On Wed, Nov 3, 2010 at 7:31 AM, David Coppa dco...@gmail.com wrote: It doesn't work. At least the OpenPGP SmartCard V2 I have. This card requires pcsc-lite and ccid. I've ported both and they worked. My work stopped trying to make scdaemon working: threading issues made me give up. I'm sorry. I was in a hurry to catch the train and wrote a lot of crap ;) I meant to say that the reader I have, a Gemalto USB Shell Token V2, only works with pcsc-lite and ccid. The way gnupg2's scdaemon interfaces with pcsc-lite using the funky gnupg-pcsc-wrapper (scdaemon - gnupg-pcsc-wrapper - pcscd - ccid) suffers from the usual threading issues on OpenBSD and does not work at all. A card reader which is correctly recognized by gnupg internal libusb support should not have problems (maybe, didn't test it). ciao, David
Re: [New] gnupg2
On Wed, Nov 3, 2010 at 9:44 AM, David Coppa dco...@gmail.com wrote: A card reader which is correctly recognized by gnupg internal libusb support should not have problems (maybe, didn't test it). A reader like this one: http://shop.kernelconcepts.de/product_info.php?products_id=64
NEW: multimedia/oggz
Hi, Oggz comprises liboggz and the tool oggz, which provides commands to inspect, edit and validate Ogg files. The oggz-chop tool can also be used to serve time ranges of Ogg media over HTTP by any web server that supports CGI. liboggz is a C library for reading and writing Ogg files and streams. It offers various features over the reference libogg, including support for seeking, validation and timestamp interpretation. Ogg is an interleaving data container developed by Monty at Xiph.org, originally to support the Ogg Vorbis audio format but now used for many free codecs including Dirac, FLAC, Speex and Theora. comments, ok? Eric. oggz.tgz Description: application/tar-gz
FLiP 8 - Assim, escrever é fácil!
FLiP 8 http://www.flip.pt/tabid/203/Default.aspxAssim, escrever é fácil! FLiP 8 já à venda na Vobis e na Worten ou através da net no Sector Zero e na Wook Inclui o Dicionário Priberam da Língua Portuguesa Outras novidades: * Léxicos suplementares para as variedades de português de todos os países da CPLP; * Compatibilidade com o Microsoft Office 2010; * Milhares de novas palavras; * Correcção ortográfica e sintáctica melhorada; * Compatibilidade com o OpenOffice.org; * Versão melhorada do conversor para o novo Acordo Ortográfico. Compre já
Re: NEW: multimedia/oggz
new tarball, now really ignoring doxygen if it is installed. On Wed, Nov 03, 2010 at 10:32:35AM +0100, Eric Faurot wrote: Hi, Oggz comprises liboggz and the tool oggz, which provides commands to inspect, edit and validate Ogg files. The oggz-chop tool can also be used to serve time ranges of Ogg media over HTTP by any web server that supports CGI. liboggz is a C library for reading and writing Ogg files and streams. It offers various features over the reference libogg, including support for seeking, validation and timestamp interpretation. Ogg is an interleaving data container developed by Monty at Xiph.org, originally to support the Ogg Vorbis audio format but now used for many free codecs including Dirac, FLAC, Speex and Theora. comments, ok? Eric. oggz.tgz Description: application/tar-gz
SOLVED: editors/vim,gtk2 fails to package
On Tue, Nov 02, 2010 at 11:04:30AM +, Andreas Kahari wrote: On Tue, Nov 02, 2010 at 11:45:12AM +0100, Landry Breuil wrote: On Tue, Nov 02, 2010 at 10:25:45AM +, Andreas Kahari wrote: Hi, When building the athena flavor of vim, there is no problem, but when building the default gtk2 flavor (or the motif or no_x11 flavors), the packaging fails due to missing manuals: Are you really up to date wrt groff/mandoc/pkg_add/infrastructure ? Landry I believe I am up to date, but I'm rebuilding the base system now just in case. Andreas It still failed, but then I cleared out the ports that vim,gtk2 depended on (via 'make clean=all depends' and rebuilt it again. It seems to have worked. Sorry for the noise. Andreas
hunspell 1.2.12 update - need help/advice
Hi!
I really wish to have this comitted. It is an update which resolves a
segfault. However, there are some warnings when loading the hungarian
spell files, because the dictionaries in the tree are very old. I've
tried to contact Martynas regarding this, but got no reply. The warnings
are harmless, but if this is blocking this hunspell update, then please
help me resolve this issue. I'm willing to post updates for the new
hungarian ispell dictionaries, but currently this is not possible,
because the dist files are on some self-maintained mirror. How can we
update this/these packages?
ps.: attached the hunspell-1.2.12 diff
Thanks,
Daniel
--
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
On Sun, Jul 04, 2010 at 18:45:43 +0100, Edd Barrett wrote:
On Wed, Jun 30, 2010 at 3:26 PM, LEVAI Daniel l...@ecentrum.hu wrote:
Can we see this in? Is there any testing left regarding this?
Yes, there were all of those error messages! error: line 214289: bad
flagvector
Well, those are just warnings in the hunspell code, and they are only
produced with old mozilla-dicts-hu dictionaries. I've initiated contact
with martynas@, to update the hungarian dictionaries, because with the
new ones there are no more warnings with the new hunspell.
Anyway here is an update to the latest hunspell (1.2.12):
Index: Makefile
===
RCS file: /cvs/ports/textproc/hunspell/Makefile,v
retrieving revision 1.3
diff -p -u -r1.3 Makefile
--- Makefile21 Jul 2010 21:14:47 - 1.3
+++ Makefile25 Sep 2010 10:53:45 -
@@ -2,8 +2,7 @@
COMMENT = spelling, stemming, morphological analysis and generation
-DISTNAME = hunspell-1.2.8
-REVISION = 0
+DISTNAME = hunspell-1.2.12
SHARED_LIBS = hunspell-1.20.0 # .0.0
@@ -27,7 +26,7 @@ MODULES = devel/gettext
CONFIGURE_STYLE = gnu
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
- LDFLAGS=-L${LOCALBASE}/lib
+ LDFLAGS=-L${LOCALBASE}/lib
-L${WRKBUILD}/src/hunspell/.libs
CONFIGURE_ARGS = ${CONFIGURE_SHARED} \
--with-ui \
--with-readline
Index: distinfo
===
RCS file: /cvs/ports/textproc/hunspell/distinfo,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 distinfo
--- distinfo13 Jun 2009 07:48:53 - 1.1.1.1
+++ distinfo25 Sep 2010 10:53:45 -
@@ -1,5 +1,5 @@
-MD5 (hunspell-1.2.8.tar.gz) = EXevVKCeMg0sJAFfKcOpPg==
-RMD160 (hunspell-1.2.8.tar.gz) = 5P055frfltoTEfKqcWPsF+rPD4M=
-SHA1 (hunspell-1.2.8.tar.gz) = 6qdvgvzwhnjkn3owr9qiaLzHUjU=
-SHA256 (hunspell-1.2.8.tar.gz) = r1Y+E2RmIOYIBStGl04Q0Pw+TUixuZb5dxy/rG38PDg=
-SIZE (hunspell-1.2.8.tar.gz) = 784360
+MD5 (hunspell-1.2.12.tar.gz) = XvLcECZmDQ/7fq57URruIw==
+RMD160 (hunspell-1.2.12.tar.gz) = Q733wG0G6PmDt8zojnHfgzwizRM=
+SHA1 (hunspell-1.2.12.tar.gz) = Ciq0seFcPa0/BfR00a4V7jYcNfg=
+SHA256 (hunspell-1.2.12.tar.gz) = X1kqcRLfIRTOx3JXTyg3y53kmea/nTXfMnpCqz6CDmk=
+SIZE (hunspell-1.2.12.tar.gz) = 969894
Index: patches/patch-man_hu_hunspell_1
===
RCS file: /cvs/ports/textproc/hunspell/patches/patch-man_hu_hunspell_1,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 patch-man_hu_hunspell_1
--- patches/patch-man_hu_hunspell_1 13 Jun 2009 07:48:53 - 1.1.1.1
+++ patches/patch-man_hu_hunspell_1 25 Sep 2010 10:53:45 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-man_hu_hunspell_1,v 1.1.1.1 2009/06/13 07:48:53 ajacoutot Exp $
man/hu/hunspell.1.orig Mon May 26 11:42:10 2008
-+++ man/hu/hunspell.1 Fri Jun 5 20:41:01 2009
+--- man/hu/hunspell.1.orig Tue Feb 23 10:08:52 2010
man/hu/hunspell.1 Sat Sep 25 11:39:53 2010
@@ -65,12 +65,12 @@ a javaslattevĂŠst). Az elsĹ szĂłtĂĄr mindig alapszĂłt
.PP
Az alapĂŠrtelmezett szĂłtĂĄr a kĂśrnyezet nyelvi beĂĄllĂtĂĄsĂĄtĂłl fĂźgg
Index: patches/patch-man_hunspell_1
===
RCS file: /cvs/ports/textproc/hunspell/patches/patch-man_hunspell_1,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 patch-man_hunspell_1
--- patches/patch-man_hunspell_113 Jun 2009 07:48:53 - 1.1.1.1
+++ patches/patch-man_hunspell_125 Sep 2010 10:53:45 -
@@ -1,10 +1,10 @@
$OpenBSD: patch-man_hunspell_1,v 1.1.1.1 2009/06/13 07:48:53 ajacoutot Exp $
man/hunspell.1.origFri Jun 5 20:03:16 2009
-+++ man/hunspell.1 Fri Jun 5 20:04:20 2009
-@@ -360,10 +360,10 @@ Dictionary path.
- Equivalent to
- .I \-p.
- .SH FILES
+--- man/hunspell.1.origTue Feb 23 11:02:17 2010
man/hunspell.1 Sat Sep 25 11:47:18 2010
+@@ -366,10 +366,10 @@ following environment variables are searched: LC_ALL,
+ LC_MESSAGES, and LANG. If none are set then the following
+ fallbacks are used:
+
-.BI
Re: hunspell 1.2.12 update - need help/advice
On 2010/11/03 11:57, LEVAI Daniel wrote: However, there are some warnings when loading the hungarian spell files, because the dictionaries in the tree are very old. I've tried to contact Martynas regarding this, but got no reply. The warnings are harmless, but if this is blocking this hunspell update, then please help me resolve this issue. I'm willing to post updates for the new hungarian ispell dictionaries, but currently this is not possible, because the dist files are on some self-maintained mirror. How can we update this/these packages? Please post what you have for the dictionaries, there is probably someone who can mirror the distfiles. @@ -35,12 +34,12 @@ $OpenBSD: patch-src_tools_hunspell_cxx,v #define HOME getenv(HOME) #define DICBASENAME .hunspell_ #define LOGFILE /tmp/hunspell.log -@@ -1382,7 +1373,7 @@ int main(int argc, char** argv) +@@ -1430,7 +1421,7 @@ int main(int argc, char** argv) int argstate = 0; #ifdef ENABLE_NLS --#ifdef HAVE_LOCALE_H -+#if defined HAVE_LOCALE_H !defined __OpenBSD__ // native environment is C - ui_lang = setlocale(LC_ALL, ); +-# ifdef HAVE_LOCALE_H ++# if defined HAVE_LOCALE_H !defined __OpenBSD__ // native environment is C + setlocale(LC_ALL, ); textdomain(hunspell); Is this still needed/wanted?
Re: hunspell 1.2.12 update - need help/advice
On Wed, Nov 03, 2010 at 11:24:23 +, Stuart Henderson wrote:
On 2010/11/03 11:57, LEVAI Daniel wrote:
However, there are some warnings when loading the hungarian
spell files, because the dictionaries in the tree are very old. I've
tried to contact Martynas regarding this, but got no reply. The warnings
are harmless, but if this is blocking this hunspell update, then please
help me resolve this issue. I'm willing to post updates for the new
hungarian ispell dictionaries, but currently this is not possible,
because the dist files are on some self-maintained mirror. How can we
update this/these packages?
Please post what you have for the dictionaries, there is probably
someone who can mirror the distfiles.
I meant that the current port's Makefile contains some self-maintained
MASTER_SITES. Sorry, English is my second language :)
Anyway, I've attached the new port for magyarispell, which is the
Hungarian dictionary package.
@@ -35,12 +34,12 @@ $OpenBSD: patch-src_tools_hunspell_cxx,v
#define HOME getenv(HOME)
#define DICBASENAME .hunspell_
#define LOGFILE /tmp/hunspell.log
-@@ -1382,7 +1373,7 @@ int main(int argc, char** argv)
+@@ -1430,7 +1421,7 @@ int main(int argc, char** argv)
int argstate = 0;
#ifdef ENABLE_NLS
--#ifdef HAVE_LOCALE_H
-+#if defined HAVE_LOCALE_H !defined __OpenBSD__ // native environment
is C
- ui_lang = setlocale(LC_ALL, );
+-# ifdef HAVE_LOCALE_H
++# if defined HAVE_LOCALE_H !defined __OpenBSD__ // native environment
is C
+ setlocale(LC_ALL, );
textdomain(hunspell);
Is this still needed/wanted?
You're right, this is not needed. Attached the new diff for hunspell.
Thanks,
Daniel
--
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
magyarispell.tar.gz
Description: application/tar-gz
Index: Makefile
===
RCS file: /cvs/ports/textproc/hunspell/Makefile,v
retrieving revision 1.4
diff -p -u -r1.4 Makefile
--- Makefile19 Oct 2010 07:54:22 - 1.4
+++ Makefile3 Nov 2010 12:43:40 -
@@ -2,8 +2,7 @@
COMMENT = spelling, stemming, morphological analysis and generation
-DISTNAME = hunspell-1.2.8
-REVISION = 0
+DISTNAME = hunspell-1.2.12
SHARED_LIBS = hunspell-1.20.0 # .0.0
@@ -27,7 +26,7 @@ MODULES = devel/gettext
CONFIGURE_STYLE = gnu
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
- LDFLAGS=-L${LOCALBASE}/lib
+ LDFLAGS=-L${LOCALBASE}/lib
-L${WRKBUILD}/src/hunspell/.libs
CONFIGURE_ARGS = ${CONFIGURE_SHARED} \
--with-ui \
--with-readline
Index: distinfo
===
RCS file: /cvs/ports/textproc/hunspell/distinfo,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 distinfo
--- distinfo13 Jun 2009 07:48:53 - 1.1.1.1
+++ distinfo3 Nov 2010 12:43:40 -
@@ -1,5 +1,5 @@
-MD5 (hunspell-1.2.8.tar.gz) = EXevVKCeMg0sJAFfKcOpPg==
-RMD160 (hunspell-1.2.8.tar.gz) = 5P055frfltoTEfKqcWPsF+rPD4M=
-SHA1 (hunspell-1.2.8.tar.gz) = 6qdvgvzwhnjkn3owr9qiaLzHUjU=
-SHA256 (hunspell-1.2.8.tar.gz) = r1Y+E2RmIOYIBStGl04Q0Pw+TUixuZb5dxy/rG38PDg=
-SIZE (hunspell-1.2.8.tar.gz) = 784360
+MD5 (hunspell-1.2.12.tar.gz) = XvLcECZmDQ/7fq57URruIw==
+RMD160 (hunspell-1.2.12.tar.gz) = Q733wG0G6PmDt8zojnHfgzwizRM=
+SHA1 (hunspell-1.2.12.tar.gz) = Ciq0seFcPa0/BfR00a4V7jYcNfg=
+SHA256 (hunspell-1.2.12.tar.gz) = X1kqcRLfIRTOx3JXTyg3y53kmea/nTXfMnpCqz6CDmk=
+SIZE (hunspell-1.2.12.tar.gz) = 969894
Index: patches/patch-man_hu_hunspell_1
===
RCS file: /cvs/ports/textproc/hunspell/patches/patch-man_hu_hunspell_1,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 patch-man_hu_hunspell_1
--- patches/patch-man_hu_hunspell_1 13 Jun 2009 07:48:53 - 1.1.1.1
+++ patches/patch-man_hu_hunspell_1 3 Nov 2010 12:43:40 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-man_hu_hunspell_1,v 1.1.1.1 2009/06/13 07:48:53 ajacoutot Exp $
man/hu/hunspell.1.orig Mon May 26 11:42:10 2008
-+++ man/hu/hunspell.1 Fri Jun 5 20:41:01 2009
+--- man/hu/hunspell.1.orig Tue Feb 23 10:08:52 2010
man/hu/hunspell.1 Sat Sep 25 11:39:53 2010
@@ -65,12 +65,12 @@ a javaslattevĂŠst). Az elsĹ szĂłtĂĄr mindig alapszĂłt
.PP
Az alapĂŠrtelmezett szĂłtĂĄr a kĂśrnyezet nyelvi beĂĄllĂtĂĄsĂĄtĂłl fĂźgg
Index: patches/patch-man_hunspell_1
===
RCS file: /cvs/ports/textproc/hunspell/patches/patch-man_hunspell_1,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 patch-man_hunspell_1
--- patches/patch-man_hunspell_113 Jun 2009 07:48:53 - 1.1.1.1
+++ patches/patch-man_hunspell_13 Nov 2010 12:43:40 -
@@ -1,10 +1,10 @@
$OpenBSD:
Re: style rule: space around variables
On Wed, Nov 03, 2010 at 09:43:17AM +0100, Antoine Jacoutot wrote: On Wed, 3 Nov 2010, Stuart Henderson wrote: On 2010/11/03 00:19, Antoine Jacoutot wrote: On Tue, 2 Nov 2010, Steven Mestdagh wrote: Marc Espie [2010-10-31, 12:26:43]: I finally made up my mind about it. Those are the rules. Don't commit new ports without proper spacing. Whenever you update ports, if you have the time, please add the spacing. I don't have a problem with this, but I notice people send in diffs which mix updates with spacing, and a simple update diff quickly becomes really long and harder to read. So I suggest we don't intermix this too much. I cannot agree more. Stop the madness please. Absolutely. I would suggest also that we don't do this port by port. If we have to do this I think the usual method of changing a category at a time is the only sane way, we really don't want hundreds of space conversion diffs for individual ports cluttering po...@. I think it should be up to the people maintaining the port. This space thing is just unreadable to me. As right as it may be, it looks just wrong to my eyes and makes thel bleed... Fix your eyes, seriously. It's a case of habit. I used to see VAR=value as more natural. But the bad consequences made me change that habit, and now I have absolutely no problem with the new style. Like I said, it's not an aesthetic choice. We're talking trappings of Makefile semantics, and avoidance of possible problems. If I do change your ports, I will add spaces.
Re: style rule: space around variables
On Wed, 3 Nov 2010, Marc Espie wrote: Fix your eyes, seriously. It's a case of habit. I used to see VAR=value as more natural. But the bad consequences made me change that habit, and now I have absolutely no problem with the new style. Like I said, it's not an aesthetic choice. We're talking trappings of Makefile semantics, and avoidance of possible problems. Don't think that it's just me. Everyone has always been annoyed by this, it's not like I'm ranting alone in my corner. If I do change your ports, I will add spaces. Sure, while at it take maintainership. -- Antoine
Re: hunspell 1.2.12 update - need help/advice
On 2010/11/03 13:44, LEVAI Daniel wrote:
On Wed, Nov 03, 2010 at 11:24:23 +, Stuart Henderson wrote:
On 2010/11/03 11:57, LEVAI Daniel wrote:
However, there are some warnings when loading the hungarian
spell files, because the dictionaries in the tree are very old. I've
tried to contact Martynas regarding this, but got no reply. The warnings
are harmless, but if this is blocking this hunspell update, then please
help me resolve this issue. I'm willing to post updates for the new
hungarian ispell dictionaries, but currently this is not possible,
because the dist files are on some self-maintained mirror. How can we
update this/these packages?
Please post what you have for the dictionaries, there is probably
someone who can mirror the distfiles.
I meant that the current port's Makefile contains some self-maintained
MASTER_SITES. Sorry, English is my second language :)
Ah I see what you mean now. Btw your English is considerably better
than my Hungarian which is pretty much limited to koszonom and a
terrible pronunciation of megnezed a belyeggyujtemenyem so this is
fine :)
Anyway, I've attached the new port for magyarispell, which is the
Hungarian dictionary package.
missing $OpenBSD$ line at the top, but also I wonder if it makes
more sense to work it into the mozilla-dicts package.. Martynas are
you around? what do you think?
Index: Makefile
===
RCS file: /cvs/ports/textproc/mozilla-dicts/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile11 Oct 2010 08:18:29 - 1.13
+++ Makefile3 Nov 2010 14:56:04 -
@@ -9,6 +9,7 @@ V= 1.2
NAME= mozilla-dicts
PKGNAME= ${NAME}-${V}
REVISION= 0
+REVISION-hu= 1
CATEGORIES=textproc
@@ -23,10 +24,11 @@ PERMIT_DISTFILES_CDROM= Yes
PERMIT_DISTFILES_FTP= Yes
MASTER_SITES= http://openbsddistfiles.com/martynas/mozilla/dicts/${V}/
+MASTER_SITES0= ${MASTER_SITE_SOURCEFORGE:=magyarispell/}
LANGUAGES= af ar be bg ca cs cy-GB da de-AT de-CH de-DE el-EN \
el en-AU en-CA en-GB en-ZA eo es-AR es-ES et eu fr \
- fy-NL ga-IE gl he hr hsb hu id is it ku la lt lv \
+ fy-NL ga-IE gl he hr hsb id is it ku la lt lv \
nb-NO nl nn-NO pl pt-BR pt-PT ro ru sk sl sq sr \
sv-SE uk
@@ -46,11 +48,17 @@ PKGNAME-$i= ${NAME}-$i-${V}
COMMENT-$i=$i dictionary for Mozilla
.endfor
+MULTI_PACKAGES+=-hu
+PKGNAME-hu=${NAME}-hu-${V}
+COMMENT-hu=hu dictionary for Mozilla
+DISTFILES+=hu_HU-1.6.1.tar.gz:0
+
do-extract:
.for i in ${LANGUAGES}
@${UNZIP} -oq ${FULLDISTDIR}/$i.xpi -d ${WRKDIR} \*.aff
@${UNZIP} -oq ${FULLDISTDIR}/$i.xpi -d ${WRKDIR} \*.dic
.endfor
+ @gzip -dc ${FULLDISTDIR}/hu_HU-1.6.1.tar.gz | tar xf - -C ${WRKDIR}
do-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/mozilla-dicts
@@ -58,5 +66,9 @@ do-install:
${PREFIX}/share/mozilla-dicts/
${INSTALL_DATA} ${WRKDIR}/dictionaries/*.dic \
${PREFIX}/share/mozilla-dicts/
+ ${INSTALL_DATA} ${WRKDIR}/hu_HU-*/hu_HU.aff \
+ ${PREFIX}/share/mozilla-dicts/hu-HU.aff
+ ${INSTALL_DATA} ${WRKDIR}/hu_HU-*/hu_HU.dic \
+ ${PREFIX}/share/mozilla-dicts/hu-HU.dic
.include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/textproc/mozilla-dicts/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo25 Sep 2008 21:13:48 - 1.2
+++ distinfo3 Nov 2010 14:56:04 -
@@ -27,7 +27,7 @@ MD5 (mozilla-dicts-1.2/gl.xpi) = HEl/aS4
MD5 (mozilla-dicts-1.2/he.xpi) = e2scDma1md+mW1uqfON8eg==
MD5 (mozilla-dicts-1.2/hr.xpi) = 348exwLm6P8yjVJR0p4+iA==
MD5 (mozilla-dicts-1.2/hsb.xpi) = SizcG91uLhLZ5OEiyfnMhA==
-MD5 (mozilla-dicts-1.2/hu.xpi) = nwMvanovTPUlxcmWwvlcJQ==
+MD5 (mozilla-dicts-1.2/hu_HU-1.6.1.tar.gz) = AShndeNo4Tpdxvg5d/8Ylw==
MD5 (mozilla-dicts-1.2/id.xpi) = XKazg+x6SU/WxckBiz4zAw==
MD5 (mozilla-dicts-1.2/is.xpi) = 87QACsTqB+Ss7AcPgsJAWw==
MD5 (mozilla-dicts-1.2/it.xpi) = yQkz7FSoW7d2Z/9PaaMtyA==
@@ -78,7 +78,7 @@ RMD160 (mozilla-dicts-1.2/gl.xpi) = bLhH
RMD160 (mozilla-dicts-1.2/he.xpi) = eBZlQ+oA2zBUHyyUDIE+OctDlU8=
RMD160 (mozilla-dicts-1.2/hr.xpi) = ASzh4kPtJbf+T/RRVz4d5B1pZVU=
RMD160 (mozilla-dicts-1.2/hsb.xpi) = olMU6cMWu4WTgH4O+g72Qr5jEBk=
-RMD160 (mozilla-dicts-1.2/hu.xpi) = OZ3xeNK+eaKNzqXbEa4BCR50J+M=
+RMD160 (mozilla-dicts-1.2/hu_HU-1.6.1.tar.gz) = rTcQemLNZXSF10VgNV/DFfyD3fo=
RMD160 (mozilla-dicts-1.2/id.xpi) = ZzhJK4NmPMRrlG7K1Cg0rXAV3B0=
RMD160 (mozilla-dicts-1.2/is.xpi) = 2pQ22BNUR1iPdqMxr2mBUlrfw7s=
RMD160 (mozilla-dicts-1.2/it.xpi) = 1t0zYnQqpQ/R4I9+zaI6gUgxTZw=
@@ -129,7 +129,7 @@ SHA1 (mozilla-dicts-1.2/gl.xpi) = 4RuFih
SHA1 (mozilla-dicts-1.2/he.xpi) = urnf9Mo8de/GBuGmtW4wNaexlDE=
SHA1 (mozilla-dicts-1.2/hr.xpi) =
Re: x11/kde4/webdev ruby conditional depend issue
Well, the issue is that they're only part of the install if ruby is detected as installed on the host system. I suppose the better solution would be just to patch the HAVE_RUBY check out, since they are not actually generated by ruby, but you can't really do much with them if ruby is not installed. I think I'll report this upstream. Requiring the entirety of ruby for two simple scripts seems a bit much imho. You can just install them manually in a post-install target. Make sure any #! paths are patched with MODRUBY_RUBY_ADJ and I agree with Joachim, it doesn't make much sense to depend on Ruby for these, so you probably want some MODRUBY_BUILDDEP/RUNDEP=No. I sent a patch upstream asking them to remove the dep on ruby for two simple scripts. I'll see what they say. I'm not sure who would be the best person to reach out to. ports@ is probably the best place. All right. I need to sort everything I have together, then I'll send out an email regarding that. Right now I've gotten everything under x11/kde4 to compile, but I need to check on lib deps and other Makefile issues, which is the harder part for me. - Onteria
Re: [UPDATE] polipo patch rcscript
Hi, On Tue, Nov 02, 2010 at 12:05:40AM +0100, Jiri B. wrote: - patch-config.sample to be more clear that it is dir in /var/log But it isn't a directory, it's just a plain file /var/log/polipo. Or am I missing something? - rcscript - removing MESSAGE, I think it's useless with rcscript Those two are fine. I'll also bump REVISION before committing it. Ciao, Kili
Re: style rule: space around variables
On Wed, Nov 03, 2010 at 02:50:59PM +0100, Antoine Jacoutot wrote: On Wed, 3 Nov 2010, Marc Espie wrote: Fix your eyes, seriously. It's a case of habit. I used to see VAR=value as more natural. But the bad consequences made me change that habit, and now I have absolutely no problem with the new style. Like I said, it's not an aesthetic choice. We're talking trappings of Makefile semantics, and avoidance of possible problems. Don't think that it's just me. Everyone has always been annoyed by this, it's not like I'm ranting alone in my corner. As expressed before, I concur. It's annoying. I understand the need for spaces with 'X=' (replace X with ! or whatever), but not for regular '='. -- Cheers, Jasper Stay Hungry. Stay Foolish.
Re: [UPDATE] polipo patch rcscript
On Wed, Nov 03, 2010 at 06:02:21PM +0100, Matthias Kilian wrote:
- rcscript
- removing MESSAGE, I think it's useless with rcscript
Those two are fine. I'll also bump REVISION before committing it.
Actually, they were *not* fine:
- polipo exits on SIGHUP, so let rc_reload() just call rc_cmd restart
- reset the permissions of ${RCDIR}/polipo in the PLIST.
Index: Makefile
===
RCS file: /cvs/ports/www/polipo/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile26 Oct 2010 15:29:24 - 1.9
+++ Makefile3 Nov 2010 17:32:56 -
@@ -4,7 +4,7 @@ COMMENT=HTTP caching proxy
DISTNAME= polipo-1.0.4.1
CATEGORIES=www
-REVISION= 0
+REVISION= 1
HOMEPAGE= http://www.pps.jussieu.fr/~jch/software/polipo/
Index: pkg/MESSAGE
===
RCS file: pkg/MESSAGE
diff -N pkg/MESSAGE
--- pkg/MESSAGE 6 Aug 2005 21:21:53 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-When run as the root user, the polipo daemon will drop privileges to
-that of the _polipo user and its login group.
-
-Some sample configuration files have been installed in
-${SYSCONFDIR}/polipo.
-
-Additionally, you may wish to start polipo at system start-up time via
-the /etc/rc.local script.
-
-if [ X${polipo} == XYES -a -x ${PREFIX}/bin/polipo ]; then
-echo -n ' polipo'
-${PREFIX}/bin/polipo daemonise=yes
-fi
-
-and adding polipo=YES to /etc/rc.conf.local
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/polipo/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 3 Feb 2008 15:06:48 - 1.3
+++ pkg/PLIST 3 Nov 2010 17:32:56 -
@@ -1,7 +1,7 @@
@comment $OpenBSD: PLIST,v 1.3 2008/02/03 15:06:48 kili Exp $
@newgroup _polipo:548
@newuser _polipo:548:_polipo:daemon:Polipo Account:/nonexistent:/sbin/nologin
-bin/polipo
+...@bin bin/polipo
@info info/polipo.info
@man man/man1/polipo.1
share/doc/polipo/
@@ -88,3 +88,7 @@ share/examples/polipo/forbidden.sample
@sample /var/polipo/
@sample /var/polipo/cache/
@extraunexec rm -rf /var/polipo/*
+...@mode
+...@owner
+...@group
+...@rcscript ${RCDIR}/polipo
Index: pkg/polipo.rc
===
RCS file: pkg/polipo.rc
diff -N pkg/polipo.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/polipo.rc 3 Nov 2010 17:32:56 -
@@ -0,0 +1,14 @@
+#!/bin/sh
+#
+# $OpenBSD$
+
+. /etc/rc.d/rc.subr
+
+daemon=/usr/local/bin/polipo
+daemon_flags=daemonise=yes
+
+rc_reload() {
+ rc_cmd restart
+}
+
+rc_cmd $1
Re: style rule: space around variables
On Wed, Nov 03, 2010 at 06:33:01PM +0100, Jasper Lievisse Adriaanse wrote: On Wed, Nov 03, 2010 at 02:50:59PM +0100, Antoine Jacoutot wrote: On Wed, 3 Nov 2010, Marc Espie wrote: Fix your eyes, seriously. It's a case of habit. I used to see VAR=value as more natural. But the bad consequences made me change that habit, and now I have absolutely no problem with the new style. Like I said, it's not an aesthetic choice. We're talking trappings of Makefile semantics, and avoidance of possible problems. Don't think that it's just me. Everyone has always been annoyed by this, it's not like I'm ranting alone in my corner. As expressed before, I concur. It's annoying. I understand the need for spaces with 'X=' (replace X with ! or whatever), but not for regular '='. FWIW, I like the spaces around '='. f.-
Re: [UPDATE] polipo patch rcscript
On Wed, Nov 03, 2010 at 06:35:22PM +0100, Matthias Kilian wrote:
- polipo exits on SIGHUP, so let rc_reload() just call rc_cmd restart
[...]
+rc_reload() {
+ rc_cmd restart
+}
ajacoutot@ pointed out that this is wrong. rc_reload() should just error
out in this case.
Index: Makefile
===
RCS file: /cvs/ports/www/polipo/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile26 Oct 2010 15:29:24 - 1.9
+++ Makefile3 Nov 2010 18:55:46 -
@@ -4,7 +4,7 @@ COMMENT=HTTP caching proxy
DISTNAME= polipo-1.0.4.1
CATEGORIES=www
-REVISION= 0
+REVISION= 1
HOMEPAGE= http://www.pps.jussieu.fr/~jch/software/polipo/
Index: pkg/MESSAGE
===
RCS file: pkg/MESSAGE
diff -N pkg/MESSAGE
--- pkg/MESSAGE 6 Aug 2005 21:21:53 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-When run as the root user, the polipo daemon will drop privileges to
-that of the _polipo user and its login group.
-
-Some sample configuration files have been installed in
-${SYSCONFDIR}/polipo.
-
-Additionally, you may wish to start polipo at system start-up time via
-the /etc/rc.local script.
-
-if [ X${polipo} == XYES -a -x ${PREFIX}/bin/polipo ]; then
-echo -n ' polipo'
-${PREFIX}/bin/polipo daemonise=yes
-fi
-
-and adding polipo=YES to /etc/rc.conf.local
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/polipo/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- pkg/PLIST 3 Feb 2008 15:06:48 - 1.3
+++ pkg/PLIST 3 Nov 2010 18:55:46 -
@@ -1,7 +1,7 @@
@comment $OpenBSD: PLIST,v 1.3 2008/02/03 15:06:48 kili Exp $
@newgroup _polipo:548
@newuser _polipo:548:_polipo:daemon:Polipo Account:/nonexistent:/sbin/nologin
-bin/polipo
+...@bin bin/polipo
@info info/polipo.info
@man man/man1/polipo.1
share/doc/polipo/
@@ -88,3 +88,7 @@ share/examples/polipo/forbidden.sample
@sample /var/polipo/
@sample /var/polipo/cache/
@extraunexec rm -rf /var/polipo/*
+...@mode
+...@owner
+...@group
+...@rcscript ${RCDIR}/polipo
Index: pkg/polipo.rc
===
RCS file: pkg/polipo.rc
diff -N pkg/polipo.rc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pkg/polipo.rc 3 Nov 2010 18:55:46 -
@@ -0,0 +1,14 @@
+#!/bin/sh
+#
+# $OpenBSD$
+
+. /etc/rc.d/rc.subr
+
+daemon=/usr/local/bin/polipo
+daemon_flags=daemonise=yes
+
+rc_reload() {
+ rc_err $0: reload is not supported
+}
+
+rc_cmd $1
Makefile format/best practices
I'm currently working on some of the kde4 Makefiles, and I'm running into a few confusing parts. First off regarding SHARED_LIBS. I have some unversioned .so files that are installed (ie. libname.so versus libname.so.2.0, not symlinked. Some are plugins, and I'm not sure if we handle those differently. I suppose one solution would be to rename them to have version info and make the nonversioned name simply symlink to that. Next is some confusion regarding WANTLIB and LIB_DEPENDS. According to this thread: http://marc.info/?l=openbsd-techm=127807849026376w=2 it seems that WANTLIB is to declare all the libraries (shared only?) that are required by the package, while LIB_DEPENDS is to indicate the actual ports that provide the required libs (save those in userland layout, such as libc, Xorg libs, etc.). If so, I notice that LIB_DEPENDS let you indicate required libraries from the package as well. Is this only used when library versions need to be taken into account (I didn't see a way to indicate that with WANTLIB)? Finally, how does conditional requirements work? Say there are two packages that provide libfoo, and conflict with each other. However, a package that depends on libfoo can use either version. Is there a way to handle marking this sort of conditional dep? If any of this is covered in a man page or webpage somewhere that I missed, simply point me to it and I'll figure it out on my own. I've already looked over the porting pages on openbsd.org, and the man page for bsd.port.mk. Hopefully I didn't miss something completely obvious. Thanks ahead of time for all responses and keep up the good work! - Onteria
Re: hunspell 1.2.12 update - need help/advice
On sze, nov 03, 2010 at 14:56:47 +, Stuart Henderson wrote: On 2010/11/03 13:44, LEVAI Daniel wrote: [...] I meant that the current port's Makefile contains some self-maintained MASTER_SITES. Sorry, English is my second language :) Ah I see what you mean now. Btw your English is considerably better than my Hungarian which is pretty much limited to koszonom and a terrible pronunciation of megnezed a belyeggyujtemenyem so this is fine :) Oh, yeah. That latter phrase works well with ladies here... :) (no, not really :). I suspect maybe you've picked that up at some ports hackathon in Budapest? Anyway, I've attached the new port for magyarispell, which is the Hungarian dictionary package. missing $OpenBSD$ line at the top, but also I wonder if it makes more sense to work it into the mozilla-dicts package.. Martynas are you around? what do you think? [...] If you're going down that road, could you please keep the hu - hu_HU symlinks? Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Makefile format/best practices
On 2010/11/03 12:11, onteria wrote: First off regarding SHARED_LIBS. I have some unversioned .so files that are installed (ie. libname.so versus libname.so.2.0, not symlinked. Some are plugins, and I'm not sure if we handle those differently. I suppose one solution would be to rename them to have version info and make the nonversioned name simply symlink to that. dlopen()'d plugins are generally unversioned. it seems that WANTLIB is to declare all the libraries (shared only?) that are required by the package, while LIB_DEPENDS is to indicate the actual ports that provide the required libs (save those in userland layout, such as libc, Xorg libs, etc.). If so, I notice that LIB_DEPENDS let you indicate required libraries from the package as well. that is legacy usage. for anything new, LIB_DEPENDS should just have (optionally) packages-specs(5) and (always) the package path. Finally, how does conditional requirements work? Say there are two packages that provide libfoo, and conflict with each other. However, a package that depends on libfoo can use either version. Is there a way to handle marking this sort of conditional dep? see packages-specs(5). in this case the package path specifies the default to be installed if nothing matching the packages-specs was already installed at build time. also note well: if port A depends on port B, and if port C depends on port D, and ports B and D conflict, then there will be failures in bulk builds. (the actual failing packages will be unpredictable because it depends on the build order, and how many machines were used in the build).
Re: style rule: space around variables
On Wed, Nov 03, 2010 at 06:33:01PM +0100, Jasper Lievisse Adriaanse wrote: On Wed, Nov 03, 2010 at 02:50:59PM +0100, Antoine Jacoutot wrote: On Wed, 3 Nov 2010, Marc Espie wrote: Fix your eyes, seriously. It's a case of habit. I used to see VAR=value as more natural. But the bad consequences made me change that habit, and now I have absolutely no problem with the new style. Like I said, it's not an aesthetic choice. We're talking trappings of Makefile semantics, and avoidance of possible problems. Don't think that it's just me. Everyone has always been annoyed by this, it's not like I'm ranting alone in my corner. As expressed before, I concur. It's annoying. I understand the need for spaces with 'X=' (replace X with ! or whatever), but not for regular '='. So, speaking of eye cancer, what's better: FUBAR= a ZOMG += d BAR ?= b ZOOOM= c or FUBAR = a ZOMG += d BAR ?= b ZOOOM = c to me, definitely the latter. space before sign, tab after, what's wrong with that ? Landry
Re: [UPDATE] polipo patch rcscript
On Wed, Nov 03, 2010 at 08:00:26PM +0100, Matthias Kilian wrote: ajacoutot@ pointed out that this is wrong. rc_reload() should just error out in this case. Even I did mess I thank you to do it correctly. Anyway, wouldn't be nice to have a possibility to override signal for pkill or to extend list for action (ie. slow-stop)? But it would make rc.d system probably to complicated. For example: - polipo (reload-forbids) - tor (slow-stop) jirib
[NEW] chntpw-100627
Hello, works for me (i386), resetted my mothers password :) jirib chntpw is a Linux utility to (re)set the password of any user that has a valid (local) account on your WinNT or Win2000 system, by modifying the crypted password in the registry's SAM file. You do not need to know the old password to set a new one. chntpw.tar.gz Description: application/tar-gz
[NEW] detox-1.2.0
Hi, works for me on i386. !77 ji...@t400(ttyp5) $ detox -nv 2005-12\ -\ Building\ Online\ Communities\ With\ Drupal,\ phpBB,\ And\ WordPress.pdf Scanning: 2005-12 - Building Online Communities With Drupal, phpBB, And WordPress.pdf 2005-12 - Building Online Communities With Drupal, phpBB, And WordPress.pdf - 2005-12-Building_Online_Communities_With_Drupal,_phpBB,_And_WordPress.pdf (00:07:22) [/tmp] !78 ji...@t400(ttyp5) $ detox -v 2005-12\ -\ Building\ Online\ Communities\ With\ Drupal,\ phpBB,\ And\ WordPress.pdf Scanning: 2005-12 - Building Online Communities With Drupal, phpBB, And WordPress.pdf 2005-12 - Building Online Communities With Drupal, phpBB, And WordPress.pdf - 2005-12-Building_Online_Communities_With_Drupal,_phpBB,_And_WordPress.pdf (00:07:32) [/tmp] !79 ji...@t400(ttyp5) $ ls -l 2005-12-Building_Online_Communities_With_Drupal,_phpBB,_And_WordPress.pdf -rw-r--r-- 1 jirib wheel 15028818 Nov 4 00:07 2005-12-Building_Online_Communities_With_Drupal,_phpBB,_And_WordPress.pdf detox is a program that renames files to make them easier to work with under Unix and related operating systems. Spaces and various other unsafe characters (such as $) get replaced with _. ISO 8859-1 (Latin-1) characters can be replaced as well, as can UTF-8 characters. More details are contained in the detox.1 man page. jirib detox.tar.gz Description: application/tar-gz
Re: style rule: space around variables
On Wednesday 03 November 2010 09:50:59 Antoine Jacoutot wrote: Don't think that it's just me. Everyone has always been annoyed by this, it's not like I'm ranting alone in my corner. Far from it. The people who like this are the exception. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: style rule: space around variables
On Wed, Nov 03, 2010 at 06:28:47PM +, Federico G. Schwindt wrote: On Wed, Nov 03, 2010 at 06:33:01PM +0100, Jasper Lievisse Adriaanse wrote: On Wed, Nov 03, 2010 at 02:50:59PM +0100, Antoine Jacoutot wrote: On Wed, 3 Nov 2010, Marc Espie wrote: Fix your eyes, seriously. It's a case of habit. I used to see VAR=value as more natural. But the bad consequences made me change that habit, and now I have absolutely no problem with the new style. Like I said, it's not an aesthetic choice. We're talking trappings of Makefile semantics, and avoidance of possible problems. Don't think that it's just me. Everyone has always been annoyed by this, it's not like I'm ranting alone in my corner. As expressed before, I concur. It's annoying. I understand the need for spaces with 'X=' (replace X with ! or whatever), but not for regular '='. FWIW, I like the spaces around '='. me too f.- -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: style rule: space around variables
On Wed, Nov 3, 2010 at 4:38 PM, Brad b...@comstyle.com wrote: On Wednesday 03 November 2010 09:50:59 Antoine Jacoutot wrote: Don't think that it's just me. Everyone has always been annoyed by this, it's not like I'm ranting alone in my corner. Far from it. The people who like this are the exception. I'm shocked that this is such a big deal. At first I thought I didn't understand what you guys were bitc^Wcomplaining about until I saw Landry's example. srsly...
Re: style rule: space around variables
On Wed, Nov 03, 2010 at 06:33:01PM +0100, Jasper Lievisse Adriaanse wrote: As expressed before, I concur. It's annoying. I understand the need for spaces with 'X=' (replace X with ! or whatever), but not for regular '='. So then you have to think when you really need the space, or worse, wait until you run into trouble to add the space. Geezzz, what part of what I wrote did you not get ?
[NEW] openconnect
Hi, works for me for long time being connected to my employer network (on i386). Maybe vpnc script can be little more tuned. Not sure if I did stuff in PLIST correctly (@sample). As I do not use GNOME I haven't even tried to do anything with its network-manager hooks. jirib OpenConnect is a client for Cisco's AnyConnect SSL VPN, which is supported by the ASA5500 Series, by IOS 12.4(9)T or later on Cisco SR500, 870, 880, 1800, 2800, 3800, 7200 Series and Cisco 7301 Routers, and probably others. OpenConnect is released under the GNU Lesser Public License, version 2.1. Like vpnc, OpenConnect is not officially supported by, or associated in any way with, Cisco Systems. It just happens to interoperate with their equipment. Development of OpenConnect was started after a trial of their official client under Linux found it to have many deficiencies: * Inability to use SSL certificates from a TPM, or even use a passphrase. * Lack of support for Linux platforms other than i386. * Lack of integration with NetworkManager on the Linux desktop. * Lack of proper (RPM/DEB) packaging for Linux distributions. * Stealth use of libraries with dlopen(), even using the development-only symlinks such as libz.so - making it hard to properly discover the dependencies which proper packaging would have expressed * Tempfile races allowing unprivileged users to trick it into overwriting arbitrary files, as root. * Unable to run as an unprivileged user, which would have reduced severity of the above bug. * Inability to audit the source code for further such Security 101 bugs. Naturally, OpenConnect addresses all of the above issues, and more. openconnect.tar.gz Description: application/tar-gz
sslh port
Hi All, I've been using this tool for some time now, and I've been wanting to make a port of it to OpenBSD. Want to know if anyone is currently working on a port of it and, if not, what you guys think of it. My regards, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD 4.5 Ubuntu 9.04 Jaunty Jackalope 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
Re: sslh port
On Wed, Nov 3, 2010 at 9:39 PM, Giancarlo Razzolini grazzol...@gmail.com wrote: Hi All, I've been using this tool for some time now, and I've been wanting to make a port of it to OpenBSD. Want to know if anyone is currently working on a port of it and, if not, what you guys think of it. My regards, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD 4.5 Ubuntu 9.04 Jaunty Jackalope 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 I don't know about that tool... could you send the homepage of that? or a description...
Re: sslh port
http://www.rutschle.net/tech/sslh.shtml It looks very interesting. -r
Re: sslh port
On Wed, Nov 3, 2010 at 10:14 PM, Roger rno...@gmail.com wrote: http://www.rutschle.net/tech/sslh.shtml It looks very interesting. -r Oh, useful on that dumb universities that prevent ssh access trough port 22...
