Bug#574947: Status and progress
Re-iterating what's been said earlier... On Sun, Jun 8, 2014 at 5:53 PM, Vincent Bernat ber...@debian.org wrote: ❦ 9 juin 2014 01:27 +0930, Ron r...@debian.org : I am using gg-tags in Emacs and the current version of global in Debian just doesn't work with this mode. I am using global with the linux kernel source code and the version in Debian hasn't worked for me since about a year. The binary silently fails to build the tags. The issue does not exist with upstream releases. What changed incompatibly to make it not work? And what would need patching to fix that? I'd really much rather see problems get fixed than layered under even more problems. If someone familiar with Emacs has some details of what doesn't work, and what needs to be done so that it will, that sounds like a separate bug to be addressed to me. Some arguments seem to not exist in previous versions. I did not investigate more as it seems quite sensible for a program to get more functionalities. Indeed! :) While there doesn't seem to be any motivation to resolve the issues blocking the package upgrade, I'd like to point you to a package repository containing an upgrade to recent upstream release (6.2.12) - http://anonscm.debian.org/gitweb/?p=collab-maint/global.git. The package is also updated to follow more recent packaging standards. It would be ideal if the official package got upgraded (or maybe replaced by another package), but in the meanwhile I'd like to keep the above repo in-sync with upstream releases. Please let me know if you face any issues using that version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
❦ 16 avril 2014 06:15 +0900, Shigio YAMAGUCHI shi...@gnu.org : There will be no response, even if you are waiting. Instead, how about making a new package named 'global6'? Such cases are often seen. e.g. Python: python, python3 gnupg: gnupg, gnupg2 Since the present package includes Ron's fine htmake, it should be considered a special one. So, the new package may co-exist with it. There is no fear of collisions, because Ron's package is 'global5' forever. :) Unfortunately, because of the conflicting names, it would be problematic. Ron, will you agree if someone packaged global6 without the CGI stuff and use of the alternative system to let people choose between global and global6 for gtags and other commands? I am using gg-tags in Emacs and the current version of global in Debian just doesn't work with this mode. -- panic(CPU too expensive - making holiday in the ANDES!); 2.2.16 /usr/src/linux/arch/mips/kernel/traps.c -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
Hi Vincent, On Sun, Jun 08, 2014 at 08:02:56AM +0200, Vincent Bernat wrote: ❦ 16 avril 2014 06:15 +0900, Shigio YAMAGUCHI shi...@gnu.org : There will be no response, even if you are waiting. Instead, how about making a new package named 'global6'? Such cases are often seen. e.g. Python: python, python3 gnupg: gnupg, gnupg2 Since the present package includes Ron's fine htmake, it should be considered a special one. So, the new package may co-exist with it. There is no fear of collisions, because Ron's package is 'global5' forever. :) Unfortunately, because of the conflicting names, it would be problematic. Ron, will you agree if someone packaged global6 without the CGI stuff and use of the alternative system to let people choose between global and global6 for gtags and other commands? That sounds a lot like taking a horrible mess, and making it even more horrible and messy to me ... which seems like quite step in the wrong direction. I am using gg-tags in Emacs and the current version of global in Debian just doesn't work with this mode. What changed incompatibly to make it not work? And what would need patching to fix that? I'd really much rather see problems get fixed than layered under even more problems. If someone familiar with Emacs has some details of what doesn't work, and what needs to be done so that it will, that sounds like a separate bug to be addressed to me. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
❦ 9 juin 2014 01:27 +0930, Ron r...@debian.org : I am using gg-tags in Emacs and the current version of global in Debian just doesn't work with this mode. What changed incompatibly to make it not work? And what would need patching to fix that? I'd really much rather see problems get fixed than layered under even more problems. If someone familiar with Emacs has some details of what doesn't work, and what needs to be done so that it will, that sounds like a separate bug to be addressed to me. Some arguments seem to not exist in previous versions. I did not investigate more as it seems quite sensible for a program to get more functionalities. With a recent version: Usage: global [-adGilnqrstTvx][-e] pattern global -c[diIoOPrsT] prefix global -f[adlnqrstvx][-L file-list] files global -g[aGilnoOqtvVx][-L file-list][-e] pattern [files] global -I[ailnqtvx][-e] pattern global -P[aGilnoOqtvVx][-e] pattern global -p[qrv] global -u[qv] With the version currently in Debian: Usage: global [-aGilnqrstTvx][-e] pattern global -c[qrsv] prefix global -f[anqrstvx] files global -g[aGilnoOqtvx][-e] pattern global -I[ailnqtvx][-e] pattern global -P[aGilnoOqtvx][-e] pattern global -p[qrv] global -u[qv] -- Let the data structure the program. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Bug#574947: Status and progress
2014-04-12 17:34 GMT+09:00 Punit Agrawal punitagra...@gmail.com: I've been using global for over a year now. And in all that usage I've never had to run anything as root. When you off-handedly mentioned a generated script being required to be run as root I didn't even know what you were talking about. Neither did you reply to my query asking for further clarification. There will be no response, even if you are waiting. Instead, how about making a new package named 'global6'? Such cases are often seen. e.g. Python: python, python3 gnupg: gnupg, gnupg2 Since the present package includes Ron's fine htmake, it should be considered a special one. So, the new package may co-exist with it. There is no fear of collisions, because Ron's package is 'global5' forever. :) -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
On Fri, Apr 11, 2014 at 1:55 PM, Ron r...@debian.org wrote: On Fri, Apr 11, 2014 at 12:50:57PM +0100, Punit Agrawal wrote: On Fri, Apr 11, 2014 at 11:31 AM, Ron r...@debian.org wrote: On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. The parameters that htconfig/htmake rely on are not part of upstream htags. So they are broken with recent releases. Which is why I say something equivalent. This was the best that Shigio and I could come up with together 15 years ago, to meet the needs of doing this in a way that was suitable for the distro. I'd like to think that if anything there would be Better ways to do this today, given the number of web-appy type things that also exist. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. NACK. Saying I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. Turning off a feature is not my preferred option either. I am the one who's initiated this discussion with the intent of trying to understand the functionality and how to package it. Well, your first reply to my query was I don't use this, so I could just turn it off. And you were still suggesting that as an option. I've been using global for over a year now. And in all that usage I've never had to run anything as root. When you off-handedly mentioned a generated script being required to be run as root I didn't even know what you were talking about. Neither did you reply to my query asking for further clarification. When faced with this situation and not knowing how to move things forward I'd suggested turning it off. And Shigio in his reply agrees that this isn't a bad option as it isn't even used that widely. The equation is pretty simple really - either we solve the problem(s) that makes this unsuitable for release with the distro, or it remains unsuitable for release with the distro. The current package in debian is broken - even the tags functionality is broken. The problem doesn't exist in upstream release. I am in favour of solving the problem you point out, but at the same time I don't agree with holding back a package update which fixes a problem for users, especially when there isn't a resolution in 3.5 years. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. The problem arises due to the expectation that the user needs to write to a priviledged system wide location. Instead, is it not preferable that the user generated content (the HTML folder and cgi scripts therein) be placed in the users web area (e.g., ~public_html) and it is served from there like any other user generated content. No priviledged access is required. Does that make sense? Well ... no. That doesn't make any sense at all. The cgi scripts run with the privilege of the web server. Which means an audited copy of that needs to be installed and enabled by someone with the privilege to decide whether or not that is acceptable. And someone with similar privilege needs to decide what files it will be allowed to access. Which means all of this needs to: a) Not be generated on the fly, so that the sysadmin can actually audit it, and know that what they audited is what is running. b) Not be world writable. Which is effectively what you'd be doing if you let 'non-static' content run executables from ~pub_html with elevated privilege. None of this is rocket science to do. It just requires some acceptance that sane security practices are actually
Bug#574947: Status and progress
Hi Shigio, Thanks for the explanation. On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. So the aim is to have a mapping from sitekeys to actual project directories containing the generated HTML. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. I am looking to see if there's an obvious way to package this. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. Please ask me again, if my explanation is insufficient. Thanks for your help. My primary motivation is to update the package as soon as possible for the majority of the users and then address any issues incrementally. Your explanation is most helpful. Punit -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
So the aim is to have a mapping from sitekeys to actual project
directories containing the generated HTML.
That's right.
Ok. Am I correct in understanding that the actual system cgi script is
not provided by global but it is to be created by the user or system
administrator.
At first, you need to get the CGI scripts by executing htags, and copy
them to the system cgi area. It is required only once.
(The scripts above will become static files in the future.)
$ htags -f ... # in any place
# cp HTML/cgi-bin/*pl /usr/local/apache2/cgi-bin # required only once
#
# From now on, normal operation
#
$ cd usr/local/src/grep-2.9
$ gtags
$ htags -f --system-cgi=prj1 # 'prj1' is embeded in the form
$ cat /usr/local/var/gtags/sitekeys/prj1
/usr/local/src/grep-2.9/HTML
$ _
[CGI program]
+---
|if (key is embeded) {
| Get key = 'prj1'
| Read /usr/local/var/gtags/sitekeys/prj1
| = /usr/local/src/grep-2.9/HTML
| chdir /usr/local/src/grep-2.9/HTML
|}
|Do the job.
I am looking to see if there's an obvious way to package this. I might
resort to turning this feature off in the first update and then add it
to the package as I understand better what is needed on the packaging
side.
I agree. But I think it is no problem on as is basis, because the use
of this feature is very difficult. I am responsible about it.
It seems that you do not need to take responsibility for it.
Shigio
--
Shigio YAMAGUCHI shi...@gnu.org
PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: Hi Shigio, Thanks for the explanation. On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. So the aim is to have a mapping from sitekeys to actual project directories containing the generated HTML. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. NACK. Saying I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. But we need to sort this out. Sweeping it under the rug is just code for This will never happen, so I will strongly object to any upload that does this. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
On Fri, Apr 11, 2014 at 11:31 AM, Ron r...@debian.org wrote: On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: Hi Shigio, Thanks for the explanation. On Thu, Apr 10, 2014 at 1:03 PM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. So the aim is to have a mapping from sitekeys to actual project directories containing the generated HTML. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. The parameters that htconfig/htmake rely on are not part of upstream htags. So they are broken with recent releases. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. NACK. Saying I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. Turning off a feature is not my preferred option either. I am the one who's initiated this discussion with the intent of trying to understand the functionality and how to package it. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. The problem arises due to the expectation that the user needs to write to a priviledged system wide location. Instead, is it not preferable that the user generated content (the HTML folder and cgi scripts therein) be placed in the users web area (e.g., ~public_html) and it is served from there like any other user generated content. No priviledged access is required. Does that make sense? But we need to sort this out. Sweeping it under the rug is just code for This will never happen, so I will strongly object to any upload that does this. Sweeping it under the run isn't my intention. I agree we need to resolve the issue. I'd appreciate your input on how it can be fixed properly. Punit Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
On Fri, Apr 11, 2014 at 12:50:57PM +0100, Punit Agrawal wrote: On Fri, Apr 11, 2014 at 11:31 AM, Ron r...@debian.org wrote: On Fri, Apr 11, 2014 at 09:38:54AM +0100, Punit Agrawal wrote: Ok. Am I correct in understanding that the actual system cgi script is not provided by global but it is to be created by the user or system administrator. Global creates everything that is needed, but installing it to the system requires privilege that an ordinary user should not have. Which means we need a secure and sensible interface for someone with that privilege to exercise it, in a way that meets the normal distro expectations and standards. A generated script that the user is required to run as root, or making a privileged system directory 777 writable is not such an interface. If people want to do that on their own systems that is fine, but the distro packages should never be recommending or requiring this. I am looking to see if there's an obvious way to package this. There is a mechanism for doing this in the existing package. If something equivalent to that was integrated upstream, none of this would be a problem anymore. The parameters that htconfig/htmake rely on are not part of upstream htags. So they are broken with recent releases. Which is why I say something equivalent. This was the best that Shigio and I could come up with together 15 years ago, to meet the needs of doing this in a way that was suitable for the distro. I'd like to think that if anything there would be Better ways to do this today, given the number of web-appy type things that also exist. I might resort to turning this feature off in the first update and then add it to the package as I understand better what is needed on the packaging side. NACK. Saying I don't need this, so I'm just going to remove it for everyone else to rush out the bits that _I_ want is not an acceptable solution. If that's all you want then you can make your own local packages easily enough. Turning off a feature is not my preferred option either. I am the one who's initiated this discussion with the intent of trying to understand the functionality and how to package it. Well, your first reply to my query was I don't use this, so I could just turn it off. And you were still suggesting that as an option. The equation is pretty simple really - either we solve the problem(s) that makes this unsuitable for release with the distro, or it remains unsuitable for release with the distro. I am very interested in seeing this all fixed, but someone is going to have to find a middle ground that both meets the minimum sensible expectations for distro Best Practice for this, and that Shigio is willing to accept. Several of us have tried several times, but maybe you will have more luck with that. The problem arises due to the expectation that the user needs to write to a priviledged system wide location. Instead, is it not preferable that the user generated content (the HTML folder and cgi scripts therein) be placed in the users web area (e.g., ~public_html) and it is served from there like any other user generated content. No priviledged access is required. Does that make sense? Well ... no. That doesn't make any sense at all. The cgi scripts run with the privilege of the web server. Which means an audited copy of that needs to be installed and enabled by someone with the privilege to decide whether or not that is acceptable. And someone with similar privilege needs to decide what files it will be allowed to access. Which means all of this needs to: a) Not be generated on the fly, so that the sysadmin can actually audit it, and know that what they audited is what is running. b) Not be world writable. Which is effectively what you'd be doing if you let 'non-static' content run executables from ~pub_html with elevated privilege. None of this is rocket science to do. It just requires some acceptance that sane security practices are actually important, and need to be designed in from the beginning, not handwaved away as too hard. But we need to sort this out. Sweeping it under the rug is just code for This will never happen, so I will strongly object to any upload that does this. Sweeping it under the run isn't my intention. I agree we need to resolve the issue. I'd appreciate your input on how it can be fixed properly. If it isn't your intention, that's great, but that wasn't what your words kept saying :) I, and others, have said many times what is needed to do this sanely, and the constraints above should not be that hard to satisfy. What has so far proved impossible has been convincing Shigio that chmod 777 is not an acceptable substitute for this. And I don't really know what else I can say anymore that might change that. Shigio, please reconsider. We have people prepared to spend time on this. Let's use that to do this properly
Bug#574947: Status and progress
2014-04-11 21:55 GMT+09:00 Ron r...@debian.org: Shigio, please reconsider. We have people prepared to spend time on this. Let's use that to do this properly once and for all. Let's find an answer that satisfies both basic security practices, and whatever it is that does concern you about methods that would do that. bless.sh and chmod 777 do not do that, so if you want to progress with this, we need to meet in the middle somewhere with a modern design using current best practice. I don't remember about 15 years before. If you have a proposal about GLOBAL then you should come to the public place for it, that is, bug-glo...@gnu.org , and explain it so that the members can understand. About the debian's policy, I can say nothing other than Debian's issue should be solved in Debian. Incidentally, removing the --system-cgi option is a wise judgment, because it is not so important any longer. It is hardly used. Those who want to use it will install GLOBAL from the tar archive. -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
Hi Shigio, Thanks for your reply. Since I don't use the htags functionality I appreciate your clarifications. I have a On Thu, Apr 10, 2014 at 1:53 AM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hello, 2014-04-09 22:38 GMT+09:00 Punit Agrawal punitagra...@gmail.com: Ron's, rather short, reply pointed out that a distro package requiring users to run a generated script as root isn't an acceptable interface. It's a misunderstanding. I just offered a means to leave the admin user to update the system directory (sitekeys directory). It is only a default; it is not required. You can change it by configure script as follows: $ ./configure --with-sitekeys-mode=777 This command line executes 'chmod 777 'localstatedir/gtags/sitekeys'. I just fixed a bug with packaging which failed to create 'localstatedir/gtags/sitekeys'. But... localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. If you have write permission for the directory, you need not invoke bless.sh after executing htags. Of course, root permission is not required. Please see 'FILES' section of htags(1). I am not sure how actively this feature is used, but in the interest of updating the package I proposed to drop generating the script and print a message for now. I've not received any further reply to my request for clarification or the proposed changes. Bless.sh script is needed for moving the project directory. Just making 'sitekeys' directory writable, everything goes well. # # Builds a hypertext of a project # $ cd /usr/src/project $ htags -f --system-cgi=key # = CGI works (bless.sh is not needed) # # Moves the project to another place # $ mv /usr/src/project /home/user # = CGI does not work $ cd /home/user/project/HTML $ sh bless.sh # = CGI works (bless.sh is needed) From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? Watch this space for further progress and do let me know if you face any problems trying to use the package from the linked repository. [0] http://anonscm.debian.org/gitweb/?p=collab-maint/global.git;a=summary Great! I am very glad to hear that new Debian GLOBAL will be released soon. I appreciate your efforts. Thanks for your comments. I appreicate your explanation and the encouragement here. Punit Regards, Shigio -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Please ask me again, if my explanation is insufficient. -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#574947: Status and progress
An update since the last reply. * I've managed to fix the issue in global related to emacsen-common while installing the package. Yay! (Note: The emacsen-bug #736062 still needs a fix though). * The global package development repository has been uploaded to collab-maint[0] which I'll sync periodically with changes I make locally. * The package in the repository has been updated to latest upstream release - 6.2.12. Since the package wasn't updated in a long time, I got in touch with Ron (the package maintainer) to inform him of the above repository and ask for feedback. I'd also suggested being co-maintainer since I use global regularly and would like to see it being maintained. Ron's, rather short, reply pointed out that a distro package requiring users to run a generated script as root isn't an acceptable interface. I wasn't quite sure what he was referring to since in all my usage of global, I've never had to run anything as root. On digging into the package, I found that one of the binaries in the package, htags, when run with the '--form' or '--dynamic' and the '--system-cgi' flag by a user who doesn't have rights to write to /usr/var/gtags/sitekeys requires them to run a generated script (bless.sh) as root. In contrast, there are a lot of use cases (including mine) which don't need any privileged access. I am not sure how actively this feature is used, but in the interest of updating the package I proposed to drop generating the script and print a message for now. I've not received any further reply to my request for clarification or the proposed changes. I hope to implement the changes soon after which I'd like to upload the package. Watch this space for further progress and do let me know if you face any problems trying to use the package from the linked repository. [0] http://anonscm.debian.org/gitweb/?p=collab-maint/global.git;a=summary -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
Hello, 2014-04-09 22:38 GMT+09:00 Punit Agrawal punitagra...@gmail.com: Ron's, rather short, reply pointed out that a distro package requiring users to run a generated script as root isn't an acceptable interface. It's a misunderstanding. I just offered a means to leave the admin user to update the system directory (sitekeys directory). It is only a default; it is not required. You can change it by configure script as follows: $ ./configure --with-sitekeys-mode=777 This command line executes 'chmod 777 'localstatedir/gtags/sitekeys'. If you have write permission for the directory, you need not invoke bless.sh after executing htags. Of course, root permission is not required. Please see 'FILES' section of htags(1). I am not sure how actively this feature is used, but in the interest of updating the package I proposed to drop generating the script and print a message for now. I've not received any further reply to my request for clarification or the proposed changes. Bless.sh script is needed for moving the project directory. Just making 'sitekeys' directory writable, everything goes well. # # Builds a hypertext of a project # $ cd /usr/src/project $ htags -f --system-cgi=key # = CGI works (bless.sh is not needed) # # Moves the project to another place # $ mv /usr/src/project /home/user # = CGI does not work $ cd /home/user/project/HTML $ sh bless.sh # = CGI works (bless.sh is needed) Watch this space for further progress and do let me know if you face any problems trying to use the package from the linked repository. [0] http://anonscm.debian.org/gitweb/?p=collab-maint/global.git;a=summary Great! I am very glad to hear that new Debian GLOBAL will be released soon. I appreciate your efforts. Regards, Shigio -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
