Created attachment 149424 [details] svn diff Based on Porter's handbook, the usage of /proc is not recommended. The diff is implementing the pgrep-like code and using sysctl to get proc info.
Created attachment 149425 [details] portlint -AC output
this definitely limits the port to freebsd. What's wrong with /proc other than handbook doesn't recommend it? What's the reason the handbook doesn't recommend it?
(In reply to John Marino from comment #2) > this definitely limits the port to freebsd. > > What's wrong with /proc other than handbook doesn't recommend it? What's > the reason the handbook doesn't recommend it? The porter handbook put this under this section: """ 12.18. Avoiding Linuxisms Do not use /proc if there are any other ways of getting the information. For example, setprogname(argv[0]) in main() and then getprogname(3) to know the executable name>. Do not rely on behavior that is undocumented by POSIX. ... """ So, I think this is only reason. :) BTW, although this port is not directly used by other BSDs, I got OpenBSD side contacts and suggest not using /proc, too. OpenBSD once supported /proc, and then removed as I heard (from kernel at least, FUSE may be used).
Created attachment 149520 [details] test port log
Can you clarify? Are you saying these seafile ports are for FreeBSD only? The removal of /proc will probably mean these don't build on DragonFly anymore because DF-specific code wasn't added.
(In reply to John Marino from comment #5) > Can you clarify? > > Are you saying these seafile ports are for FreeBSD only? [JF] No. > > The removal of /proc will probably mean these don't build on DragonFly > anymore because DF-specific code wasn't added. [JF] I will install a DrangoFlyBSD and make a try. If you have identified any suspicious lib calls, which is not supported by DragonflyBSD, you can also let me know. I am also considering to add the test code for /proc existence. If so, /proc fs is used; otherwise, we will use sysctl way. I will try to be back on Friday (US EST).
sysctl way is okay as long as it works for both freebsd and dragonfly. let's keep this simple if we can.
This appears like a moot discussion. The port won't build on DragonFly anyway because of this requirement: LIB_DEPENDS= libfuse.so:${PORTSDIR}/sysutils/fusefs-libs Using FUSE limits seafile to FreeBSD.
(In reply to John Marino from comment #8) > This appears like a moot discussion. > > The port won't build on DragonFly anyway because of this requirement: > LIB_DEPENDS= libfuse.so:${PORTSDIR}/sysutils/fusefs-libs > > > Using FUSE limits seafile to FreeBSD. Do you mean DragonFly miss fuse kernel side support? I thought I checked roughly before, but not go to too much detail. FreeBSD and NetBSD, and openBSD seems to fine. the founder of DragonFlyBSD started playing eithe fuse-like idea in 2006. Could you give me some idea of why fuse is missing there, what I can help to make this port happen on DragonFly? You are DPort creator, and active on DragonFly. If you can have some evaluation, maybe we can have a way to make it work. At the same time, I will check why we need fuse.
(In reply to Jingfeng Yan from comment #9) > (In reply to John Marino from comment #8) > > This appears like a moot discussion. > > > > The port won't build on DragonFly anyway because of this requirement: > > LIB_DEPENDS= libfuse.so:${PORTSDIR}/sysutils/fusefs-libs > > > > > > Using FUSE limits seafile to FreeBSD. > > Do you mean DragonFly miss fuse kernel side support? I thought I checked > roughly before, but not go to too much detail. FreeBSD and NetBSD, and > openBSD seems to fine. the founder of DragonFlyBSD started playing eithe > fuse-like idea in 2006. Could you give me some idea of why fuse is missing > there, what I can help to make this port happen on DragonFly? > > You are DPort creator, and active on DragonFly. If you can have some > evaluation, maybe we can have a way to make it work. At the same time, I > will check why we need fuse. BTW, if the fuse discussion not fit here, you can send email to me yan_jingfeng@yahoo.com.
(In reply to Jingfeng Yan from comment #9) > BTW, if the fuse discussion not fit here, you can send email to me yan_jingfeng@yahoo.com. It's fine here. > Do you mean DragonFly miss fuse kernel side support? Correct - no kernel support for FUSE > I thought I checked > roughly before, but not go to too much detail. FreeBSD and NetBSD, and > openBSD seems to fine. the founder of DragonFlyBSD started playing eithe > fuse-like idea in 2006. Could you give me some idea of why fuse is missing > there, what I can help to make this port happen on DragonFly? FUSE basically doesn't work that well. None of the FUSE ports are maintained (literally, they have no maintainer). It's unclear who is responsible for FUSE maintenance in the kernel. I think there's no designated person. Basically, it barely works on FreeBSD, when there is a problem nobody is there to fix it, and DragonFly just decided it wasn't worth pursuing. Maybe not officially, but nobody is making an effort to support it. > You are DPort creator, and active on DragonFly. If you can have some > evaluation, maybe we can have a way to make it work. At the same time, I > will check why we need fuse. I think the only hope is that FUSE is optional and that we don't set the option on DragonFly. If it's truly required, there's no hope. John
(In reply to John Marino from comment #11) > (In reply to Jingfeng Yan from comment #9) > > BTW, if the fuse discussion not fit here, you can send email to me yan_jingfeng@yahoo.com. > > It's fine here. > > > Do you mean DragonFly miss fuse kernel side support? > > Correct - no kernel support for FUSE > > > I thought I checked > > roughly before, but not go to too much detail. FreeBSD and NetBSD, and > > openBSD seems to fine. the founder of DragonFlyBSD started playing eithe > > fuse-like idea in 2006. Could you give me some idea of why fuse is missing > > there, what I can help to make this port happen on DragonFly? > > FUSE basically doesn't work that well. None of the FUSE ports are > maintained (literally, they have no maintainer). It's unclear who is > responsible for FUSE maintenance in the kernel. I think there's no > designated person. Basically, it barely works on FreeBSD, when there is a > problem nobody is there to fix it, and DragonFly just decided it wasn't > worth pursuing. Maybe not officially, but nobody is making an effort to > support it. > > > > You are DPort creator, and active on DragonFly. If you can have some > > evaluation, maybe we can have a way to make it work. At the same time, I > > will check why we need fuse. > > I think the only hope is that FUSE is optional and that we don't set the > option on DragonFly. If it's truly required, there's no hope. > > John No, it is not required. It can be ignored. I will make FUSE to an option.
Created attachment 149740 [details] svn diff - procfs is not required, but optional. - make fuse is make option, which is default for FreeBSD, disabled in DragonFly. - suggest to review last week's seahub new shar file, which has dedicated python django, and djblets installation.
Created attachment 149741 [details] test port log
Created attachment 149742 [details] SVN diff - procfs is not required, but optional. - make fuse is make option, which is default for FreeBSD, disabled in DragonFly. - suggest to review last week's seahub new shar file, which has dedicated python django, and djblets installation.
Created attachment 149744 [details] SVN diff - procfs is not required, but optional. - make fuse is make option, which is default for FreeBSD, disabled in DragonFly. - suggest to review last week's seahub new shar file, which has dedicated python django, and djblets installation. 149742: SVN diff (outdated) because it contained one patch file without using "-u" option in diff command.
A commit references this bug: Author: marino Date: Fri Nov 28 08:11:14 UTC 2014 New revision: 373534 URL: https://svnweb.freebsd.org/changeset/ports/373534 Log: net-mgmt/seafile: Remove use of /proc and make FUSE optional DragonFly has not implemented FUSE, so it's not reqired by default. PR: 195024 submitted by: maintainer Changes: head/net-mgmt/seafile/Makefile head/net-mgmt/seafile/files/patch-configure.ac head/net-mgmt/seafile/files/patch-controller_seafile-controller.c head/net-mgmt/seafile/files/patch-lib_Makfile.am head/net-mgmt/seafile/files/patch-lib_utils.c head/net-mgmt/seafile/files/patch-lib_utils.h head/net-mgmt/seafile/pkg-plist
thanks. I moved some of the option lines around and added tabs, but that was it.