sync autochanges back to upstream

[kberry]

I've reset the main TL build to include xdvipsk, and expect the binaries for most platforms will be included in tonight's build.

I disabled building it on i386-solaris, because the crle stuff that you inserted for xdvipsk makes the teckit_compile test fail, and maybe other things. It should be possible to build xdvipsk without the crle changes, since we build lots of other C++ programs, but let's leave that for another time. I doubt anyone will be using xdvipsk on i386-solaris.

So: can you please make sure you've copied back the changes I made to the various files to your upstream, so the next time you update the TL repo, they won't be lost? Notably, renaming thirdparty/lib*/ac to ac.no (or just removing), since trying to configure these directories as part of TL is not necessary (and fails), since you included all the necessary stuff in the top level Makefile.am. As far as I've seen.

Thanks.

[sigto]

I disabled building it on i386-solaris, because the crle stuff that you inserted for xdvipsk makes the teckit_compile test fail, and maybe other things. It should be possible to build xdvipsk without the crle changes, since we build lots of other C++ programs, but let's leave that for another time. I doubt anyone will be using xdvipsk on i386-solaris.

Can we postpone this job for now? Is it critical and urgent in case of already running pretests?

Notably, renaming thirdparty/lib*/ac to ac.no (or just removing), since trying to configure these directories as part of TL is not necessary (and fails), since you included all the necessary stuff in the top level Makefile.am. As far as I've seen.

This configuration was inherited from the previous xdvipsk version when these libraries were standalone in the lib folder.
I missed it because I was short on time and lacked experience. Thanks again for your assistance..

What are some good practices for developing TexLive sources? Should be used TexLive-source GitHub fork, or any Docker, VM solutions?

Regards,
Sigitas

[kberry]

Can we postpone this job for now? Yes. It's not important to have xdvipsk on i386-solaris now, or ever, as far as I'm concerned. TL should probably drop support for i386-solaris. What are some good practices for developing TexLive sources? Should be used TexLive-source GitHub fork, or any Docker, VM solutions? Good question. I myself don't use anything like that for the programs I work on outside of the TL source, but Norbert or Max might have something useful to suggest. I'll write them. -k

[kberry]

@gucci-on-fleek @norbusan Max, Norbert, please see Sigitas's question above about good practices. For xdvipsk, he has their separate upstream repository (here). I'm not sure what to suggest. Can you advise? Thanks.

[norbusan]

@sigto There is no "recommended" flow, unfortunately.
What I do is I have my own git checkout of texlive.git (the whole) locally, and when I do changes I rebased then merge and then immediately do git svn dcommit - this has worked the last 5-10? or more years.

But the complete checkout is big.

I do NOT know whether you can git svn dcommit from the texlive-source github repo - I have never tried it, and doubt it is working.

[sigto]

Thanks, Norbert, for sharing your experience. I’m fine working locally and committing to SVN. The hardest part for me is making sure my local build works the same with GitHub Actions builds or builds on platforms other than Linux or macOS. I’m a bit uneasy about testing it with actual SVN commits. I initially thought of using a GitHub repository fork and testing builds with GitHub Actions in that fork. Is that a reasonable way?

[norbusan]

What about this:

• you checkout a texlive-source from github
• you make a branch dev/SOMETHINGSOMETHING like /dev/xdvipsk-dev - note the dev/ prefix is necessary, the github repo rejects other branches to be pushed
• You work on this branch
• You/me change the github actions to run the xdvipsk work on pushes to this branch

That way you should be able to get all your stuff tested on your branch.

The only problem I cannot solve immediately is how to get your changes back into svn. Of course you can just make a diff and patch it into svn and commit it, but that looses the git history.

Would that work for you?

[sigto]

Thanks for your help, it should work.

[kberry]

run the xdvipsk work on pushes to this branch Yes, we can easily change the xdvipsk-test action to work from the new branch. Sigitas, can you create your branch and let us know? The only problem I cannot solve immediately is how to get your changes back into svn. Of course you can just make a diff and patch it into svn and commit it, but that looses the git history. "Losing" the git history does not sound bad to me. Then what ends up in tl svn can be a comprehensible change, not all the development commits along the way. Especially if ChangeLog entries are written, which (in my experience) is highly desirable. --thanks, karl.

[sigto]

• you make a branch dev/SOMETHINGSOMETHING like /dev/xdvipsk-dev - note the dev/ prefix is necessary, the github repo rejects other branches to be pushed

I created local branch dev/xdvipsk-dev from git@github.com:TeX-Live/texlive-source.git trunk branch clone.
How can I transfer it to remote (permission denied problem) or did I misunderstand how to use it?

[norbusan]

I invited you to the org and a team. I will give the team push permission after you have joined.

[sigto]

Thanks, it worked.

[norbusan]

Good, I see you branch. You will want to regulary either rebase on origin/trunk or at least merge it to keep up with the rest.

Should we add some github automatic testing of your branch?

[norbusan]

Ok, I have done this. If you merge trunk and push that to your branch, after that all pushes to the branch should run the xdvipsk build only github action.

[sigto]

Should we add some github automatic testing of your branch?

If it means TESTS described in xdvipsk/Makefile.am then yes, it would be fine.

[kberry]

If it means TESTS described in xdvipsk/Makefile.am then yes, it would be fine. Indirectly. The xdvipsk-test.sh and .yml that Norbert set up actually builds the whole tree, now from your branch, on every commit there (as I understand it), but with everything but xdvipsk disabled: ``` ./Build -C ... disable-all-pkgs --enable-xdvipsk ``` So that runs make check. I see the last build succeeded, so yay :). Feel free to continue to tweak the xdvipsk files in .github as needed. Karl