allowing anonymous contributions to LyX's source code?

[Scott Kostyshak]

From time to time, we receive patches from people who prefer to remain
anonymous (e.g. use a nickname and not their real name). It would be
nice if we had a clear policy on whether we are OK with this.

After some searching, from what I understand, the GPL license does not
forbid anonymous contributions [1]. However, I'm not too confident in
this. I wish there were an entry in the GPL FAQ [2]. The question
regarding the Eclipse Public License (EPL) is addressed in the EPL FAQ,
which states that a contributor may not remain anonymous.

I have found open source projects who use GPL that explicitly state they
do not accept anonymous contributions, e.g. [3].

If we can accept anonymous contributions under the GPL (which needs a
more definitive answer), do we want to? In the past I think I remember
LyX developers being generally against accepting anonymous
contributions. My personal opinion is that if the GPL allows, I would
like for LyX to accept contributions without forcing contributors to
reveal their true name. My main argument in favor is that I think that
protecting peoples' privacy is important and with time is only becoming
more important.

The post in [1] mentions that some projects do not accept such
contributions because they are afraid that the patch could actually come
from somewhere else and the poster does not have permission to give the
copyright away. But if this is really our concern, I would argue that in
practice someone who wished to remain anonymous would just have to
create a fake name ("John Smith") and submit the patch like that. So
unless we do some extra verification (e.g. we require a PGP signature),
I don't see how forcing people to use a (fake) name solves this
particular concern.

I've seen arguments in the past that since we chose to give up our
anonymity, it is only fair that others do the same. I really don't
understand this argument. If someone believes this, can you expand
further? Why force someone unnecessarily to do something they don't want
to do?

I'm curious about your thoughts. Since GPL license issues are a topic
that I'm pretty ignorant about, I'm open to changing my mind.

Scott


[1]
https://softwareengineering.stackexchange.com/questions/115343/does-the-agplv3-allow-people-to-contibute-code-anonymously
[2]
https://www.gnu.org/licenses/gpl-faq.html
[3]
https://w1.fi/cgit/hostap/plain/CONTRIBUTIONS


signature.asc
Description: PGP signature

Re: Minted example not displaying in pdf anymore

[Enrico Forestieri]

On Sun, Jun 25, 2017 at 04:24:18PM -0400, Scott Kostyshak wrote:
> 
> True, but I think that is partly because we used to support GCC 4.6 and
> Qt 4.8. We have never supported minted, so that is why I think it is
> "more OK" if we do not support older versions. In the end, I suppose it
> depends on how long it would take us to add support for older versions,
> and on if that support would be hackish or would be a good
> implementation.
> 
> Enrico, any thoughts on the above?

Taking into account older versions of Pygments that are case
sensitive would be straightforward. It would suffice to lower
case the language only when it is going to be written in the
LaTeX file. Indeed, our GUI is case sensitive and the language
combo gets disabled if the case does not match (meaning that the
language can only be changed through the advanced tab).

I don't think this has any adverse effect, except if you export to
LaTeX and then import back with tex2lyx. In this case the language
combo will be most certainly disabled. But it suffices going to the
advanced tab and properly adjust the case to have it functional again.

-- 
Enrico

qt4/Makefile.am patch from #10711

[Scott Kostyshak]

Does anyone feel comfortable pushing the patch recently posted at the
following trac issue?

https://www.lyx.org/trac/ticket/10711

Scott


signature.asc
Description: PGP signature

Re: Copying translations from 2.2.x to master?

[Scott Kostyshak]

On Sat, Jun 10, 2017 at 01:27:02PM -0400, Scott Kostyshak wrote:
> On Sat, Jun 10, 2017 at 10:29:04AM +0200, Uwe Stöhr wrote:
> > Hi Scott, I am still away for another week. I already transferred the po 
> > files from 2.2.x to master for all active translations .
> 
> Great, thank you!
> 
> > So please don't touch the po files in master.
> 
> OK.
> 
> > The translators will be informed
> 
> By whom? I was going to send an email, but do you prefer to do it? That
> would probably be best since you know more about this than I do. Either
> way is fine with me. I just want to know who has the responsibility.
> Is 2 weeks a good time to give them for a deadline?
> 
> > that they only need to translate the giles in master for LyX 2.3. 
> 
> And what about the docs? Will you send an email about that also?
> 
> Scott

Hi Uwe,

I just wanted to make sure you saw my above questions. If no email has
been sent, I would like to do so as soon as possible. I believe that we
will resolve other beta-blockers soon (notably the discussion on
-shell-escape, and the discussion on dashes) so translations are the
last remaining issue before we can get a beta out.

