OWFS -- 1-Wire file system. OWFS is an easy way to use the powerful 1-wire system of Dallas/Maxim. OWFS is a simple and flexible program to monitor and control the physical environment. You can write scripts to read temperature, flash lights, write to an LCD, log and graph, ... WWW: http://www.owfs.org/ Build succesfull on at least FreeBSD 8.4, 9.2, 10.0. Not actually tested on 10.0 though. Some options are known not to build at all, those are marked BROKEN.
Attached is patch for Makefile & distinfo, to build owfs 2.9p5 instead of p4. The updated version has important fixes.
Missing pkg-plist patch for 2.9p5; make package failed.
Hi, if you are still interested in having this port in FreeBSD, it may (or may not) need to be reworked to support stage, and it may need updating to other newer conventions such as "USES" which is expanding all time. For staging, see http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/000080.html Additionally, you need to provide some sort of quality assurance. In order of preference, we are looking for: 1) "poudriere testport" or "poudriere bulk -t" logs 2) Redports or tinderbox logs 3) at least this: https://www.freebsd.org/doc/en/books/porters-handbook/porting-testing.html Please provide an updated shar file and attach a test log. Alternatively, please indicate if you are no longer interested in having this software in the Ports Collection and that we can close the PR. Thanks!
Created attachment 145621 [details] owfs 2.9p5 with stagefixes
Created attachment 145622 [details] poudriere testport logfile Port now updated with full stage support and deprecated MANX removed. Also attached is output of 'poudriere testport -n' command executed on a FreeBSD 9.2-amd64 machine. The port builds fine on FreeBSD 10.0 as well.
Note: the two patch-files shall be ignored. Seems I'm not able to remove them.
Thanks, moving to stage-ready. Next committer, note comment 6
Found an additional problem, the build failed with an updated ports tree. Seems bsd.python.mk was removed just a day or so ago. Tried to attach an updated .shar but I just keep getting Internal Server Error... The Makefile should be patched accordingly, tested on FreeBSD 9.2: --- owfs-a/Makefile 2014-08-12 09:13:00.633966176 +0200 +++ owfs-b/Makefile 2014-08-12 09:13:05.830968397 +0200 @@ -172,8 +172,7 @@ .endif .if ${PORT_OPTIONS:MOWPYTHON} -USE_PYTHON=yes -.include "${PORTSDIR}/Mk/bsd.python.mk" +USES+=python SWIG=1 CONFIGURE_ARGS+= --enable-owpython PLIST_SUB+= OWPYTHON=""
i'm the next committer. :(
since this shar is also created badly and there's a mistake in Makefile, can you generate a new shar with the correction please?
Created attachment 145815 [details] owfs 2.9p5 with stagefixes+pythonfix Updated shar with proper root & python-fix applied!
Created attachment 145822 [details] owfs 2.9p5 with stagefixes+pythonfix+cleanups Updated with further cleanups (indentation, whitespace, pkg-plist order, some dead stuff removed)
/me is trembling..
The good news: portlint is happy The bad news: You are using the old OPTIONS style. You can really shorten the makefile with : <OPTIONNAME>_CONFIGURE_WITH <OPTIONNAME>_CONFIGURE_ENABLE <OPTIONNAME>_LIB_DEPENDS <OPTIONNAME>_RUN_DEPENDS <OPTIONNAME>_USES etc read this page from top to bottom: https://www.freebsd.org/doc/en/books/porters-handbook/makefile-options.html Then I think you will see how to significantly reduce the size of the makefile. It's a lot of work so I'll leave it for you. Ask if you have any questions. ( another learning opportunity )
don't forget OPTIONS_SUB either
Yeah, enough of my beginner misstakes for you today.. ;) Thank you, will look into it and update accordingly!
Created attachment 145838 [details] owfs 2.9p5 with stagefixes+pythonfix+cleanups+new options
Created attachment 145839 [details] poudriere testport logfile There, updated the port with new-style options. Please let me know of any further improvements which can be made, I'm sure there are some.. :)
I see a bunch of similar patches like: X-__version__ = '0.0-%s' % '$Id$'.split( )[ 2 ] X+__version__ = '0.0' Surely you could add a post-patch target and used ${REINPLACE_CMD} -e '<regex>' <list of files> and change all of those without a patch. I suspect you can. Generally when you have a repetitive and simple change like this, used sed -i (which is what ${REINPLACE_CMD} is) I think you can eliminate a bunch of patches with that.
The options stuff looks a lot better, don't you think? The other thing that stands out just from looking at the shar is the amount of STRIP_CMD you have having to use. Did you check the makefile to see if it defines "install-strip" target? If it does, just add "INSTALL_TARGET=install-strip" and you can get rid of all those post-install strip targets. if not, there may be another way e.g. patching the makefile but I'd have to look
Created attachment 145846 [details] owfs 2.9p5, strip-fix
(In reply to John Marino from comment #19) > I see a bunch of similar patches like: > X-__version__ = '0.0-%s' % '$Id$'.split( )[ 2 ] > X+__version__ = '0.0' > > Surely you could add a post-patch target and used ${REINPLACE_CMD} -e > '<regex>' <list of files> and change all of those without a patch. I > suspect you can. > Generally when you have a repetitive and simple change like this, used sed > -i (which is what ${REINPLACE_CMD} is) > > I think you can eliminate a bunch of patches with that. In theory it would be cleaner, but looking closer there was actually some difference between the patches. Adding to that, escaping issues ($Id$ and " vs ' and so on..) made me give up on moving it into post-patch. Besides, this patch is temporary and is fixed in trunk, thus will be removed on next release. (In reply to John Marino from comment #20) > The options stuff looks a lot better, don't you think? Very much so :) > > The other thing that stands out just from looking at the shar is the amount > of STRIP_CMD you have having to use. > > Did you check the makefile to see if it defines "install-strip" target? If > it does, just add "INSTALL_TARGET=install-strip" and you can get rid of all > those post-install strip targets. > > if not, there may be another way e.g. patching the makefile but I'd have to > look INSTALL_TARGET=install-strip did the trick, except for the Perl and Python .so's. Those are still stripped manually in the updated shar.
(In reply to johan from comment #22) > (In reply to John Marino from comment #19) > > I see a bunch of similar patches like: > > X-__version__ = '0.0-%s' % '$Id$'.split( )[ 2 ] > > X+__version__ = '0.0' > > > In theory it would be cleaner, but looking closer there was actually some > difference between the patches. Adding to that, escaping issues ($Id$ and " > vs ' and so on..) made me give up on moving it into post-patch. > Besides, this patch is temporary and is fixed in trunk, thus will be removed > on next release. I looked again, the last 7 patches are identical. I'll try making it working, eliminating 7 patches is no small thing.
after exploring the shar, I see this is a single combined patch. Even if I leave it this way, I have to remove all that git "diff" "Index" lines, they don't belong here. Normally it's one patch per file changed, but having many patches in one file is okay, and some people think this should be the new norm (I'm not one of those though)
This line eliminates 8 patches: post-patch: ${REINPLACE_CMD} \ -e "s/^\(__version__ = '[[:digit:]]\.[[:digit:]]\).*/\1'/" \ ${WRKSRC}/module/swig/python/unittest/*.py \ ${WRKSRC}/module/ownet/python/ownet/__init__.py
Here's the full block. When the next release comes, you just remove it. Now there are no patches. # These __version__ fixes should be unnecessary on next release post-patch: @${REINPLACE_CMD} \ -e "s/^\(__version__ = '[[:digit:]]\.[[:digit:]]\).*/\1'/" \ ${WRKSRC}/module/swig/python/unittest/*.py \ ${WRKSRC}/module/ownet/python/ownet/__init__.py @${REINPLACE_CMD} -e "s/\(__version__ =\).*/\1 '1.9'/" \ ${WRKSRC}/module/ownet/python/ownet/connection.py @${REINPLACE_CMD} -e "s/\(__version__ = .*\) [+].*/\1/" \ ${WRKSRC}/module/swig/python/ow/__init__.py
(In reply to johan from comment #22) > INSTALL_TARGET=install-strip did the trick, except for the Perl and Python > .so's. Those are still stripped manually in the updated shar. I grepped for install-strip, it's not anywhere in the new shar. (??)
it builds cleanly though, I need to diff those two shars to see what changed ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for directories owned by MTREEs ===> Checking for directories handled by dependencies ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done
(In reply to John Marino from comment #28) > it builds cleanly though, I need to diff those two shars to see what changed Nothing. attachment 145838 [details] and attachment 145846 [details] are identical. Now I'm really confused.
Created attachment 145857 [details] owfs 2.9p5, patch+strip-fix (In reply to John Marino from comment #26) > Here's the full block. > When the next release comes, you just remove it. Now there are no patches. > > > > # These __version__ fixes should be unnecessary on next release > post-patch: > @${REINPLACE_CMD} \ > -e "s/^\(__version__ = '[[:digit:]]\.[[:digit:]]\).*/\1'/" \ > ${WRKSRC}/module/swig/python/unittest/*.py \ > ${WRKSRC}/module/ownet/python/ownet/__init__.py > @${REINPLACE_CMD} -e "s/\(__version__ =\).*/\1 '1.9'/" \ > ${WRKSRC}/module/ownet/python/ownet/connection.py > @${REINPLACE_CMD} -e "s/\(__version__ = .*\) [+].*/\1/" \ > ${WRKSRC}/module/swig/python/ow/__init__.py Great, thanks! (In reply to John Marino from comment #29) > (In reply to John Marino from comment #28) > > it builds cleanly though, I need to diff those two shars to see what changed > > > Nothing. attachment 145838 [details] and attachment 145846 [details] are > identical. Now I'm really confused. I guess I did a bit too much of porting yesterday as well, must have attached the old file... There, the updated one, including patch cleanup.
Alright, I see two things. 1) Your targets are split up. Post patch and pre-configure should be near the bottom. You put all the targets at the end. 2) What is the reason for <bsd.port.pre.mk> and <bsd.port.post.mk>? I don't see one. 3) That's wrong anyway because you have <bsd.port.options.mk>. Only in very rare cases do you use both. so #1 is a style thing, #2 and #3 are probably plain wrong.
Created attachment 145859 [details] owfs 2.9p5, patch+strip+postpre-fix There, cleaned up order of targets. Hm, I think pre was used before when I first loaded bsd.options.mk, then added USES+=tcl if TCL option was checked. And then I included bsd.pre.mk to obtain TCL_LIBDIR which was added to configure args. No longer required with opt_USES, cleaned up!
A commit references this bug: Author: marino Date: Sat Aug 16 09:15:19 UTC 2014 New revision: 365069 URL: http://svnweb.freebsd.org/changeset/ports/365069 Log: Add new port comms/owfs PR: 189222 Submitted by: Johan (stromnet.se) OWFS -- 1-Wire file system. OWFS is an easy way to use the powerful 1-wire system of Dallas/Maxim. OWFS is a simple and flexible program to monitor and control the physical environment. You can write scripts to read temperature, flash lights, write to an LCD, log and graph, ... Changes: head/comms/Makefile head/comms/owfs/ head/comms/owfs/Makefile head/comms/owfs/Makefile.options head/comms/owfs/distinfo head/comms/owfs/pkg-descr head/comms/owfs/pkg-plist
Ok, for the next release, I'll recommend that you move Makefile.options back into makefiles, and don't list the options one per line. Put as many on a line as you can and wrap before 80 columns Once you do that, the Makefile.options really isn't that long and it makes everything in place and more readable. Anyway, congrats, you have your port!
(In reply to John Marino from comment #34) > Ok, for the next release, I'll recommend that you move Makefile.options back > into makefiles, and don't list the options one per line. Put as many on a > line as you can and wrap before 80 columns > > Once you do that, the Makefile.options really isn't that long and it makes > everything in place and more readable. Makes sense, will do! > > Anyway, congrats, you have your port! Yay! Thanks for your efforts on this one too :)