Created attachment 146508 [details] new port shar file Seahub is the web frontend for seafile-server.
Created attachment 146509 [details] test port log
Created attachment 146510 [details] new port shar file
Created attachment 146795 [details] new port shar file - updated from 3.0.4 to 3.1.5, which is latest version. - the installation does not rely on the manually download/install python modules. These modules are part of run dependencies.
Thanks for the submission. - Some scripts seem to use bash, but I can't find shells/bash as RUN_DEPENDS - The indentation is quite off and it would be nice, if you can get the blocks aligned properly - The descriptions for the option knobs do not fit into the typical FreeBSD specific scheme. Please skip "option" in the description and make it more descriptive. - Please check your port with portlint -AC and try to get the warnings fixed, where possible.
Please update this patch according to review feedback in bug 193132 and bug 193133 Additionally, * COMMENT begins with indefinite article ("Seahub is the") * GH_PROJECT unnecessary * SEAFOBJ_DESC / SEAFDAV_DESC descriptions needs improvement and clarity * Use USES=shebangfix instead of post-patch: REINPLACE_CMD
Created attachment 146901 [details] updated shar file - correct offset of alignment - add bash as rundeps - correct comment, GH_PROJECT - add some extended option desc - adopt USES=shebangfix - not install some interim files
Created attachment 146902 [details] diff to new shar
Created attachment 146903 [details] portlint -AC output
Please include a completely new shar or a full SVN diff (preferred) instead of a diff to the previous attachment Thanks also for your prompt updates
Ignore my comment 9, however: * GH_PROJECT is unnecessary * Were you planning on using git tags rather than git commit hashes for GH_TAGNAME? these are preferred when they exist in the repository.
(In reply to Kubilay Kocak from comment #10) > Ignore my comment 9, however: > > * GH_PROJECT is unnecessary - will fixed it soon. > * Were you planning on using git tags rather than git commit hashes for > GH_TAGNAME? these are preferred when they exist in the repository. - I am trying, but ... When I set GH_TAGNAME= vx.x.x GH_COMMIT= ${GH_TAGNAME} I got two directories under work. One is with tag name, the other with commit number. But they don't carry same data files... WRKSRC does set with TAGNAME one, but it seems root@freebsd93:/usr/ports/www/seahub # make ===> Missing license file for APACHE20 in /usr/ports/www/seahub/work/haiwen-seahub-v3.1.5-server-testing/LICENSE.txt *** [/usr/ports/www/seahub/work/.license_done.seahub._usr_local] Error code 1 Stop in /usr/ports/www/seahub. *** [stage] Error code 1 Stop in /usr/ports/www/seahub. root@freebsd93:/usr/ports/www/seahub/work # tree -L 2 . |-- haiwen-seahub-800774b | |-- CONTRIBUTORS | |-- HACKING | |-- LICENSE.txt | |-- README.markdown | |-- code-check.sh | |-- compilemessages.sh | |-- i18n.sh | |-- locale | |-- makemessages.sh.template | |-- manage.py | |-- media | |-- pylintrc | |-- pylintrc.template | |-- run-fts.sh | |-- run-seahub.sh.template | |-- seahub | |-- send_user_notifications.sh.template | |-- setenv.sh.template | |-- sql | |-- subdomain | |-- test-seahub.sh.template | |-- thirdpart | `-- tools `-- haiwen-seahub-v3.1.5-server-testing `-- runtime 10 directories, 16 files Any suggestion? If I set TAGNAME, not COMMIT, I can not have correct directory name ...
Both are needed, in this case: GH_TAGNAME= v${PORTNAME}-server-testing GH_COMMIT= 800774b More details on how they work can be seen in Mk/bsd.sites.mk
Created attachment 146938 [details] updated shar file shar file, remove the GH_PROJECT and adopt GH_TAGNAME changes,
Created attachment 146943 [details] diff to last shar fixed a small typo
Created attachment 146944 [details] updated shar file fixed a small typo.
Created attachment 147039 [details] updated shar file correct typo in descr file.
Created attachment 147066 [details] updated shar file According to the seafile project branch convention, using non-test tag release, also remove two test purposes dependencies.
I'm sorry nobody has looked at this for, well, 2 months. It looks ok to me except for this: Xdo-install: X @${ECHO_MSG} ">>> Installing scripts..." X @${MKDIR} -m 0755 ${STAGEDIR}${HAIWENDIR}seafile-server/runtime/ X @${INSTALL} -m 0755 ${WRKSRC}/runtime/seahub.conf \ X ${STAGEDIR}${HAIWENDIR}seafile-server/runtime/ X @${MKDIR} -m 0755 ${STAGEDIR}${SEAHUBDIR} X @cd ${WRKSRC} && ${COPYTREE_SHARE} . ${STAGEDIR}${SEAHUBDIR} X @${FIND} ${STAGEDIR}${SEAHUBDIR} -name "*.bak" -exec ${RM} {} \; X @${FIND} ${STAGEDIR}${SEAHUBDIR} -name "*.orig" -exec ${RM} {} \; The "@" suppresses the command. We only allow "@" suppression on mkdir commands in the install and post-install targets. Plus, while not technically wrong, I don't really like seeing post-extra and post-patch. Can you move the contents of post-extract to post-patch target? Especially since it gives us the opportunity to patch the .conf file if we need to?
This can't be patch-ready if PRs that block it aren't patch-ready (or committed) themselves. Plus this needs changing, moving to "open"
Created attachment 149113 [details] portlint -AC output
Created attachment 149114 [details] updated shar file
Created attachment 149116 [details] updated shar file - not use dirrmtry anymore - correct "=" usage - correct @ usage - delete post-extract, and move it post-patch
(In reply to John Marino from comment #19) > This can't be patch-ready if PRs that block it aren't patch-ready (or > committed) themselves. Plus this needs changing, moving to "open" It has been for a while that there is no review for 193134 193313 193315 193316 Best, Jingfeng
(In reply to Jingfeng Yan from comment #23) > (In reply to John Marino from comment #19) > > This can't be patch-ready if PRs that block it aren't patch-ready (or > > committed) themselves. Plus this needs changing, moving to "open" > > It has been for a while that there is no review for > > 193134 193313 193315 193316 > > Best, > Jingfeng closed 193316. Rework needs to place and test for the python modules installation.
Created attachment 149426 [details] portlint -AC output
Created attachment 149427 [details] Updated shar file By using setup.py script to install all the requirements into thirdpart directory, especially remove the port requirements for Djblets 0.6. The test results for this implementation is positive.
(In reply to Jingfeng Yan from comment #26) > Created attachment 149427 [details] > Updated shar file > > By using setup.py script to install all the requirements into thirdpart > directory, especially remove the port requirements for Djblets 0.6. The test > results for this implementation is positive. Bug ID 195023 and 195024 are removing the requirements for /proc. Without the /proc. the simple deployment usage could be: bash cd /usr/local/www/haiwen/seafile-server/seahub for file in makemessages.sh.template run-seahub.sh.template send_user_notifications.sh.template setenv.sh.template; do cp ${file} ${file%%.template} done cd /usr/local/www/haiwen/seafile-server source seahub/setenv.sh ./setup-seafile.sh ./seafile.sh start ./seahub.sh start I am running the Pouderier tests now.
(In reply to Jingfeng Yan from comment #27) > (In reply to Jingfeng Yan from comment #26) > > Created attachment 149427 [details] > > Updated shar file > > > > By using setup.py script to install all the requirements into thirdpart > > directory, especially remove the port requirements for Djblets 0.6. The test > > results for this implementation is positive. > > Bug ID 195023 and 195024 are removing the requirements for /proc. Without > the /proc. the simple deployment usage could be: > > bash > > cd /usr/local/www/haiwen/seafile-server/seahub > for file in makemessages.sh.template run-seahub.sh.template > send_user_notifications.sh.template setenv.sh.template; do > cp ${file} ${file%%.template} > done > > cd /usr/local/www/haiwen/seafile-server > source seahub/setenv.sh > ./setup-seafile.sh > ./seafile.sh start > ./seahub.sh start > > I am running the Pouderier tests now. Holy C... The test can not access WWW network?!
(In reply to Jingfeng Yan from comment #28) > Holy C... The test can not access WWW network?! Poudriere only allows network access at the fetch phase. A port should never use the network after that.
(In reply to John Marino from comment #29) > (In reply to Jingfeng Yan from comment #28) > > Holy C... The test can not access WWW network?! > > Poudriere only allows network access at the fetch phase. A port should > never use the network after that. Then, I have very limited choice, which does not do anything for django related dependency, and as the Seahub release way, leave this part to the users. Or, I have to fight hard to say something like this: Why reviewboard-1.7.22 requires djblets, then it get a specific version of djblets. If other application needs other version of djblets, why we can not have a version of djblets for that app? You can also check: There is no one use py27-django-pipeline 1.3+, but only review board use another version: py27-django-pipeline12. That is why I am confused what is the policy for python pkg version port in FreeBSD port system. Do I miss any important point from the other thread.
(In reply to Jingfeng Yan from comment #30) > Why reviewboard-1.7.22 requires djblets, then it get a specific version of > djblets. If other application needs other version of djblets, why we can > not have a version of djblets for that app? I think you are asking the wrong question. The question is, why is seahub unable to use the latest version of djblets? This makes seahub look bad IMO. It's a bad situation. I wanted to avoid the situation *IF POSSIBLE*. If it's not possible, then fine, we bring back a legacy port. This kind of thing is why I avoid python. > That is why I am confused what is the policy for python pkg version port in > FreeBSD port system. Do I miss any important point from the other thread. It's just good practice not to have multiple versions of the same port. Avoid it where it's possible. Sometimes it can't be avoided. But I didn't want to make this call, I wanted the python@ team to give good advice.
(In reply to John Marino from comment #31) > (In reply to Jingfeng Yan from comment #30) > > Why reviewboard-1.7.22 requires djblets, then it get a specific version of > > djblets. If other application needs other version of djblets, why we can > > not have a version of djblets for that app? > > I think you are asking the wrong question. The question is, why is seahub > unable to use the latest version of djblets? This makes seahub look bad IMO. > > It's a bad situation. I wanted to avoid the situation *IF POSSIBLE*. If > it's not possible, then fine, we bring back a legacy port. This kind of > thing is why I avoid python. > > > That is why I am confused what is the policy for python pkg version port in > > FreeBSD port system. Do I miss any important point from the other thread. > > It's just good practice not to have multiple versions of the same port. > Avoid it where it's possible. Sometimes it can't be avoided. But I didn't > want to make this call, I wanted the python@ team to give good advice. (1) The information that I gathered is that Djblets is tightly bind to version of Django. As I understand, if you select version of Django, then you have specific version range of Djblets. I can start to push Seahub developer to move newer version of Django, but which version os Django will not be known soon, and how long it take may not known. So, we might have to have multiple versions of Djblets. The positive part is that we are introducing higher versions, not back to legacy. However, if we look at the problem in other point of view: When updating Djblets from 0.6 to current version in port system, if the old version were kept for Django 15, we would have seen the same result: We have specific version Djblets for specific Django version. So, the point is not to bring back legacy version, but keep Django chain in complete. (The reason that I mentioned Linux side Djblets naming in 193316, just gave some idea that it does have some evidence Django and Djblets have some tight binding). It does not mean anything wrong in that decision. But, Django 15 is still alive in the port system, and we don't want to say everyone have to run the bleeding version. I agree with you because we must be very careful to keep multiple version of python packages (especially some old stuff) because it is a big headache thing (python version, package version, ... that multiple-dimension problem will stuff the port system). So, I bring the problem whether we want to have multiple versions, or it takes case by case. If you think from keeping Django framework complete, taking Djblets 0.6.14 back is not such bad, just another special case. (2) (FYI, Seahub was PUSHED from Django lower version to current version 15, we can not not use Django14 related Djblets, which is 0.7.12 in system). The statement in other thread: - Seahub needs Djblets, not FreeBSD port. So, I move the dependencies into seahub to be handled by python setuptools and place the django15, and Djblets0.6 under seahub place instead of global site. However, this way seems not be able to seperated dependency downloading and installation (I am still learning whether it is possible, but not that bright so far). The current python package download happens in do-install stage. I don't know whether these can happens on post-fetch stage (it could be very odd). In py-djbelts06 thread, it stressed that the users should have their virtualenv to run stuff. For setting up virtualenv, it is not part of port system. If FreeBSD port should not have Djblets, then it must be handled by the users. (3) Overall, I think the python side don't want to have it, I can not do it thru do-install. If placing setup.py running in fetch procedure is a bad hacking, I have to say forget about the Django related dependencies. We leave this part to users' virtual env. Seahub release package does not include anything about Django ... It might be me that run too far.
Created attachment 149515 [details] portlint -AC output
Created attachment 149517 [details] updated shar file This shar file introduce option to install python site packages. Now, it is OFF by default. I am not sure whether I should turn it ON by default.
Created attachment 149518 [details] test port log move the downloading procedure in fetch stage, and pass the port test.
A commit references this bug: Author: marino Date: Fri Nov 28 09:05:51 UTC 2014 New revision: 373536 URL: https://svnweb.freebsd.org/changeset/ports/373536 Log: Add new port www/seahub PR: 193135 Submitted by: Jingfeng Yan Seahub is the web frontend for seafile-server. WWW: https://github.com/haiwen/seahub Changes: head/www/Makefile head/www/seahub/ head/www/seahub/Makefile head/www/seahub/distinfo head/www/seahub/files/ head/www/seahub/files/altinstall.pth head/www/seahub/files/patch-send_user_notifications.sh.template head/www/seahub/files/patch-setenv.sh.template head/www/seahub/files/runtime_seahub.conf head/www/seahub/files/setup.cfg head/www/seahub/files/setup.py head/www/seahub/pkg-descr head/www/seahub/pkg-plist
Thanks! There were some repeated line with options, so I removed the duplicates, rearranged them, tabbed differently, but otherwise it passed poudriere just fine (FreeBSD 10 amd64)
(In reply to John Marino from comment #37) > Thanks! There were some repeated line with options, so I removed the > duplicates, rearranged them, tabbed differently, but otherwise it passed > poudriere just fine (FreeBSD 10 amd64) Thank you for your working during the Thanksgiving.