I'm sorry to bother you when you are busy. Thank you for all of the work
you do for the translations.

Scott


signature.asc
Description: PGP signature

Re: dash patch for stable

[Scott Kostyshak]

On Wed, Jun 14, 2017 at 11:48:13PM -0400, Richard Heck wrote:
> On 06/14/2017 02:08 PM, Scott Kostyshak wrote:
> > On Tue, Jun 13, 2017 at 09:30:03PM +, Guenter Milde wrote:
> >> On 2017-06-09, Scott Kostyshak wrote:
> >>
> >>> [-- Type: text/plain, Encoding:  --]
> >>> On Mon, Jun 05, 2017 at 07:41:21AM +, Guenter Milde wrote:
>  I don't have a preference regarding the two alternative patches for 
>  stable.
> >>> And what is the status of this discussion for 2.3.0? Did we come to an
> >>> agreement on what should be done?
> >> Unfortunately, there is no agreement.
> > OK. So we are stuck. I want to come to a decision before beta1. I'm not
> > sure what to suggest. I get the feeling that we've had enough discussion
> > and further discussion will not lead to a unanimous agreement. In this
> > case, I suppose we need to take a vote. Can I get a +1 from someone else
> > that thinks a vote would be a good idea in this situation?
> 
> Yes, that's the way we have proceeded in the past when there were such
> disagreements.
> 
> > (if indeed I get a +1 on the above) to proceed with a vote, anyone who
> > would like to make a proposal would need to write a self-contained
> > description of the problem and their proposed solution. A critique of
> > other available solutions is encouraged as well, so that we get a
> > feeling of the advantages/disadvantages of each proposed solution. I
> > emphasize self-contained because the discussion has been spread out and
> > we want people to participate in the vote who have not followed the
> > discussion so far. In addition to the essence of the proposal being
> > self-contained, you are welcome to make references to previous
> > discussion if you want to give the reader the option of reading a
> > particular issue more in detail. But don't waste time on this until we
> > get a +1 to proceed with a vote.
> 
> + a lot. We defintely need a summary of what the issue is.

Günter, are you planning to make a proposal so that we can vote? I'm
sorry to ask you to do this when you have already spent a lot of time on
the topic, but I am hoping that this round will be the last one and that
we can vote and come to a conclusion, and that we can decide this before
2.3.0beta1.

Thanks for all of your time on this topic. I regret not taking the time
to fully understand all of the discussion before (I was secretly hoping
unanimous agreement would be achieved), but I look forward to spending
time to understand the advantages/disadvantages of your self-contained
proposal.

Scott


signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

[Scott Kostyshak]

On Sun, Jun 25, 2017 at 02:54:29PM +0200, Jürgen Spitzmüller wrote:
> Am Sonntag, den 25.06.2017, 13:53 +0200 schrieb Guillaume MM:
> > > While I believe that the question of providing the package most
> > > popular
> > > at a certain point in time vs. a good enough implementation is
> > > secondary
> > > to security implications, I also inquired at
> > >  whether it would be
> > > hard
> > > to implement 3-step compilation in minted.sty.
> > > 
> > 
> > A quick update: there is now a reply on the ticket above. In addition
> > I 
> > received the following reply from the author of minted.sty.
> 
> Thanks for bringing this to Geoffrey's attention!

Judging by the comments of gpoore, we do not want to wait for this for
2.3.0. But this does affect the discussion of what to do for 2.3.0,
since we might not want to introduce a workflow in 2.3.0 that we will
change soon after.

But regardless of what we decide to do about minted specifically, there
is still the open question of what to do with other .lyx files that
require -shell-escape. I don't think we ship any besides the newly added
minted ones, but it might be relevant to whether we make it easy to
temporarily add the -shell-escape or whether we want to make it hard (to
discourage it), with the consequence that the user might forget to
remove it. Once we answer this question in general, then we can decide
what to do with minted.

If the answer to the general question is "yes, let's make it easy so
that the user is not encouraged to permanently change a converter that
they might forget about", then from what I understand, Enrico has
proposed a patch that does that so it is straight-forward to move on: we
can use that approach for minted for 2.3.0, and when the github issues
is fixed, then we can transition to a safer approach (but I suppose it
will depend on what version of minted the user has?).

If the answer to the general question is "no, let's make it hard so that
the user is discouarged from adding -shell-escape without thinking about
it", then from what I understand, we do not make any changes to the
current state of master (i.e. we do not apply the patch proposed by
Enrico), but we still ship minted support as it is currently
implemented.

I'm sure I got something wrong in my attempt to summarize the situation
and figure out what we must decide on, so can someone correct me and add
more details? Please do so without adding your opinion on what we
*should* do. I just want to know the potential options out there.

Does everyone agree that the general question (of "make it easy or hard
for user to add -shell-escape") is important and must be addressed
before 2.3.0beta1, or did I miss something?

Scott


signature.asc
Description: PGP signature

Re: 2.3.0alpha1 tar balls are available

[Scott Kostyshak]

On Fri, Jun 23, 2017 at 12:54:19PM +0200, Liviu Andronic wrote:
> On Thu, Apr 27, 2017 at 1:59 AM, Scott Kostyshak  wrote:
> 
> > > > Should I create a branch from alpha1-1 and cherry pick only Kornel's
> > > > fixes?
> > >
> > > Yes, that is what I would do: Call it 2.3-alpha1-1 or something like
> > that.
> >
> > I did the following git commands. I called the branch 2.3-alpha1-x
> > and I will call the tag 2.3-alpha1-1:
> >
> 
> It took me some time but I've now prepared the packages for the `alpha1-1`
> tarballs. We now have `-dbg` packages as well, and as always the
> installation is independent of the main `lyx` installation.
> 
> Install the `lyx2.3pre` package for your distribution:
> https://launchpad.net/~lyx-devel/+archive/ubuntu/daily
> 
> There were important changes to the recipe, though, so as far as I go the
> packages are themselves alpha-ish. Please report if you encounter any
> issues.

Thanks for doing that, Liviu and for the extra warning about the
packages.

Scott

Re: Minted example not displaying in pdf anymore

[Scott Kostyshak]

On Thu, Jun 22, 2017 at 10:02:08PM +0200, Kornel Benko wrote:
> Am Donnerstag, 22. Juni 2017 um 13:22:20, schrieb Scott Kostyshak 
> 

> > > After some googling I came to this page:
> > >   http://pygments.org/docs/changelog/#version-2-2-0
> > > where I found this changelog line:
> > >   * Lexer aliases passed to get_lexer_by_name() are now case-insensitive.
> > > 
> > > This is for the version 2.0rc1, while I have only version 1.6. The 
> > > recommended upgrade with
> > >   # sudo pip install pygments --upgrade
> > >   Downloading/unpacking pygments from 
> > > https://pypi.python.org/packages/02/ee/b6e02dc6529e82b75bb06823ff7d005b141037cb1416b10c6f00fc419dca/Pygments-2.2.0-py2.py3-none-any.whl#md5=ce67fc58b51ffd29a2de8b97fcda274a
> > > Downloading Pygments-2.2.0-py2.py3-none-any.whl (841kB): 841kB 
> > > downloaded
> > >   Installing collected packages: pygments
> > > Found existing installation: Pygments 1.6
> > >   Not uninstalling Pygments at /usr/lib/python2.7/dist-packages, 
> > > owned by OS
> > >   Successfully installed pygments
> > >   Cleaning up...
> > > 
> > > cured the case for me. Of course, the same has to be done for python3
> > >   #   sudo pip3 install pygments --upgrade
> > 
> > Makes sense. My version was 2.1.
> > 
> > So the minimum version for pygmentize that we require is 2.0? It was
> > released in November 2014. To me, that is old enough that we should not
> > make a significant effort to support older versions since this will be a
> > new feature.
> 
> I am not so sure. For instance we still try to support e.g. gcc 4.6 or qt 4.8.

True, but I think that is partly because we used to support GCC 4.6 and
Qt 4.8. We have never supported minted, so that is why I think it is
"more OK" if we do not support older versions. In the end, I suppose it
depends on how long it would take us to add support for older versions,
and on if that support would be hackish or would be a good
implementation.

Enrico, any thoughts on the above?

> > Why did you have 1.6? Was it shipped with your distro?
> 
> Yes, it is part of the distro.
> I still have mint 17.3 based on ubuntu 14.04. I tried once to install
> mint 18 (based on ubuntu 16), but the following boot showed only a black 
> screen.
> Was unable to trace down what went wrong.
> Installation of ubuntu 16 was successful, but
> 1.) I was unable to use ssh with my old keys (e.g. could not connect to 
> lyx-git)
> 2.) my gpg-keys for mail invalid
> 3.) the use of mysql in digikam was dropped. And the conversion to sqlite 
> crashed regularly after 2 hours.
>   (In the mean time I wrote my own conversion script. It finishes in 2 
> minutes and does not crash)

I see, yes those are show-stoppers.

> 
> > And
> > why did it work before? Was it something in LyX that changed?
> 
> Apparently I did not check the pdf-output. (It compiles without errors, but 
> the pdf
> misses all inline listings)

Ah yes I often forget to check the output also.

Scott

trac login link does not use https by default

[Scott Kostyshak]

