I just noticed I missed out responding to one of your queries in my reply.

On Wed, Nov 30, 2016 at 7:19 PM, Punit Agrawal <punitagra...@gmail.com> wrote:
> On Wed, Nov 30, 2016 at 4:56 PM, Ian Jackson
> <ijack...@chiark.greenend.org.uk> wrote:
>> Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to 
>> package a new upstream version"):
>>> In offline discussions with Wookey, we came to the realisation that
>>> reading the various bug reports (including this one) it is not very
>>> clear how global (upstream) is structured, the functionality it
>>> provides and bits that are holding back the debian update.
>> Thank you for your clear and excellent explanation.
>> On to some questions it raises for me:
>>> Optionally, "htags" can generate a dynamic index (which reduces disk
>>> space usage) but requires an http server setup to be able to serve the
>>> pages. In this scenario, you will also need to be able to execute CGI
>>> scripts as the symbol lookup is done when serving the http request (as
>>> opposed to pre-processed when using static pages).
>>> And this last bit (integration with system web server) is the
>>> functionality that had security concerns raised by Ron [etc.]
>> So, to be clear, it is this functionality which is dropped in the
>> package that you and Wookey uploaded to experimental/delayed ?
> The debian packaging added two tools not present in upstream -
> htconfig and htmake. These tools and debian patched htags together
> make the integration with system web server work to the extent that
> Ron was comfortable shipping the package. Both htmake and htconfig are
> authored by Ron.
> So although the package uploaded by Wookey retain the tools they have
> become non-functional due to upstream changes to htags. But as you
> point out, you can still achieve a very similar end result using other
> mechanisms.
>> But AIUI this functionality remains:
>>> In addition to the above mechanisms, upstream also provides "htags"
>>> which can be used to generate an HTML version of the index. "htags"
>>> uses the index created by "gtags" and the source tree as input and
>>> generates html files which allow you to navigate the source code in
>>> the browser. By default, htags generates static pages which means you
>>> can browse the code in a local browser without requiring a web server.
>> So the impact for a user of the existing functionality the regression
>> is not that their entire workflow is disrupted.
> That is exactly what I was trying to get across in my previous email.
>> Rather (unless the software is improved) they have these choices:
>>  - Put up with pregenerated html indices.  Is the only downside
>>    of this that they use additional disk space, and presumably
>>    cpu time to generate them ?

AFAICT, yes.

>>  - Run the htags server on a high-numbered port somehow.  (Is there
>>    some kind of simple scriptery provided, to do this?)
> It would be a web server - htags isn't a server in itself. Upstream's
> suggestion of using
> python -m CGIHTTPServer
> in the generated HTML folder worked for the package Wookey has
> uploaded. This command can be executed with user privileges and runs a
> local instance of an http server.
> IIUC, running the web server with user privileges, prevents it from
> binding to external interfaces/IP addresses.
>>  - If the machine is not really multi-user, tear down the security
>>    boundary defending the webserver from their user account, and give
>>    their user account access to the webserver cgi directory (or plumb
>>    it in with symlinks).  (Are there any instructions or scripts for
>>    this?)  (Also this assumes that the source code is not super
>>    secret.)
> So I am not very familiar with cgi scripts (having never used it
> myself) but I believe what you say is possible - somebody with a
> little more knowledge than me should be easily able to come up with
> the instructions.
>> I don't know much about this, but several of these choices seem likely
>> to be plausible choices for many if not most current users of htags.
>> FAOD none of this changes my view about the proper resolution of this
>> TC petition.  But answers might help clarify the discussion.
>> Thanks,
>> Ian.
>> --
>> Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.
>> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
>> a private address which bypasses my fierce spamfilter.

Reply via email to