[MIR] gnome-text-editor

[Sebastien Bacher]

[Availability]
The package gnome-text-editor is already in Ubuntu universe.
The package gnome-text-editor build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64 arm64 armhf ppc64el riscv64 s390x
Link to package https://launchpad.net/ubuntu/+source/gnome-text-editor

[Rationale]
- The package gnome-text-editor is required in Ubuntu main to replace gedit as the default desktop text editor
- Package gnome-text-editor covers the same use case as gedit, but is better
  because it is the new default editor in GNOME and it is actively maintained, thereby we want to replace it.

- The package gnome-text-editor is required in Ubuntu main no later than aug 25
  due to kinetic feature freeze

[Security]
- No CVEs/security issues in this software in the past

- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software

[Quality assurance - function/usage]
- The package works well right after install

[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has current no open report
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/gnome-text-editor/+bug
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gnome-text-editor
- The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
- The package runs a test suite on build time, if it fails
  it makes the build fail, link to build log https://launchpadlibrarian.net/598874210/buildlog_ubuntu-kinetic-amd64.gnome-text-editor_42.1-1_BUILDING.txt.gz

- The package does not run an autopkgtest because desktop softwares aren't easy to test in autopkgtest. THe situation isn't a regression compared to gedit which we want ro replace. While it would be nice to get some sort of autopkgtest in place we don't think that should be a blocker to replace gedit.

We created a manual testplan to be used to verify updates until we figure out a better automated testing story, https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeTextEditor

[Quality assurance - packaging]
- debian/watch is present, it's currently not working due to GNOME infrastructure changes but that's going to be resolved.

- there are only a few minor lintian warnings

# lintian --pedantic
W: gnome-text-editor: no-manual-page usr/bin/gnome-text-editor
W: gnome-text-editor source: no-nmu-in-changelog
W: gnome-text-editor source: source-nmu-has-incorrect-version-number 42.1-1
P: gnome-text-editor source: silent-on-rules-requiring-root

- Lintian overrides are not present

- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies

- The package will be installed by default, but does not ask debconf questions

- Packaging and build is easy, link to d/rules https://salsa.debian.org/gnome-team/gnome-text-editor/-/blob/debian/master/debian/rules

[UI standards]
- Application is end-user facing, Translation is present, via standard gettext
- End-user applications that ships a standard conformant desktop file,

[Dependencies]

- No further depends or recommends dependencies that are not yet in main expect gtksourceview-5 which is a newer serie of a package already in main which we plan to transition to.

[Standards compliance]
- This package correctly follows FHS and Debian Policy

[Maintenance/Owner]
- Owning Team will be desktop-packages
- Team is not yet, but will subscribe to the package before promotion

- This does not use static builds
- This does not use vendored code

- The package has been built in the archive more recently than the last
  test rebuild

[Background information]
The Package description explains the package well
Upstream Name is gnome-text-editor
Link to upstream project https://gitlab.gnome.org/GNOME/gnome-text-editor

[Didier Roche-Tolomelli (didrocks)]

I’ll review the rest on the MIR, but to not add more delay, I think we should discuss this:

> "- The package does not run an autopkgtest because desktop softwares aren't easy to test in autopkgtest. THe situation isn't a regression compared to gedit which we want ro replace. While it would be nice to get some sort of autopkgtest in place we don't think that should be a blocker to replace gedit."

I see more and more packages telling this "It’s already not tested, or the rest of the stack is not tested, so let’s keep this status quo and not improve it". I kind of disagree with this, and I think the MIR process is the right moment to get things right, or at least, in a better state. Otherwise, things will never improve.

So my suggestion, is really to follow the MIR guidelines, stating that either autopkgtests are provided, or that, if not feasable (which I agree testing GUI is hard on our infra and it doesn’t seem unfortunately there is assigned capacity to get that situation better), "the subscribed team must provide a written test plan in a comment to the MIR bug, and commit to running that test either at each upload of the package or at least once each release cycle. "

I think this latter approach is a mitigation plan, (which won’t protect you though from reverse dependencies to break you, contrary to autopkgtests).
Thoughts?

[Sebastien Bacher (seb128)]

Thanks Didier. I agree with you that when considering new components we should use the opportunity to improve our testing story. We need to figure out the testing story for graphical applications and I hope that's something we can add to our roadmap in the next cycles as we get more resources.

I will create a manual testcase meanwhile

[Sebastien Bacher (seb128)]

I've added a testplan to https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeTextEditor now

[Didier Roche-Tolomelli (didrocks)]

Review for Package: gnome-text-editor

[Summary]
MIR team ack under the condition gtksourceview5 is already transition is promoted to main. I think the easiest is to transition to it so that it’s promoted and then promoting this one. This is the reason I switch it to incomplete until the transition is done to avoid promotions by error beforehand.

Recommended TODOs:
- Maybe fix the only warning present due to unused variable and propose it upstream:
../src/editor-application.c: In function ‘editor_application_command_line’:
../src/editor-application.c:412:22: warning: unused variable ‘self’ [-Wunused-variable]
  412 | EditorApplication *self = (EditorApplication *)app;
      | ^~~~

[Duplication]
gedit provides the same functionality, but it will be replaced by this new application.

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems:
- gtksourceview5 is needed. See top suggestion for transition being done before promoting this package.

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries

OK:
- not a go package, no extra constraints to consider in that regard

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does not have a test suite that runs as autopkgtest but a manual test plan is provided
- no new python2 dependency

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

[Upstream red flags]
OK:
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests)
- no use of user nobody
- no use of setuid
- use of setuid, but ok because TBD (prefer systemd to set those
  for services)
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- part of the UI, desktop file is ok
- translation present

Problems:
- One warning during build, see top explanation on recommended TODOs as this one is small.

[Jeremy Bícha (jbicha)]

I am setting this bug to Fix Commited based on the ACK in the previous comment.
ubuntu-meta has been updated for gedit -> gnome-text-editor
gnome-calculator has been switched to gtksourceview5 which was the only other package in main using gtksourceview4.

[Sebastien Bacher (seb128)]

Override component to main
gnome-text-editor 42.1-1 in kinetic: universe/misc -> main
gnome-text-editor 42.1-1 in kinetic amd64: universe/gnome/optional/100% -> main
gnome-text-editor 42.1-1 in kinetic arm64: universe/gnome/optional/100% -> main
gnome-text-editor 42.1-1 in kinetic armhf: universe/gnome/optional/100% -> main
gnome-text-editor 42.1-1 in kinetic ppc64el: universe/gnome/optional/100% -> main
gnome-text-editor 42.1-1 in kinetic riscv64: universe/gnome/optional/100% -> main
gnome-text-editor 42.1-1 in kinetic s390x: universe/gnome/optional/100% -> main
Override [y|N]? y
7 publications overridden.

[Sebastien Bacher (seb128)]

About the TODO, in fact the upstream code is

  EditorApplication *self = (EditorApplication *)app;
  .
  .
  .
  g_assert (EDITOR_IS_APPLICATION (self));
  g_assert (G_IS_APPLICATION_COMMAND_LINE (command_line));

the g_assert are for debugging and disabled at thee package build by using G_DISABLE_ASSERT so I think that can be considered as a false positive