To reproduce, go to:

http://www.lyx.org/trac

Then click on "login". The connection for entering your login and
password is not secure.

Note that it is secure if in the link I give above, https is used. I
think that the login link should always be secure.

Is this an easy fix for anyone?

Scott


signature.asc
Description: PGP signature

Re: Can shell-escape take advantage of needauth framework?

[Jürgen Spitzmüller]

Am Sonntag, den 25.06.2017, 13:53 +0200 schrieb Guillaume MM:
> > While I believe that the question of providing the package most
> > popular
> > at a certain point in time vs. a good enough implementation is
> > secondary
> > to security implications, I also inquired at
> >  whether it would be
> > hard
> > to implement 3-step compilation in minted.sty.
> > 
> 
> A quick update: there is now a reply on the ticket above. In addition
> I 
> received the following reply from the author of minted.sty.

Thanks for bringing this to Geoffrey's attention!

Jürgen

signature.asc
Description: This is a digitally signed message part

Re: [LyX/2.2.x] Fix bugs #9598 and #10650

[Guillaume MM]

so as not to lay a trap for the developers who are going to come 
after me.



"to maintain the code after me" (avoiding any unintentional double
meaning due to my uncolloquial English).

Re: Can shell-escape take advantage of needauth framework?

[Guillaume MM]

Le 21/06/2017 à 07:15, Guillaume MM a écrit :


While I believe that the question of providing the package most popular
at a certain point in time vs. a good enough implementation is secondary
to security implications, I also inquired at
 whether it would be hard
to implement 3-step compilation in minted.sty.



A quick update: there is now a reply on the ticket above. In addition I 
received the following reply from the author of minted.sty.




I agree that -shell-escape is problematic, especially in a case like
LyX where the raw LaTeX code can be less visible. I will be happy to
add a 3-step compile option; the only issue will be finding time to
do it. I think the Python side of doing this would be trivial. The
main work would need to be in LaTeX code in minted.sty. I've provided
some additional technical details (if you want them) in the GitHub
issue.

Re: [LyX/2.2.x] Fix bugs #9598 and #10650

[Guillaume MM]

Le 08/06/2017 à 26:72, Enrico Forestieri a écrit :
> On Thu, Jun 08, 2017 at 12:50:19AM +0200, Guillaume MM wrote:
>
>> Le 05/06/2017 à 23:15, Enrico Forestieri a écrit :
>>> commit 59c22bd7b604a3ba9e0e78f7c51cb601f08d0192
>>> Author: Enrico Forestieri
>>> Date:   Mon Jun 5 23:14:48 2017 +0200
>>>
>>>   Fix bugs #9598 and #10650
>>> ---
>>
>>> +// gcc < 4.8.0 and msvc < 2015 do not support C++11 thread_local
>>> +#if defined(__GNUC__) && ((__GNUC__ == 4 && __GNUC_MINOR__ < 8) || 
__cplusplus < 201103L)

>>> +#define THREAD_LOCAL_STATIC static __thread
>>> +#elif defined(_MSC_VER) && ((_MSC_VER < 1900) || __cplusplus < 
201103L)

>>> +#define THREAD_LOCAL_STATIC static __declspec(thread)
>>> +#else
>>> +#define THREAD_LOCAL_STATIC thread_local static
>>> +#endif
>>> +
>>
>>
>> According to Stephan in this discussion:
>>
>> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg196176.html
>>
>> it is unfortunately not possible to use thread_local on Mac before some
>> time, it seems. I would actually be happy to hear the contrary.
>
> Note that __thread appears to be supported since OSX 10.7, and
> clang always takes the first branch because for historical reasons it
> currently defines __GNUC__ = 4 and __GNUC_MINOR__ = 2, so it
> should work on 10.7 and above. But I agree that this is confusing
> and fragile, so I will clarify the code so as not to lay a trap
> for the developers who are going to come after me.
>

Ok, good to know, thanks.

Guillaume

Re: [LyX/master] Fixup 522516d9 : editable() is unusable in mathed

[Guillaume MM]

Le 23/06/2017 à 20:38, Jean-Marc Lasgouttes a écrit :

Le 20/06/2017 à 23:31, Guillaume MM a écrit :

Hi Jean-Marc,

There is the case of InsetMathRef which has nargs()!=0 but whose cell 
is not active. See e.g. the fix at 7337c968. Is the logic still valid 
in this case? Just in case.


Hi Guillaume,

What do you think of this one instead? I don't want to commit it and fix 
it up a third time :)


I think that it is consistent with your comments :) sorry I do not have
anything further useful to say about it. I agree that it would be good
to see if isActive and editable could be merged.

Guillaume