Re: LyX Bug Tracker Password Reset Behavior

[Joel Kulesza]

On Tue, Mar 8, 2022 at 8:51 AM José Abílio Matos  wrote:

> On Tuesday, 8 March 2022 01.53.10 WET Scott Kostyshak wrote:
>
> > Thanks, Joel! I've been complaining several years that we should switch,
>
> > but I don't do anything about it :). And I still have no plans to
>
> > volunteer.
>
> >
>
> > Scott
>
> There are several examples of transitions like that:
>
> https://lwn.net/Articles/885854/
>
> In that article from LWN there are references to other moves like llvm.
>
> So it not so much is the move is worth, certainly it is in the sense that
> the administration of a infrastructure takes lots of time. The next issue
> is when should it be done, before a release, 6 months after a major
> release, etc...
>
> --
>
> José Abílio
>

Colleagues,

Thanks for reinvigorating this discussion.

Regarding José's link: indeed, I did some similar reading a while ago and
it seems the only constant is change, as projects have migrated around.
Those projects using Trac have variously reported success, and from what I
found it seems like newer versions of Trac have improved exporters relative
to what I understand LyX's version has available.  We effectively have a
SQLite dump available that then needs to be parsed.  Once parsed, we need
to then import into the preferred interface.  For this sort of thing, I
prefer Gitlab over Github (mainly because of the tighter integration of
services—see PS line if interested).  To that end, I tested an import of
~1,500 LyX issues into Gitlab about a year ago, which is about 10% of the
tickets.  That's about the upper limit of import size, which just means
we'll need to do ~10 chunked imports.  I see no problem with this.

To JMarc's question on what works and what doesn't.  Importing issue data
is clunky, but functional.  We cannot import individual comments as Gitlab
comments (as far as I can tell), but we can structure comments in the issue
description to read sensibly.  Importing issue attachments and
cross-referencing the files to the issues is something I couldn't get
working, is complicated, but I have some ideas about how to get working.
It is surely worth looking back at this since a year has elapsed since I
last did this.

Also, a coordination challenge: to get issues properly linked to human
actors (submitters, commenters, etc.), it appears that we'll want to have
individuals register an account with Gitlab *before* the import.  I'm sure
we won't get 100% coverage, but I hope we can "put the word out" on the
various LyX lists to drive this registration, to collect such user IDs, to
ultimately best link the imported data to real people.

To Scott's observation that we likely need *a* volunteer who is highly
motivated and has time...  I'm happy to continue working with this if the
prevailing opinion supports such a migration.  On the subject of when and
how to do this: much prototyping can be done before a "real migration".  I
still have the Python script I was using to process Trac data into
Gitlab-importable artifacts.  The real migration will likely be a matter of
closing issue activity over the course of a weekend to permit export from
Trac and import to Gitlab.  Regarding when that weekend should be: after a
release seems reasonable, but I'm unsure whether we need to hold ourselves
to any such schedule because a significant rift in workflow will result,
and there's likely no "good" time for that.

If we do have the prevailing opinion that we want to move ahead, some next
steps I see:

1.  I would ask active LyX developers/maintainers interested in assisting
me with sanity checks and testing to create a Gitlab.com account and send
me (privately) your user ID.

With that, I can add those individuals to the private project where I've
been doing my prototyping.  I want to keep the project private until I can
get a sanity check from trusted LyX maintainers that I'm not failing to
consider any privacy or security issues.

2. Once confirmed, I'd like to open up the current prototype Gitlab site to
be publicly accessible and solicit broader feedback (likely on this list,
though not limited just to trusted LyX maintainers but all interested
parties).

3. Incorporate the aforementioned feedback into the output processing
that's already there, and perform a prototype migration to a (different)
test project.  This prototype migration would not require any Trac outage,
etc.

With the outcome of the third step, we can determine go/no-go on a real
migration and coordinate when to do that, with particular consideration for
getting all available folks registered beforehand but not bothering
everyone too early in case we can't ensure clear success.

I look forward to everyone's thoughts on these points and this approach.

Thank you,
Joel

P.S. Some remarks on other Gitlab experience: I coordinate a Gitlab-based
project related to experimental and evaluated nuclear data processing here
, which
makes extensive use of CI

Has anyone tried the Mold linker?

[Scott Kostyshak]

Has anyone tried Mold when linking LyX? I've been curious about it for a
while. I just checked Ubuntu 22.04 daily and it has it packaged, which
makes it more interesting to try when I find the time.

Some references if curious:

  https://github.com/rui314/mold/releases/tag/v1.1.1
  https://www.phoronix.com/scan.php?page=news_item&px=Mold-1.1.1-Released

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX Bug Tracker Password Reset Behavior

[Scott Kostyshak]

