Bug#841294: Overrule maintainer of "global" to package a new upstream version
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 <punitagrawal@gmail.com> wrote:
> On Wed, Nov 30, 2016 at 4:56 PM, Ian Jackson
> <ijackson@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 <ijackson@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 to: