Bug 193135

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.

Comment 4 Marcus von Appen 2014-09-05 22:08:57 UTC

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.

Comment 5 Kubilay Kocak 2014-09-06 03:01:09 UTC

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

Comment 9 Kubilay Kocak 2014-09-06 10:32:12 UTC

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

Comment 10 Kubilay Kocak 2014-09-06 10:49:16 UTC

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 ...

Comment 12 Kubilay Kocak 2014-09-06 11:25:00 UTC

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.

Comment 18 John Marino 2014-10-27 15:29:02 UTC

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?

Comment 19 John Marino 2014-11-02 17:58:11 UTC

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?!

Comment 29 John Marino 2014-11-15 07:12:55 UTC

(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.

Comment 31 John Marino 2014-11-15 15:08:17 UTC

(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.

Comment 36 commit-hook 2014-11-28 09:06:15 UTC

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

Comment 37 John Marino 2014-11-28 09:08:06 UTC

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.