[MIR] dh-elpa

Bug #1951066 reported by Lukas Märdian
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cmake (Ubuntu)
Invalid
Undecided
Unassigned
dh-elpa (Debian)
Fix Released
Unknown
dh-elpa (Ubuntu)
Fix Released
Undecided
Lukas Märdian

Bug Description

[Availability]
The package src:dh-elpa is already in Ubuntu universe.
The package dh-elpa-helper build for the architectures it is designed to work on
It currently builds and works for architectures: all (arch independent)
Link to package [[https://launchpad.net/ubuntu/+source/dh-elpa|src:dh-elpa]]

It is enough to promote the dh-elpa-helper binary to main.

[Rationale]
- The package dh-elpa-helper is required in Ubuntu main as src:cmake dependency
- The package src:dh-helper will not generally be useful for a large part of
  our user base, but is important/helpful still because it is a higher level
  abstraction layer around src:emacsen-common that is used by src:cmake and
  others to unify the installation of elpa packages (like "cmake-mode").
- Additional reasons: we provided syntax highlighting and indentation for
  CMakeLists.txt and *.cmake source files in emacs previously and do not want
  to drop that.
- Additionally new use-cases enabled by this are: NONE, just keeping status quo
- Package dh-elpa covers the same use case as emacsen-common, but is better
  because it is a higher level abstraction layer, thereby we want to put it on
  top to avoid common errors such as https://bugs.debian.org/802915
- The package dh-elpa-helper is a new runtime dependency of package cmake-data
  that we already support

[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
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software
  (filters, scanners, plugins, UI skins, ...) – it provides an extension to the
  debhelper build environment, tho.

[Quality assurance - function/usage]
- The package works well right after install – if elpa dehbehlper and
  ${elpa:Depends} are being used

[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
  and long term critical bugs open
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/dh-elpa/+bug => 0 bugs
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=dh-elpa
    => no critical bugs, but 1 long standing bug, classified as "important"
       https://bugs.debian.org/886024 It cannot be reproduced by the upstream
       developers and morphed more into a proposal that the maintainers are
       unconvinced of, therefore it stalled
    => Another interesting bug is https://bugs.debian.org/995936 that is being
       discussed as of recently and would remove the Ubuntu delta if resolved.
- The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
- The package does not run a test at build time. ELPA_NAME is set and ./dh_elpa
  executed but that doesn't seem to fail the build anything is wrong.
- The package does not run an autopkgtest because non is provided in
  debian/tests
- README.org states a limitation: "This tool is currently not very well tested."
- We could try adding an autopkgtest that builds a simple elpa package, as
  descibed in https://wiki.debian.org/Teams/DebianEmacsenTeam/elpa-hello, that
  we could maybe also run at build time.

[Quality assurance - packaging]
- debian/watch is present and works
- This package does not yield massive lintian Warnings, Errors
  => out-of-date-standards-version could/should be updated
- Link to recent build log including a lintian run https://paste.ubuntu.com/p/4GRz5zJS8w/
- Lintian overrides are present, but ok because debian/watch is present, even
  though this is a native package, but watchfile is used with pkg-emacsen PET
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default
- Packaging and build is easy, link to d/rules https://paste.ubuntu.com/p/km3WdffNcJ/

[UI standards]
- Application is not end-user facing (does not need translation)

[Dependencies]
- No further depends or recommends dependencies that are not yet in main

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

[Maintenance/Owner]
- Team is not yet, but will subscribe to the package before promotion
  => I suggest the desktop team to take care of this package, as it is an
     abstraction layer above emacsen-common, that is being owned by the desktop
     team.
- This does not use static builds
- This does not use vendored code

[Background information]
- The Package description explains the package well
- Upstream Name is dh-elpa
- Link to upstream project https://salsa.debian.org/emacsen-team/dh-elpa
- This package is a native Debian package, created & maintained by the Debian
  Emacsen team.

[TODO]
I suggest the following TODOs before this is ready for promotion:
- subscribe ~desktop-packages (as this is a higher level abstraction of
  emacsen-common)
- merge the latests upstream version from Debian
- update the standards version
- add an autopkgtests to build a simple "elpa-hello" package, as described in
  https://wiki.debian.org/Teams/DebianEmacsenTeam/elpa-hello

Lukas Märdian (slyon)
Changed in dh-elpa (Ubuntu):
status: Incomplete → New
Changed in dh-elpa (Ubuntu):
status: New → Incomplete
Lukas Märdian (slyon)
tags: added: update-excuse
Lukas Märdian (slyon)
description: updated
Changed in dh-elpa (Ubuntu):
status: Incomplete → New
Revision history for this message
Lukas Märdian (slyon) wrote :

Adding a patch that resolves most of the TODO

Changed in dh-elpa (Ubuntu):
assignee: nobody → Christian Ehrhardt  (paelzer)
Changed in cmake (Ubuntu):
status: New → Invalid
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI: Pulling also dh-elpa would trigger a bunch of further dependencies in universe, so this really is a no.go: libdebian-source-perl, dh-make-perl, emacs-nox, libarray-utils-perl, libconfig-tiny-perl

But since you already said dh-elpa-helper is enough I'll focus on that

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI: The debdiff really LGTM to resolve most of the weak points

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (3.3 KiB)

Review for Package: dh-elpa

[Summary]
A small helper (for build time), well packaged and up top date.
The weak self-tests already got identified by the reporter and adressed
upfront (thanks).
I found nothing else that seems to be concerning.

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does not need a security review

List of specific binary packages to be promoted to main: dh-elpa-helper
Specific binary packages built, but NOT to be promoted to main: dh-elpa

Required TODOs:
- Please finish and upload your improvements (primarily testing)
- Please sort out if Desktop or Foundations will subscribe to this
  on promotion of the package

Recommended TODOs:
- None

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this (as long as we keep it reduced
  to dh-elpa-helper)
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- 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 (minmally and only build time)
- 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
- if special HW does prevent build/autopkgtest is there a test plan, code,
  log provided?
- if a non-trivial test on this level does not make sense (the lib alone
  is only doing rather simple things), is the overall solution (app+libs)
  extensively covered i.e. via end to end autopkgtest ?
- no new python2 dependency

Problems:
- As already identified by Lukas and suggested with a debdiff, tests are weak
  but can be added.

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under
  control
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok (if needed, e.g. non-native)
- Upstream (Debian = upstream) update history is good
- Ubuntu update history is ok
- the current release is packaged (as part of the provided debdiff
  that will be uploaded before promoting this one)
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

[Upstream red flags]
OK:
- no Errors/warnings during the build
- 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 (cra...

Read more...

Changed in dh-elpa (Ubuntu):
status: New → Incomplete
assignee: Christian Ehrhardt  (paelzer) → nobody
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Status => Incomplete until the agreed required TODOs are resolved.
Then ready for promotion.

Revision history for this message
Lukas Märdian (slyon) wrote :

So I've uploaded my proposed changes and also sent them upstream to Debian.

The desktop team agreed to take ownership of this package, as per #ubuntu-desktop IRC converstation of 2021-12-10:
11:59 <slyon> Hey Desktop team! I am wondering if you'd be willing to take ownership of dh-elpa in "main" (LP: #1951066) – myself/foundations did the MIR, uploaded a new version of the package to have it in good shape (incl. adding an autopkgtest, c.f. https://bugs.debian.org/1001452)
11:59 <ubottu> Launchpad bug 1951066 in dh-elpa (Ubuntu) "[MIR] dh-elpa" [Undecided, Incomplete] https://launchpad.net/bugs/1951066
11:59 <ubottu> Debian bug 1001452 in dh-elpa "dh-elpa: Adding a basic autopkgtest" [Wishlist, Open]
11:59 <slyon> It popped up as a cmake component-mismatch, that's why foundations took the
11:59 <slyon> initial steps. But this is essentially a layer above the emacsen-common (i.e.
11:59 <slyon> cmake switched from using emacsen-common directly to using the dh-elpa-helper).
11:59 <slyon> emacsen-common is mantained by Desktop, currently.
12:27 <seb128> slyon, hey, thanks for doing the MIR work. Seems fair for desktop to own it since we maintain emacs yes
13:20 <slyon> thanks!

Changed in dh-elpa (Ubuntu):
status: Incomplete → New
Lukas Märdian (slyon)
no longer affects: cmake (Debian)
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Great,
all seems to be in place then, pelase:
1. get Desktop to subscribe to the PKG
2. set it to Fix Committed
3. subscribe and get in touch with an AA to promote it

Assigning to Lukas to do that

Changed in dh-elpa (Ubuntu):
assignee: nobody → Lukas Märdian (slyon)
Changed in dh-elpa (Debian):
status: Unknown → New
Revision history for this message
Lukas Märdian (slyon) wrote :

Thank you for subscribing ~desktop-packages! I've marked this "Fix Commited" and assigned ~ubuntu-archive for promotion.

Changed in dh-elpa (Ubuntu):
status: New → Fix Committed
Revision history for this message
Steve Langasek (vorlon) wrote :

Override component to main
dh-elpa 2.0.9ubuntu1 in jammy: universe/misc -> main
dh-elpa 2.0.9ubuntu1 in jammy amd64: universe/devel/optional/100% -> main
dh-elpa 2.0.9ubuntu1 in jammy arm64: universe/devel/optional/100% -> main
dh-elpa 2.0.9ubuntu1 in jammy armhf: universe/devel/optional/100% -> main
dh-elpa 2.0.9ubuntu1 in jammy i386: universe/devel/optional/100% -> main
dh-elpa 2.0.9ubuntu1 in jammy ppc64el: universe/devel/optional/100% -> main
dh-elpa 2.0.9ubuntu1 in jammy riscv64: universe/devel/optional/100% -> main
dh-elpa 2.0.9ubuntu1 in jammy s390x: universe/devel/optional/100% -> main
dh-elpa-helper 2.0.9ubuntu1 in jammy amd64: universe/devel/optional/100% -> main
dh-elpa-helper 2.0.9ubuntu1 in jammy arm64: universe/devel/optional/100% -> main
dh-elpa-helper 2.0.9ubuntu1 in jammy armhf: universe/devel/optional/100% -> main
dh-elpa-helper 2.0.9ubuntu1 in jammy i386: universe/devel/optional/100% -> main
dh-elpa-helper 2.0.9ubuntu1 in jammy ppc64el: universe/devel/optional/100% -> main
dh-elpa-helper 2.0.9ubuntu1 in jammy riscv64: universe/devel/optional/100% -> main
dh-elpa-helper 2.0.9ubuntu1 in jammy s390x: universe/devel/optional/100% -> main
15 publications overridden.

Changed in dh-elpa (Ubuntu):
status: Fix Committed → Fix Released
Changed in dh-elpa (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.