<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/debian/rules, branch v2.5.1</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>debian package: synced with OBS versions</title>
<updated>2026-01-01T20:11:35+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-01T20:11:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0236c1ee6244700db907d7dcabde301916f90cda'/>
<id>0236c1ee6244700db907d7dcabde301916f90cda</id>
<content type='text'>
In principle the debian/ subdirectory is redundant with the
files in OBS. It is only still useful when building with distribute.mk
or as a template for future adoption into the Debian repositories.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In principle the debian/ subdirectory is redundant with the
files in OBS. It is only still useful when building with distribute.mk
or as a template for future adoption into the Debian repositories.
</pre>
</div>
</content>
</entry>
<entry>
<title>when running the testsuite with --verbose, also turn off colors (--color=never)</title>
<updated>2025-09-21T14:30:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-09-21T12:21:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e38dbd2f3fe241e9e669595e611d6d4cd07da97e'/>
<id>e38dbd2f3fe241e9e669595e611d6d4cd07da97e</id>
<content type='text'>
Improves readability of the log files.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Improves readability of the log files.
</pre>
</div>
</content>
</entry>
<entry>
<title>debian/rules: enable verbose testsuite log</title>
<updated>2025-08-14T11:52:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-08-14T11:52:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=003cb1e430739d8a464321b236ac6f34f7b39678'/>
<id>003cb1e430739d8a464321b236ac6f34f7b39678</id>
<content type='text'>
In case there is a failure, there is no way to inspect the
testsuite directory - all there will be is a CI or Launchpad runner log,
so all information should be in that log.
The CI `make check` and RPM spec also sets the --verbose flag.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In case there is a failure, there is no way to inspect the
testsuite directory - all there will be is a CI or Launchpad runner log,
so all information should be in that log.
The CI `make check` and RPM spec also sets the --verbose flag.
</pre>
</div>
</content>
</entry>
<entry>
<title>Debian: disabled parallel builds when running the test suite</title>
<updated>2024-12-28T01:01:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-28T00:58:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9f9b31685d612731c2b3064beb9fa149f4b6e76a'/>
<id>9f9b31685d612731c2b3064beb9fa149f4b6e76a</id>
<content type='text'>
* Hopefully makes the log easier to read in case of failures.
  There may still be 2 runs concurrently since we build Curses and Gtk in parallel.
* Updated homepage.
* Ubuntu plucky builds are failing.
  See https://launchpadlibrarian.net/765999455/buildlog_ubuntu-plucky-amd64.sciteco_2.3.0-0ppa1~plucky1_BUILDING.txt.gz
  This may have been a spurious failure due to xvfb-run.
  It may be less likely with --no-parallel.
  Theoretically we could bump the Debian package version in order to test that,
  but the PPA is practically not used by anybody anyway.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Hopefully makes the log easier to read in case of failures.
  There may still be 2 runs concurrently since we build Curses and Gtk in parallel.
* Updated homepage.
* Ubuntu plucky builds are failing.
  See https://launchpadlibrarian.net/765999455/buildlog_ubuntu-plucky-amd64.sciteco_2.3.0-0ppa1~plucky1_BUILDING.txt.gz
  This may have been a spurious failure due to xvfb-run.
  It may be less likely with --no-parallel.
  Theoretically we could bump the Debian package version in order to test that,
  but the PPA is practically not used by anybody anyway.
</pre>
</div>
</content>
</entry>
<entry>
<title>fully support relocatable binaries, improving AppImages</title>
<updated>2024-11-05T09:32:04+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-11-04T22:29:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9cce7d263ea3f2984a619cdfcb54d264c6a4c51d'/>
<id>9cce7d263ea3f2984a619cdfcb54d264c6a4c51d</id>
<content type='text'>
* You can now specify `--with-scitecodatadir` as a relative path,
  that will be interpreted relative to the binary's location.
* Win32 binaries already were relocatable, but this was a Windows-specific
  hack. Win32 binaries are now built with `--with-scitecodatadir=.`
  since everything is in a single directory.
* Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`.
  This is not crucial for ordinary installations, but is meant for AppImage creation.
* Since AppImages are now built from relocatable packages,
  we no longer need the unionfs-workaround from pkg2appimage.
  This should fix the strange root contents when autocompleting in
  AppImage builds.
* This might also fix the appimage.github.io CI issues.
  I assume that because I could reproduce the issue on FreeBSD's
  Linuxulator in dependence of pkg2appimage's "union"-setting.
  See https://github.com/AppImage/appimage.github.io/pull/3402
* Determining the binary location actually turned out be hard and
  very platform-dependant. There are now implementations for Windows
  (which could also read argv[0]), Linux and generic UNIX (which
  works on FreeBSD, but I am not sure about the others).
  I believe this could also be useful on Mac OS to create app bundles,
  but this needs to be tested - currently the Mac OS binaries are
  installed into fixed locations and don't use relocation.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You can now specify `--with-scitecodatadir` as a relative path,
  that will be interpreted relative to the binary's location.
* Win32 binaries already were relocatable, but this was a Windows-specific
  hack. Win32 binaries are now built with `--with-scitecodatadir=.`
  since everything is in a single directory.
* Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`.
  This is not crucial for ordinary installations, but is meant for AppImage creation.
* Since AppImages are now built from relocatable packages,
  we no longer need the unionfs-workaround from pkg2appimage.
  This should fix the strange root contents when autocompleting in
  AppImage builds.
* This might also fix the appimage.github.io CI issues.
  I assume that because I could reproduce the issue on FreeBSD's
  Linuxulator in dependence of pkg2appimage's "union"-setting.
  See https://github.com/AppImage/appimage.github.io/pull/3402
* Determining the binary location actually turned out be hard and
  very platform-dependant. There are now implementations for Windows
  (which could also read argv[0]), Linux and generic UNIX (which
  works on FreeBSD, but I am not sure about the others).
  I believe this could also be useful on Mac OS to create app bundles,
  but this needs to be tested - currently the Mac OS binaries are
  installed into fixed locations and don't use relocation.
</pre>
</div>
</content>
</entry>
<entry>
<title>fully support out of tree builds</title>
<updated>2024-08-23T02:51:55+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-08-23T02:13:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ee9cf43587d5fef3a0f6d97ef50b8cf848945bcb'/>
<id>ee9cf43587d5fef3a0f6d97ef50b8cf848945bcb</id>
<content type='text'>
* You no longer have to copy contrib/scintilla, contrib/scinterm and contrib/lexilla
  manually to the build directory.
* It turns out, that Scintilla/Lexilla was supporting this since 2016.
  Scintilla allows pointing to a source directory (srdir) and Lexilla to a binary directory (DIR_O).
* For Scinterm I opened a pull request in order to add srcdir/basedir variables:
  https://github.com/orbitalquark/scinterm/pull/21
* `make distcheck` is therefore now also fixed.
* The FreeBSD package is now allowed to build out of source.
  I haven't tested it yet.
* See also https://github.com/ScintillaOrg/lexilla/issues/266
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You no longer have to copy contrib/scintilla, contrib/scinterm and contrib/lexilla
  manually to the build directory.
* It turns out, that Scintilla/Lexilla was supporting this since 2016.
  Scintilla allows pointing to a source directory (srdir) and Lexilla to a binary directory (DIR_O).
* For Scinterm I opened a pull request in order to add srcdir/basedir variables:
  https://github.com/orbitalquark/scinterm/pull/21
* `make distcheck` is therefore now also fixed.
* The FreeBSD package is now allowed to build out of source.
  I haven't tested it yet.
* See also https://github.com/ScintillaOrg/lexilla/issues/266
</pre>
</div>
</content>
</entry>
<entry>
<title>Debian: fixed rules (build and binary targets)</title>
<updated>2023-06-20T14:40:54+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-20T03:07:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b709f27a4cdbb60ed99f09f8a66c1541bd6c888a'/>
<id>b709f27a4cdbb60ed99f09f8a66c1541bd6c888a</id>
<content type='text'>
* dh_testdir would sometimes cause problems on the PPA servers,
  so we replaced it with an empty rule.
* We need to define the binary-arch and binary-indep targets
  in order to recurse into the correct subdirectories.
  I do not understand why this always worked on the Github runner
  and sometimes even on the PPA servers.
  Unfortunately, we cannot just call `dh binary-arch -B... -p...`
  since that would call `dh_install -a` which overrides any `-p` (package),
  thus trying to install the curses binaries from the Gtk build directory
  and vice versa.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* dh_testdir would sometimes cause problems on the PPA servers,
  so we replaced it with an empty rule.