On Tue, Mar 08, 2022 at 03:51:38PM +, José Abílio Matos wrote:
> On Tuesday, 8 March 2022 01.53.10 WET Scott Kostyshak wrote:
> > Thanks, Joel! I've been complaining several years that we should switch,
> > but I don't do anything about it :). And I still have no plans to
> > volunteer.
> > 
> > Scott
> 
> There are several examples of transitions like that:
> https://lwn.net/Articles/885854/
> 
> In that article from LWN there are references to other moves like llvm.
> 
> So it not so much is the move is worth, certainly it is in the sense that the 
> administration of a infrastructure takes lots of time. The next issue is when 
> should it be done, before a release, 6 months after a major release, etc...

In my opinion, the only big issue is that we need one volunteer who is
very motivated and has time. Others can help this one person (and can be
delegated specific tasks), but I think unless one person is in charge,
it will be a mess.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: SIGSEGV on master regarding math completion

[Scott Kostyshak]

On Tue, Mar 08, 2022 at 04:20:34PM +0100, Jean-Marc Lasgouttes wrote:
> Le 06/03/2022 à 19:55, Scott Kostyshak a écrit :
> > It is not minimal, but I see the message when I open ch01.lyx, after
> > lots of messages about modules not available, from the below ticket:
> > 
> >https://www.lyx.org/trac/ticket/12486
> 
> Indeed, thanks. Should be fixed now.

Thanks for the fix!
Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Crash when changing shortcut bind file

[Scott Kostyshak]

On Tue, Mar 08, 2022 at 04:43:38PM +0100, Kornel Benko wrote:
> Open UserGuide.lyx
> goto 2.1 Basic File Operations, so that some shortcuts are visible
> change the bind-file from cua to emacs
>   Tools-Preferences...->Editing->Shortcuts->Bind file: emacs ==> crash

I can reproduce. In addition to a SIGSEGV, I get the following output that 
perhaps is useful:

  /home/scott/lyxbuilds/master-master/repo/src/Paragraph.cpp:4283:12: runtime 
error: member access within misaligned address 0x0065006f for type 'struct 
Private', which requires 8 byte alignment
  0x0065006f: note: pointer points here
  

And also:

  QBackingStore::endPaint() called with active painter; did you forget to 
destroy it or call QPainter::end() on it?

Scott

> The other way e.g. emacs->cua does not crash.
> 
>   Kornel
> 
> -- 
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel



> -- 
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel



signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX Bug Tracker Password Reset Behavior

[José Abílio Matos]

On Tuesday, 8 March 2022 01.53.10 WET Scott Kostyshak wrote:
> Thanks, Joel! I've been complaining several years that we should switch,
> but I don't do anything about it :). And I still have no plans to
> volunteer.
> 
> Scott

There are several examples of transitions like that:
https://lwn.net/Articles/885854/

In that article from LWN there are references to other moves like llvm.

So it not so much is the move is worth, certainly it is in the sense that the 
administration of a infrastructure takes lots of time. The next issue is when 
should it be done, before a release, 6 months after a major release, etc...

-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Crash when changing shortcut bind file

[Kornel Benko]

Open UserGuide.lyx
goto 2.1 Basic File Operations, so that some shortcuts are visible
change the bind-file from cua to emacs
Tools-Preferences...->Editing->Shortcuts->Bind file: emacs ==> crash

The other way e.g. emacs->cua does not crash.

Kornel

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


pgp0iTsZtCvBO.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX Bug Tracker Password Reset Behavior

[Jean-Marc Lasgouttes]

Le 08/03/2022 à 02:00, Joel Kulesza a écrit :
Along those lines, you mentioned transitioning to Gitlab.  That's 
something I investigated ~1 year ago.  I'm happy to share nascent (and 
partial) work, but I'm unsure whether there are any privacy concerns of 
the metadata that I propagated, which is why I'm not immediately sharing 
the link in this note.


It is great that you took a look.

 From that work, I observe that the migration will be somewhat labor 
intensive, and many of the formatting "niceties" of legacy issues will 
be lost or at least severely diluted.  I'm not entirely happy with the 
result, which is why I didn't share progress before now, but perhaps the 
90% solution is acceptable for older issues acknowledging that the 100% 
solution for issues and the other tightly integrated interface elements 
for future issues (and work) is worth it. I provide this link in case we 
want to revisit discussion on this point and to pursue this as an option.


Could you list what works and what does not?

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: SIGSEGV on master regarding math completion

[Jean-Marc Lasgouttes]

Le 06/03/2022 à 19:55, Scott Kostyshak a écrit :

It is not minimal, but I see the message when I open ch01.lyx, after
lots of messages about modules not available, from the below ticket:

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


Indeed, thanks. Should be fixed now.

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel