Description of the process to get eXe included in Debian, steps taken so far and problems encountered. - exelearning/iteexe GitHub Wiki

Table of Contents Open ITP bug Build and test the source package Problems pending Anticipated difficulties Embedded Libraries Copyright file

• https://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage
• http://mentors.debian.net/intro-maintainers
• https://www.debian.org/doc/manuals/maint-guide/

The process to get eXe included in Debian is:

1. Check in Work-Needing and Prospective Packages (WNPP) list that no one is already working on it, and open an Intent to Package (ITP) bug.
2. Build and test the source package
3. Upload the package to mentors.debian.net
4. Find a Debian Developer (sponsor) interested in checking out the new package and upload it on our behalf.
5. Maintain the package

An ITP bug for python-intef-exe has already been filed, with number #737654. It is tagged it with the debian-edu user tag, so this bug is listed in the Debian Edu bugs list. I expect Debian Edu is the team where we have a better chance of finding an DD interested in sponsoring us.

If the debian/changelog of the package uploaded includes the sentence Closes: #737654, this ITP bug would be automatically closed when the package gets accepted into Debian repositories.

I have tried to build a source package, following these steps:

Download the project (2.0beta2, commit 6413d41c251ded80dd35b170f54622913cb855fd), and prepare an *.orig.tar.gz file from original sources

$ git clone git+ssh://[email protected]//var/lib/gforge/chroot/scmrepos/git/iteexe/iteexe.git $ cd iteexe $ git checkout 6413d41c251ded80dd35b170f54622913cb855fd $ cd .. $ cp -R iteexe/ python-intef-exe-2.0~beta2 $ sudo rm -R python-intef-exe-2.0~beta2/.git $ sudo rm -R python-intef-exe-2.0~beta2/.gitignore $ tar -czf python-intef-exe_2.0~beta2.orig.tar.gz python-intef-exe-2.0~beta2

Set a new release on changelog and Build source package with original sources

$ debchange -b --newversion 2:2.0~beta2-1 Debian release. Closes: #737654 $ debchange -r --distribution unstable $ debuild -S -sa

Source package builds, but lintian throws some warnings that would prevent the package to be accepted.

1. python-intef-exe source: native-package-with-dash-version: Native packaging should only be used if a piece of software was written specifically to be turned into a Debian package. In this case, the version number should not contain a Debian revision part.
2. python-intef-exe source: dh_python-is-obsolete line 58: This package calls dh_python in its debian/rules file. dh_python is deprecated and has been replaced by dh_python2.
3. python-intef-exe source: debhelper-but-no-misc-depends python-intef-exe: The source package uses debhelper, but it does not include ${misc:Depends} in the given binary package's debian/control entry.
4. python-intef-exe source: missing-debian-source-format: Explicitly selecting a source format by putting the format in debian/source/format is recommended. [..] please consider switching to "3.0 (quilt)"
5. python-intef-exe source: build-depends-indep-without-arch-indep: The control file specifies source relations for architecture-independent packages, but no architecture-independent packages are built.
6. python-intef-exe source: debian-rules-missing-recommended-target build-arch: The debian/rules file for this package does not provide one of the recommended targets. All of build-arch and build-indep should be provided, even if they don't do anything for this package.
7. python-intef-exe source: debian-rules-missing-recommended-target build-indep
8. python-intef-exe source: clean-should-be-satisfied-by-build-depends debhelper
9. python-intef-exe source: ancient-standards-version 3.6.1 (current is 3.9.4)

I made some changes in debian/* to correct some of these warnings:

• Adding debian/source/format file corrects 1 and 4:

 3.0 (quilt)

• Changes to debian/control
  • Added ${misc:Depends} to Depends (3)
  • Changed Build-Depends-Indep field to Build-Depends (5, 8)
  • Changed Standards-Version value to 3.9.4 (9)

After those changes, I tried to build the source package, and a few warnings still remain:

W: python-intef-exe source: dh_python-is-obsolete line 58 N: N: This package calls dh_python in its debian/rules file. dh_python is N: deprecated and has been replaced by dh_python2. N: N: dh_python2 is available in Squeeze; if backporting the package to a N: Lenny or older system, please ignore this warning. N: N: Severity: normal, Certainty: certain N: N: Check: debhelper, Type: source N:

W: python-intef-exe source: debian-rules-missing-recommended-target build-arch N: N: The debian/rules file for this package does not provide one of the N: recommended targets. All of build-arch and build-indep should be N: provided, even if they don't do anything for this package. If this N: package does not currently split building of architecture dependent and N: independent packages, the following rules may be added to fall back to N: the build target: N: N: build-arch: build N: build-indep: build N: N: Note that the following form is recommended however: N: N: build: build-arch build-indep N: build-arch: build-stamp N: build-indep: build-stamp N: build-stamp: N: build here N: N: These targets will be required by policy in the future, so should be N: added to prevent future breakage. N: N: Refer to Debian Policy Manual section 4.9 (Main building script: N: debian/rules) for details. N: N: Severity: normal, Certainty: certain N: N: Check: rules, Type: source N:

W: python-intef-exe source: debian-rules-missing-recommended-target build-indep

 
 I: python-intef-exe source: debian-watch-file-is-missing

N: N: This source package is not Debian-native but it does not have a N: debian/watch file. This file is used for automatic detection of new N: upstream versions by the Debian External Health Status project and other N: project infrastructure. If this package is maintained upstream, please N: consider adding a debian/watch file to detect new releases. N: N: If the package is not maintained upstream or if upstream uses a N: distribution mechanism that cannot be meaningfully monitored by uscan N: and the Debian External Health Status project, please consider adding a N: debian/watch file containing only comments documenting the situation. N: N: Refer to Debian Policy Manual section 4.11 (Optional upstream source N: location: debian/watch) and the uscan(1) manual page for details. N: N: Severity: wishlist, Certainty: certain N: N: Check: watch-file, Type: source N:

• https://wiki.debian.org/EmbeddedCodeCopies
• https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Debian Policy explicity states: "If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible."

So, we have a problem here. We might try to argue that binary packages already in Debian are too different from the copies included in eXe, so it is not possible for us to use them.

As long as we ship third party code with eXe we must state its copyright and license in debian/copyright file. Juan Rafael's Analysis of the Libraries Used in eXe document is very useful, but some copyright and authoring information is missing and should be updated.