* We need to define the binary-arch and binary-indep targets
  in order to recurse into the correct subdirectories.
  I do not understand why this always worked on the Github runner
  and sometimes even on the PPA servers.
  Unfortunately, we cannot just call `dh binary-arch -B... -p...`
  since that would call `dh_install -a` which overrides any `-p` (package),
  thus trying to install the curses binaries from the Gtk build directory
  and vice versa.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed Debian packages: don't use curly brace expansions as they are not portable</title>
<updated>2021-10-12T07:43:35+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-10-12T07:06:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=da1a6507a826acbdfc2f492027efe0c48cc790b6'/>
<id>da1a6507a826acbdfc2f492027efe0c48cc790b6</id>
<content type='text'>
* fixed some Debian lintian warnings
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* fixed some Debian lintian warnings
</pre>
</div>
</content>
</entry>
<entry>
<title>upgraded to Scintilla 5.1.3 and Scinterm 3.1</title>
<updated>2021-10-11T05:02:05+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-10-11T05:02:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=6e67f5a682ff46d69888fec61b94bf45cec46721'/>
<id>6e67f5a682ff46d69888fec61b94bf45cec46721</id>
<content type='text'>
* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches).
  All of the patches are now either irrelevant or have been merged upstream.
* Since Scintilla 5 requires C++17, this increases the minimum GCC version at least
  to 5.0. We may actually require even newer versions.
* I could not upgrade the scintilla-mirror (which was imported from Mercurial),
  so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0,
  master was deleted and I reimported the entire Scintilla repo using
  git-remote-hg.
  This means that scintilla-mirror now contains two entirely separate trees.
  But it is still possible to clone old SciTECO repos.
* The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed.
  Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream
  releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced),
  we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3).
  This branch is never rebased or deleted. Therefore, we are guaranteed to be able to
  clone arbitrary SciTECO repo commits - not only releases.
  Releases no longer have to be tagged in scintilla-mirror.
  On the downside, fixup commits may accumulate in these new branches.
  They can only be squashed once a new branch for a new Scintilla release is created
  (e.g. by cherry-picking followed by rebase).
* Scinterm does no longer have to reside in the Scintilla subdirectory,
  so we added it as a regular submodule.
  There are no more recursive submodules.
  The Scinterm build system has not been improved at all, but we use
  a trick based on VPATH to build Scinterm in scintilla/bin/.
* Scinterm is now in Git and we reference the upstream repo for the
  time being.
  We might mirror it and apply the same branching workflow as with Scintilla
  if necessary.
  The scinterm-mirror repository still exists but has not been touched.
  We will also have to rewrite its master branch as it was a non-reproducible
  Mercurial import.
* Scinterm now also comes with patches for Scintilla which we simply applied
  on our sciteco-rel-5-1-3 branch.
* Scintilla 5 outsourced its lexers into the Lexilla project.
  We added it as yet another submodule.
* All submodules have been moved into contrib/.
* The Scintilla API for setting lexers has consequently changed.
  We now have to call SCI_SETILEXER(0, CreateLexer(name)).
  As I did not want to introduce a separate command for setting lexers,
  &lt;ES&gt; has been extended to allow setting lexers by name with the SCI_SETILEXER
  message which effectively replaces SCI_SETLEXERLANGUAGE.
* The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used
  in the SciTECO standard library anyway - and have consequently been removed
  from symbols-scilexer.c.
  The style macros from SciLexer.h (SCE_...) are theoretically still useful - even
  though they are not used by our current color schemes - and have therefore been
  retained. They can be specified as wParam in &lt;ES&gt;.
* &lt;ES&gt; no longer allows symbolic constants for lParam.
  This never made any sense since all supported symbols were always wParam.
* Scinterm supports new native cursor modes.
  They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER
  caret style is configured by default.
  It makes no sense to enable native cursor modes now since the
  command line should have a native cursor but is not yet a Scintilla view.
* The Scintilla upgrade performed much worse than before,
  so some optimizations will be necessary.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches).
  All of the patches are now either irrelevant or have been merged upstream.
* Since Scintilla 5 requires C++17, this increases the minimum GCC version at least
  to 5.0. We may actually require even newer versions.
* I could not upgrade the scintilla-mirror (which was imported from Mercurial),
  so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0,
  master was deleted and I reimported the entire Scintilla repo using
  git-remote-hg.
  This means that scintilla-mirror now contains two entirely separate trees.
  But it is still possible to clone old SciTECO repos.
* The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed.
  Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream
  releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced),
  we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3).
  This branch is never rebased or deleted. Therefore, we are guaranteed to be able to
  clone arbitrary SciTECO repo commits - not only releases.
  Releases no longer have to be tagged in scintilla-mirror.
  On the downside, fixup commits may accumulate in these new branches.
  They can only be squashed once a new branch for a new Scintilla release is created
  (e.g. by cherry-picking followed by rebase).
* Scinterm does no longer have to reside in the Scintilla subdirectory,
  so we added it as a regular submodule.
  There are no more recursive submodules.
  The Scinterm build system has not been improved at all, but we use
  a trick based on VPATH to build Scinterm in scintilla/bin/.
* Scinterm is now in Git and we reference the upstream repo for the
  time being.
  We might mirror it and apply the same branching workflow as with Scintilla
  if necessary.
  The scinterm-mirror repository still exists but has not been touched.
  We will also have to rewrite its master branch as it was a non-reproducible
  Mercurial import.
* Scinterm now also comes with patches for Scintilla which we simply applied
  on our sciteco-rel-5-1-3 branch.
* Scintilla 5 outsourced its lexers into the Lexilla project.
  We added it as yet another submodule.
* All submodules have been moved into contrib/.
* The Scintilla API for setting lexers has consequently changed.
  We now have to call SCI_SETILEXER(0, CreateLexer(name)).
  As I did not want to introduce a separate command for setting lexers,
  &lt;ES&gt; has been extended to allow setting lexers by name with the SCI_SETILEXER
  message which effectively replaces SCI_SETLEXERLANGUAGE.
* The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used
  in the SciTECO standard library anyway - and have consequently been removed
  from symbols-scilexer.c.
  The style macros from SciLexer.h (SCE_...) are theoretically still useful - even
  though they are not used by our current color schemes - and have therefore been
  retained. They can be specified as wParam in &lt;ES&gt;.
* &lt;ES&gt; no longer allows symbolic constants for lParam.
  This never made any sense since all supported symbols were always wParam.
* Scinterm supports new native cursor modes.
  They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER
  caret style is configured by default.
  It makes no sense to enable native cursor modes now since the
  command line should have a native cursor but is not yet a Scintilla view.
* The Scintilla upgrade performed much worse than before,
  so some optimizations will be necessary.
</pre>
</div>
</content>
</entry>
<entry>
<title>debianized the Gtk UI (sciteco-gtk)</title>
<updated>2021-05-31T22:36:58+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-05-31T22:36:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0dcfb82c706585d1ed5bd700a88cc9ddc6a8751d'/>
<id>0dcfb82c706585d1ed5bd700a88cc9ddc6a8751d</id>
<content type='text'>
* Added a Freedesktop file - only as part of the debian package yet.
  `make install` won't install a Desktop file since it would have to be
  generated.
* Just like when installing manually, you can have a Curses and Gtk installation
  side by side using the same .teco_ini.
* Common data between the Curses UI (sciteco-curses) and Gtk UI are in a new
  architecture-independant package sciteco-common.
* The Gtk+ binaries are prefixed with `g` (gsciteco, gtedoc.tes, ggrosciteco.tes).
* Debian source and binary packages can be built using `./distribute.mk debian`
  as usual.
  It should also be possible to push everything to the PPA for the next release,
  although that is not yet tested.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Added a Freedesktop file - only as part of the debian package yet.
  `make install` won't install a Desktop file since it would have to be
  generated.
* Just like when installing manually, you can have a Curses and Gtk installation
  side by side using the same .teco_ini.
* Common data between the Curses UI (sciteco-curses) and Gtk UI are in a new
  architecture-independant package sciteco-common.
* The Gtk+ binaries are prefixed with `g` (gsciteco, gtedoc.tes, ggrosciteco.tes).
* Debian source and binary packages can be built using `./distribute.mk debian`
  as usual.
  It should also be possible to push everything to the PPA for the next release,
  although that is not yet tested.
</pre>
</div>
</content>
</entry>
</feed>
