= My unsorted Ubuntu packaging and maintenance FAQ =
(incl. even more - somewhat related - topics)
== Help ==
* Need to reach out to the SRU team?
* join IRC channel #ubuntu-release and ask, highlight 'ubuntu-sru'
* or reach out to the SRU team member on duty (Ubuntu SRU Shift tracker)
https://calendar.google.com/calendar/u/0/embed?src=c_vss4l1h120lm53b7s978rgno88@group.calendar.google.com&ctz=Europe/Berlin
* Have question or need help on the current development release?
* join IRC channel #ubuntu-devel or better #ubuntu-release on Libera.Chat and highlight using 'plusone'
* +1 Maintenance duty ([[https://wiki.ubuntu.com/PlusOneMaintenanceTeam|+1 Maintenance Team]], [[https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Basics|Basics]])
https://calendar.google.com/calendar/u/0/embed?src=canonical.com_ebb5nmcc6hflbue6jma2v0dkl0@group.calendar.google.com&ctz=Europe/Berlin
* In case an upload for the development release is stuck in the upload queue, or needs special approval (like s390-tools*, due to needed signing), contact an Archive Admin / AA (#archive-admins) or someone from the RT (#release-team) and ask for help / approval at '#ubuntu-devel'. <
> The unapproved queue for the development release is usually empty, therefore it's not reviewed that often. Hence it's not unusual that pinging the [[https://launchpad.net/~ubuntu-archive|archive admins]] is needed to get uploads like s390-tools approved/unblocked/going ...)
* Have a question or need help with universe packages?
* join IRC channel #ubuntu-motu and ask
* find a [[https://launchpad.net/~motu|motu]] (or [[https://launchpad.net/~ubuntu-core-dev|core-dev]])
* Patch Pilot Program <
>
[[https://ubuntu.com/community/contribute/ubuntu-development/ubuntu-patch-pilots|Ubuntu Patch Pilots]]
== Terms ==
Some important terms (with each more info below):
* transition
multiple source packages must migrate together to keep the archive installable
(and I would add 'and to keep the combo of such packages working')
https://people.canonical.com/~ubuntu-archive/transitions/
* proposed migration
migrating packages from -proposed to release
https://wiki.ubuntu.com/ProposedMigration
* sync
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/Syncs.md
copies a source package verbatim from an external repository into Ubuntu, overwriting any package of the same name
* merge
https://wiki.ubuntu.com/UbuntuDevelopment/Merging
is a three-way merge of a package which originated in an external repository.
This is used when there is a newer version available from the external repository,
but the package has also been modified in Ubuntu ( Merge-o-Matic assists)
* consistency checks:
* incorrect dependencies
* uninstallable packages: <
>
https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy_uninst.txt
* binary packages that are no longer built by a source package: <
>
https://wiki.ubuntu.com/UbuntuDevelopment/NBS
* source package:
* To be precise, the .dsc file (the 'Debian source control' file) only describes the source package.
The .dsc file itself is part of the source package.
The source package itself is a set of files, like in this example:
* the upstream (or orig) tar-ball "bash_4.2.orig.tar.gz"
* the tar-ball with all upstream changes and the debian packaging files "bash_4.2-2ubuntu2.diff.gz";
depending on the used format this would nowadays be a "bash_4.2-2ubuntu2.debian.tar.gz"
* and the .dsc file, "bash_4.2-2ubuntu2.dsc"
* References:
* https://wiki.debian.org/dsc
* https://wiki.debian.org/Packaging/SourcePackage
* https://wiki.debian.org/Packaging/SourcePackage?action=show&redirect=SourcePackage
== +1 Maintenance ==
* ensures that the development release stays in an installable state
and that the archive is usable throughout the cycle.
* primary goal is to maintain archive-level quality throughout the development cycle to minimize roadblocks
for people developing features for the next release, and to ease the preparation of milestones.
* References:
* https://wiki.ubuntu.com/PlusOneMaintenanceTeam
* https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Specs/Priorities
* https://calendar.google.com/calendar/u/0/embed?src=canonical.com_ebb5nmcc6hflbue6jma2v0dkl0@group.calendar.google.com&ctz=Europe/Berlin
* In case help is needed with the development release,
got to #ubuntu-release on Libera.Chat and highlight the call sign 'plusone'.
== Ubuntu Release Process ==
* References
* https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess
* https://wiki.ubuntu.com/ReleaseSchedule
* Each Ubuntu release cycle follows a similar pattern, with the phases listed below.
UbuntuDevelopers need to align their work to these.
* 8 Phases:
* Beginning a new Release (toolchain, seeds)
* Planning (specs, ideas)
* Merging with Upstream (syncs, merges until Debian Import Freeze)
* Feature Development (oerlap usually with mergig, spec implementation)
* Stabilization (Freeze) (greater caution towards release, queued uploads, FFe)
* Milestones (images for alpha, beta, RC)
* Finalization (only fixing showstopper/severe bugs, crashes, install issues)
* Stable Releases (SRU - stable release update process starts)
== SRU / Stable Release Update process ==
* References:
* https://wiki.ubuntu.com/StableReleaseUpdates
* https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
* https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
* https://people.canonical.com/~ubuntu-archive/pending-sru.html
* Once an Ubuntu release has been completed and published,
updates for it are only released under certain circumstances,
and must follow a special procedure called a "stable release update" or SRU.
* An important part of the SRU process is the (SRU) Verification.
=== SRU Verification ===
* References:
* https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
* https://wiki.ubuntu.com/StableReleaseUpdates#Verification
* find bugs that need a verification, by
* viewing the Pending Ubuntu SRUs (http://people.ubuntu.com/~ubuntu-archive/pending-sru.html),
* asking aptitude from the command-line: "aptitude search ~i~Aproposed"
* querying Launchpad for a specific release (here lucid) and the bug tag verification-needed
(https://launchpad.net/ubuntu/focal/+bugs?field.status%3Alist=FIXCOMMITTED&field.tag=verification-needed), or
* looking at bugs which the SRU verification team is subscribed
(https://bugs.launchpad.net/~sru-verification/+subscribedbugs)
* pending SRUs are generated by parsing the changelogs of the packages in -proposed
* more SRU related tags: https://wiki.ubuntu.com/QATeam/PerformingSRUVerification#Tagging_the_report
== Freeze ==
* References:
* https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Freezes
* https://wiki.ubuntu.com/FeatureFreeze
* https://wiki.ubuntu.com/FreezeExceptionProcess
* types of freezes:
* https://wiki.ubuntu.com/FeatureFreeze
* https://wiki.ubuntu.com/UserInterfaceFreeze
* https://wiki.ubuntu.com/DocumentationStringFreeze
* https://wiki.ubuntu.com/KernelFeatureFreeze
* https://wiki.ubuntu.com/HardwareEnablementFreeze
* https://wiki.ubuntu.com/KernelFreeze
* https://wiki.ubuntu.com/FinalFreeze
* There are two kinds of freezes, "soft" and "hard" freezes.
* 'soft'
Soft freezes have no mechanism in the archive software to enforce them,
they just rely on each developer to ensure that they only upload appropriate changes.
For instance, FeatureFreeze is a soft freeze, as you can still upload as before,
you are just required to seek exceptions for new features.
* 'hard'
In contrast to soft freezes hard freezes flick a switch in the archive software
such that all uploads are not immediately accepted,
they instead end up in the UNAPPROVED Queue.
Packages remain in this queue until they are explicitly accepted by an Archive Administrator.
This means that your changes can be reviewed before they are accepted,
so that extra review can be done, and it is not left to your discretion
to enforce the rules of the freeze. The 'final freeze' is such a freeze.
* On IRC, the topic of #ubuntu-devel on Libera Chat is generally updated to indicate the current freeze status.
* And there are usually also mails send out to the appropriate -announce mailing lists, too.
== FFe ==
* References:
* https://wiki.ubuntu.com/FeatureFreeze
* https://wiki.ubuntu.com/FreezeExceptionProcess
* Example:
[FFe] [UBUNTU 22.04] ibmca engine with libica = libica.so.4 - sshd dumps core (openssl-ibmca)
https://bugs.launchpad.net/bugs/1967141
> openssl-ibmca (2.2.3-0ubuntu1) jammy; urgency=medium
* New upstream release. LP: #1967141
* The difference between 2.2.2 and 2.2.3 includes just these two fixes:
+ "PKEY: Fix usage of ECX keys"
+ "use correct libica for ibmca_mechaList_test"
Rather than adding these as quilt patches, raising the package to the
bugfix-only version that incl. them is preferable.
* For "PKEY: Fix usage of ECX keys" a backport of
"Fix compilation for OpenSSL 3.0" was needed:
d/p/e59cce5-Fix-compilation-for-OpenSSL-3.0.patch
* For convenience reasons a generated sample config is now included in
the package, but also the optional configuration generator Perl script
'ibmca-engine-opensslconfig'.
* d/control: add dh-autoreconf to Build-Depends to work around a Lintian
regression on missing-build-dependency-for-dh-addon
== Sponsoring / Sponsorship / Sponsors ==
* References:
* https://wiki.ubuntu.com/SponsorshipProcess
* https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship
* https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
* https://launchpad.net/~ubuntu-sponsors
* https://launchpad.net/~ubuntu-security-sponsors
* sponsoring queue: http://sponsoring-reports.ubuntu.com <
> old URL: http://reports.qa.ubuntu.com/reports/sponsoring/ is dead)
* Sponsoring dashboard: <
> https://ubuntu-release.kpi.ubuntu.com/d/yIC34LpGk/ubuntu-metrics?orgId=1&from=now-6M&to=now
* notes for contributors: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
* to the worked based on an LP bug
* attach a fix (or even debdiff)
* subscribe ubuntu-sponsors (or ubuntu-security-sponsors in case of security patches)
* don't assign the bug to anyone if it needs sponsorship
(the sponsor usually assign it to him-/her-self in case he/she picks it up)
* pending (sponsorship) requests:
* https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-sponsors
* https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-sponsors&field.component=3&field.component=4
* https://bugs.launchpad.net/~ubuntu-security-sponsors/+subscribedbugs
* or all at once at this report: http://sponsoring-reports.ubuntu.com/index.html !!!
== Package Uploads ==
* References:
* https://wiki.ubuntu.com/UbuntuDevelopment/Uploading !!!
* https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Uploading
* https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Uploading_Restrictions
* my prefered tool is 'dput'
* dput ubuntu foo_1.0-0ubuntu1_source.changes # for people with upload superpowers
* dput ppa:lpid/ppa-name foo_1.0-0ubuntu1_source.changes
* upload must be signed by a GPG key registered in Launchpad (otherwise upload will be silently ignored)
* uploads will land in the upload queue https://launchpad.net/ubuntu/focal/+queue and will be checked and approved (or rejected) the the archive admins
* build will take minutes up to hours, depending on the package and architecture (arm kernel 10+h)
* after successful buils the next 'publisher' run that starts at 3 and 33 minutes past each hour makes it available
* new packages will be announced at the appropriate mailing list, like: https://lists.ubuntu.com/archives/focal-changes/
* The changelog are available here: http://changelogs.ubuntu.com/changelogs/ or better:
https://launchpad.net/ubuntu/+source//+changelog or even:
apt changelog
* Make source-only uploads, i.e. use "dpkg-buildpackage -S"
If you need to include the orig tarball as well, use parameters -S -sa
== Proposed migrations ==
* References about proposed migrations:
* https://wiki.ubuntu.com/ProposedMigration
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/ProposedMigration.md
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageTests.md
* https://wiki.ubuntu.com/ProposedMigration#How_to_re-run_autopkgtests_with_dependencies_on_other_packages_in_the_proposed_pocket
* https://autopkgtest-cloud.readthedocs.io/en/latest/
* https://packaging.ubuntu.com/html/auto-pkg-test.html
* Uploads to the Ubuntu development series are routed through the -proposed pocket, <
>
and must build there and pass certain tests before they are promoted to the release pocket for general use.
* '-proposed' is a partial suite, means it only contains packages that have not yet migrated
* hence it must must be used in combination or on top of the release pocket
* A package will migrate from proposed to release if:
https://wiki.ubuntu.com/ProposedMigration#Migrating_packages_from_-proposed_to_release <
>
a) package must be built and published on all archs (like in release pocket) <
>
b) all deps must be satisfiable with packages from release, or with packages that are going to be installed at the same time (probably in -proposed as well (transition) <
>
c) all potential tests of the package, it's binaries or of it's reverse deps must must pass (or have never passed "Always failed") <
>
d) no bugs with 'block-proposed' are opened against the package <
>
e) moving the package to the release pocket must not break any packages that are already in release <
>
* If a)-c) applies the package is a 'valid candidate', otherwise 'not considered'.
* main work (for me, atm) are that failed tests block the migration,
and "Regression" is listed for the failed architecture(s)
* Further reasons that prevent a proposed migration:
* everything is fine, but no verification done yet (SRU only)
* "main/universe binary mismatch" - a source package may have some binaries in main and others in universe, but this can get mixed up for various reasons. This is known as "component mismatches" (and is related to IR).
* "impossible depends" - in case the dependent and depending packages are in different areas of the archive (one in main and the other in universe)
* "migrating makes something uninstallable" - dependency to an old package version; no-change rebuild may help
* "depends: a [b] (not considered)" - 'a' is blocked because it depends on 'b', however 'b' is either invalid or rejected
* "implicit dependency: a [b]" - implicit dependency is a pseudo dependency where Breaks/Conflicts creates an inverted dependency
* "implicit dependency: a [b] (not considered)" - same than above, but 'b' is also either invalid or rejected
* "has no binaries on arch" - package has either failed to build or failed to upload the binaries for a build
* "has no binaries on any arch (- to x.y.z)" - package doesn't have a current version, this error can indicate the package is not (yet) in the archive, or it can mean its binaries were removed previously but not sync-blacklisted and thus reappeared
* "flaky tests, hardware instabilities, and intermittent network issues" -
* "test Dependency Irregularities" - issues in debian/tests/control
* "test Framework Timeouts and Out of Memory" - big_packages / long_tests at https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
* Disabling/skipping tests
* Disabling/skipping/customizing tests for certain architectures
* Skipping autopkgtesting entirely
* autopkgtest failed to download material from the internet (e.g. pip or Maven)
* proposed migrations are tracked at:
* for a release in development:
https://people.canonical.com/~ubuntu-archive/proposed-migration/kinetic/update_excuses.html
or just:
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
* for stable releases:
https://people.canonical.com/~ubuntu-archive/proposed-migration//update_excuses.html
like:
https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html
* The above pages (and more: https://people.canonical.com/~ubuntu-archive/proposed-migration/) <
>
are frequently re-generated (about every 3h) by a tool called 'britney':
* https://wiki.ubuntu.com/ProposedMigration#Additional_information
* https://code.launchpad.net/~ubuntu-release/britney/britney1-ubuntu
* https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu
* The 'update_excuses' pages are ordered newest to oldest, but Ctrl+f is your friend here.
* autopkgtest regressions are the main things to be fixed there, fixes can be manyfold, like: <
>
just re-trigger, add a fix, sync/merge a new version that incl. a fix (devel only), <
>
no-change rebuilds, increased resources (more RAM 'big_packages' more time 'long_tests'), etc. <
>
Tests that have always failed can also be skipped with the help of 'never_run'. <
>
For the last three cases see the [[https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/tree/README.md|README.md]] here: <
>
https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
* Example of an MP to add a modification for a package to 'autopkgtest-package-configs':
https://code.launchpad.net/~fheimes/autopkgtest-cloud/+git/autopkgtest-package-configs/+merge/429252
* Not everyone is able to re-trigger autopkgtests on 'update_excuses', <
>
even if a re-trigger symbol is visible and clickable (--> LP#1953374). <
>
Ask ask core-devs in case an autopkgtest retrigger is needed <
>
(and you don't have the superpower to do that yourself). <
>
In case of an SRU, one usually needs to reach out to IRC #ubuntu-release, <
>
But since most of the core-devs are in #ubuntu-devel, <
>
it might be more promising to ask there, even in case of an SRU. <
>
It's a good habit to have the retrigger URLs well prepared and share with the help of pastebin, for example: <
>
"Please could someone from the core-devs re-trigger this autopkgtest for me: <
>
https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=ppc64el&package=casync&trigger=zlib%2F1%3A1.2.11.dfsg-2ubuntu9.1
It failed with a timeout on one architecture only, hence it might be a flaky test and worth to re-try - thx!" <
>
(In case of multiple URLs to re-try, put them in a pastebin and share the link.)
* Is in case a fix is needed to solve a problem with a proposed migration, <
>
it's best to not add this package to fix to the existing bug (and mark it as also affects...), <
>
but always open a separate LP bug in such a case, <
>
otherwise getting the regressions solved can become very difficult... <
>
(imagine there is a block due to package A in LP bug X, but unblock is not easily possible, <
>
because it would count for all packages B, C,... that are marked as affected by a single LP bug X).
* If a (static) library was changed (and with that it's API/ABI) and a no-change rebuild is required, <
>
open a separate LP bug, always add the LP bug number as a reference to the changelog <
>
(even if this does not seem to done for all no-change rebuilds, <
>
otohs SRU bug/upload always require a bug reference) <
>
and add an update-excuse tag. <
>
Then get this sponsored and uploaded, once in -proposed re-trigger autopkgtests accordingly.
* Changed dynamic libraries usually only require a re-trigger with pointing the the new/fixed version
(see below).
* References on re-triggering tests:
* https://wiki.ubuntu.com/ProposedMigration#How_to_re-run_autopkgtests_with_dependencies_on_other_packages_in_the_proposed_pocket
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/ProposedMigration.md#autopkgtest-regressions
* https://autopkgtest-cloud.readthedocs.io/en/latest/architecture.html#test-request-formatsee
* 'update_excuses' (aka 'britney') tests are by default done against the -release/-update pockets.
* Just the 'package that is under test' is taken from the -proposed pocket.
* But if a test should done entirely under -release/-update pocket conditions,
especially including the 'package under test', this can be forced by adding the URL suffix: <
>
"&trigger=migration-reference/0". <
>
And if the test fails with the "migration-reference/0", <
>
the test will be ignored for the proposed-migration <
>
and it will vanish from the update_excuses page.
* In case more dependencies/packages from -proposed are needed for a test, <
>
these need to be explicitly named by a suffix like this: <
>
"&trigger=PKG_NAME/PKG_VER" <
>
(whereas with 'PKG_NAME' only and no 'PKG_VER', the package will be taken from -release/-update by default,
but with 'PKG_VER' pointing to the version of 'PKG_NAME' as it is in -proposed, it will be taken from there)
- example:
https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=s390x&package=htslib&trigger=zlib%2F1%3A1.2.11.dfsg-2ubuntu1.4
the 'package under test' is 'htslib' (package=htslib) <
>
on architecture 's390x' (arch=s390x) <
>
for Ubuntu release 'focal' (release=focal) <
>
that is tested with a dependent package 'zlib' (also triggered by 'zlib'). <
>
Since this 'zlib' package comes with an explicit version '1:1.2.11.dfsg-2ubuntu1.4' <
>
(aka 'zlib%2F1%3A1.2.11.dfsg-2ubuntu1.4'), this zlib is highly likely from proposed.
* If one now wants to retry a test using another lib version from -proposed <
>
(rather than by default the one from -release/-update) <
>
and additional "&trigger=PKG_NAME/PKG_VER" needs to be appended. <
>
Example: <
>
https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=s390x&package=libbio-samtools-perl&trigger=zlib/1%3A1.2.11.dfsg-2ubuntu1.4&trigger=htslib/1.10.2-3ubuntu0.1&trigger=libbio-samtools-perl/1.43-2build2
* Notice that if a re-trigger is needed for all architectures (like amd64, ppc64el, arm64 and s390x), <
>
there is no way to do that with one URL, this requires four re-trigger URLs <
>
(there is no such thing like a --(&arch=s390x)--).
* Notice that 'britney' schedules the jobs every couple of hours, <
>
so it may/will take some time until you see the changes reflected at the 'update_excuses' page.
* Sometimes it can happen by coincidence that in parallel to your new package upload, <
>
and the resulting proposed-migration, that larger changes for example in the tools-chain were done, too <
>
(like an upgrade to a new compiler). <
>
This may cause even more regressions, which may not be caused by your upload: Well, that's 'bad luck' :-/
* For testing against a PPA a suffix like this is needed '&ppa=LPUSER/PPA&trigger=SRCPKG/VERSION' <
>
Example: <
>
https://autopkgtest.ubuntu.com/request.cgi?release=RELEASE&arch=ARCH&package=SRCPKG&ppa=LPUSER/PPA&trigger=SRCPKG/VERSION
The results of a completed tests are available here: <
>
https://autopkgtest.ubuntu.com/results/autopkgtest-RELEASE-LPUSER-PPA/?format=plain
* Sometimes a proxy is needed in case a test behaves differently using a proxy, see here: <
>
https://wiki.ubuntu.com/ProposedMigration#I.27m_seeing_a_squid_proxy.3F__My_tests_behave_differently_there.21
https://pastebin.ubuntu.com/24875282/
* In order to indicate some investigations or work on a regression <
>
or problem a package has to migrate off -proposed, one may open a bug and tag it with:
* with 'update-excuse' for the release currently in development
* with 'update-excuse-' for stable releases (update-excuse-focal)
This makes the tagged LP bug linked from the update excuses page under the package. <
>
Example of an update-excuse bug: <
>
https://bugs.launchpad.net/bugs/1988352
* One may see the autopkgtest job running here: <
>
https://autopkgtest.ubuntu.com/running
* One may find the autopkgtest test results here: <
>
Example: <
>
https://autopkgtest.ubuntu.com/packages/libb/libbio-samtools-perl/focal/s390x
* And the initial proposed-migration ('zlib' here), that trigger the autopkgtest, will be updated: <
>
https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#zlib
* 'block-proposed' tag - a bug that should be held back from migrating into the release pocket <
>
(e.g. because build fails, causes an FTBFS, causes issue on dependent packages, <
>
requested by upstream -for whatever reason [liboqs])
* 'block-proposed-' tag - a bug that should be held back being released into <
>
the updates pocket for the corresponding stable series (e.g. due to staging)
* uploads providing only test fixes will generally be staged/phased using block-proposed-
== autopkgtests ==
* References:
* https://autopkgtest.ubuntu.com/
* https://autopkgtest.ubuntu.com/running
* https://packaging.ubuntu.com/html/auto-pkg-test.html
* https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageTests.md
* https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst
* There can be several issues/regressions with autopkgtests:
* real regression: a real issue caused by the upload of the new package, set tag 'verification-failed'
* not a real regression: maybe just broken by some other deps; commenting on SRU bug; SRU team could add a badtest or reset-test
* flaky test: rerun, or analyze and argue that it's not related to the package
* it's the uploader's responsibility to make sure the package is in a releasable state and that all the autopkgtests triggered by the upload are either passing or badtested
* lp-test-ppa from https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers offers some help:
lp-test-ppa --showurl ppa:kstenerud/postfix-postconf-segfault-1753470 --release bionic
* The '--showurl' parameter prints out the URL, so that they can be cut-and-paste into email or chat. * using KVM:
* autopkgtest-buildvm-ubuntu-cloud -r focal -v --cloud-image-url http://cloud-images.ubuntu.com/daily/server
* autopkgtest -U -s -o dep8-mypackage mypackage/ -- qemu /var/lib/adt-images/autopkgtest-focal-amd64.img
* using LXD:
* autopkgtest-build-lxd images:ubuntu/impish/amd64
* autopkgtest -U -s -o dep8-mypackage mypackage/ -- lxd autopkgtest/ubuntu/focal/amd64
* using a PPA: --setup-commands="sudo add-apt-repository -y -u -s ppa:mylaunchpaduser/focal-mypackage-fixed-something-1234567"
* on Canonistack (which is closest to real autopkgtests)
autopkgtest --no-built-binaries --apt-upgrade --setup-commands setup-testbed --shell-fail systemd_247.3-1ubuntu2.dsc -- ssh -s nova -- --flavor m1.small --image ubuntu/ubuntu-focal-daily-s390x-server-20221023-disk1.img --keyname fheimes_canonistack-bos01
* by default: est will run against all packages in release plus the new candidate from proposed:
'--apt-pocket=proposed=src:' or '--apt-pocket=proposed=src:srcpkg1,srcpkg2'
* run against all packages that are in proposed:
'--apt-pocket=proposed'
* in case a test requires a proxy one may add:
--env "http_proxy=http://squid.internal:3128" --env "https_proxy=http://squid.internal:3128" --env "no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,launchpad.net,10.24.0.0/24"
== Phasing / Staging / phased_updates ==
* References:
* https://people.canonical.com/~ubuntu-archive/phased-updates.html
* https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
* https://code.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides
* https://bazaar.launchpad.net/~ubuntu-sru/+junk/phased-update-overrides/view/head:/phased-updates-overrides.txt
* https://wiki.ubuntuusers.de/Aktualisierungen/phased_update/
* If a package gets released to -updates, it is not immediately in -updates for everyone, the update is rather phased in steps of 10% of the user base, increased every 6 hours, so that a successful phased update will be completed after 54 hours or ~2 days.
* This is to ensure quality, since it allows to monitor for regressions, indicated by an increased error rate, so that the update process can be halted in worst case.
* The progress is tracked here: https://people.canonical.com/~ubuntu-archive/phased-updates.html
== Merge proposals for package updates ==
* It's recommended to do a quick self review of your merge proposal for a package update or version bump
before declaring it as 'needs review' or as ready to be reviewed and sponsored:
* Merge Proposal Reviewing
https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/MergeProposalReview.md
* Initial Review of the diff / debdiff
* Check the changelog:
* Contains bug pointer, like '(LP: #1234567)'
* Proper version change: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
* Proper distribution: not unstable, not a Debian release name
* Lists ideally all files changed
* quilt patches with 'fuzz' are not allowed and need to be fixed/refreshed
* refresh of quilt patches to solve 'offsets' should be at done at max if working on '-devel'
(so for PATCHES, not for SRUs) or to fix a fuzz
* Proper author & email
* make the changelog clear and crisp - ideally "grep-able" with key words, file names, etc.
* Following the dep-3 http://dep.debian.net/deps/dep3/ for quilt patches:
Description:
Author:
Origin: ,
Bug:
Bug-:
Forwarded:
Applied-Upstream:
Reviewed-by:
Last-Update: 2021-11-19
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Example(s):
"
Update Surface_X11.cxx
Runtime selection of ARGB XImage byte order
Author: johnmartin-oracle <55413843+johnmartin-oracle@users.noreply.github.com>
Origin: upstream, https://github.com/TigerVNC/tigervnc/pull/1084/commits/7ab92639848a6059e2b6b88499b008b9606f3af6
Bug-IBM: Bugzilla 192826
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1929790
Applied-Upstream: v1.11.90
Reviewed-by: Frank Heimes
Last-Update: 2021-09-20
"
or this:
"
Description: EP11: Dilithium: Specify OID of key strength at key generation
Newer EP11 firmware versions require that the OID of the desired
Dilithium key strength is specified with attribute CKA_IBM_PQC_PARAMS
at key generation. Older firmware versions ignore this attribute.
Author: Ingo Franzki
Origin: backport, https://github.com/opencryptoki/opencryptoki/commit/6759faed4c7a2e154ca2f2c56a5b51aec68227fc
Bug-IBM: Bugzilla 198153
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1973296
Forwarded: not-needed
Applied-Upstream: 3.18
Reviewed-by: Frank Heimes
Last-Update: 2022-05-13
"
* Check the commits:
* Patches / changes are logically split into separate git commits (d/p)
* in case a package was never touched by Canonical for Ubuntu
(hence has no 'ubuntu?' in its version), but now needs to be,
the tool 'update-maintainer' tool needs ot be called which will modify debian/control
which then needs to be committed as well (as separate commit) (d/control)
Maintainer: Ubuntu Developers
XSBC-Original-Maintainer: Debian S/390 Team
* changelog is usually the last commit (d/changelog)
* Check the files:
Only files inside the debian directory must be modified!
* Review Template
[ https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/MergeProposalReview.md ]
The following template may come useful when submitting reviews:
* Changelog:
* [ ] old content and logical tag match as expected
* [ ] changelog entry correct version and targeted codename
* [ ] changelog entries correct
* [ ] update-maintainer has been run
* Actual changes:
* [ ] no upstream changes to consider
* [ ] no further upstream version to consider
* [ ] debian changes look safe
* Old Delta:
* [ ] dropped changes are ok to be dropped
* [ ] nothing else to drop
* [ ] changes forwarded upstream/debian (if appropriate)
* New Delta:
* [ ] no new patches added
* [ ] patches match what was proposed upstream
* [ ] patches correctly included in debian/patches/series
* [ ] patches have correct DEP3 metadata / header (incl. working URL for field Origin)
* Build/Test:
* [ ] build is ok
* [ ] verified PPA package installs/uninstalls
* [ ] autopkgtest against the PPA package passes
* [ ] sanity checks test fine
* Other:
* [ ] LP bug public
* [ ] LP bug affects the correct package(s)
* If there is now everything is prepared:
* change the MP from "work in progress" to "needs review"
* (on change to 'needs review' you'll get a notification mail)
* and check (again) that the correct reviewer is set
* and check (again) that a 'Related bug(s)' is assigned
* change the LP bug status to "In Progress"
* a SRU template was added to the LP bug (not needed for development release patches)
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template ]
* subscribe the "ubuntu-sponsors" LP group to the LP bugs (since sponsorship is needed)
https://launchpad.net/~ubuntu-sponsors
* ask someone to review and sponsor (maybe informally)
* add a tag for the ubuntu release, like 'focal'
* crossing fingers that everything is okay ...
* If the reviewer / sponsor is happy and uploaded the changes,
he/she usually adds a comment to the ticket, like:
"
Thanks. I fixed up a small lintian warning about the changelog entry being longer than 80 chars.
Other than that, LGTM. Uploaded.
"
* If the updated package has arrived at the ubuntu release unapproved queue:
https://launchpad.net/ubuntu/jammy/+queue?queue_state=1
https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=s390-tools
* SRU package upload is stuck
In case an SRU package upload is stuck in the upload queue for several days (e.g. 1+ week),
join the IRC channel #ubuntu-release and ask the SRU team kindly for having a look at this specific package,
by using the tag "ubuntu-sru", ideally adding the URL and ask for approval.
But better double check the status before using rmadison:
$ rmadison qclib | grep jammy
qclib | 2.3.0-0ubuntu1 | jammy/universe | source, s390x
compare with:
# https://launchpad.net/ubuntu/jammy/+queue?queue_state=1&queue_text=qclib
qclib (source) 2.3.0-0ubuntu1.1 universe libs medium Proposed
* Example, write:
"@ubuntu-sru Hi SRU team, the qclib package is for quite a while in the jammy unapproved queue.
Would you be so kind to have a look at it and ideally approve?"
* Don't forget to be thankful:
"@ many thx (just received the notification ...)"
* So use the IRC channel: #ubuntu-release
Highlight with "ubuntu-sru" - the SRU team member should have a notification enabled for this keyword
(similar to "ubuntu-archive", "ubuntu-release", "ubuntu-sponsors", ...)
* Sometimes it might be needed to directly ping the SRU team member that's on duty directly
(for example in urgent cases):
https://calendar.google.com/calendar/u/0/embed?src=c_vss4l1h120lm53b7s978rgno88@group.calendar.google.com&ctz=Europe/Berlin
* In case of package for the development release that is stuck in the upload queue,
use again #ubuntu-release (not necessarily #ubuntu-devel), since what's basically needed
is approval from someone from the RT (release-team) or AA (archive-admins) to sign this up,
and those hang out in '#ubuntu-release'.
== Package versioning ==
* Updating a package version:
* https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/VersionStrings.md
* https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue
* No-change rebuild examples:
* SRU: 1.43-3build2 ==> 1.43-3build2.1
* PATCH: 1.43-3build2 ==> 1.43-3build3 <
>
(since it's 'no-change' do not add an Ubuntu specific version suffix 'XubuntuY')
* Ubuntu-specific examples:
* PATCH example: 0.111-1 ==> 0.111-1ubuntu1 <
>
(In such a case one need to run the 'update-maintainer' script.)
* BUT most important is to check that the upgrade path of a package is never broken. <
>
Means the package versions of the different Ubuntu releases must be in an ascending order, like: <
>
package version 'a' of Ubuntu release n-1 < package version 'b' of Ubuntu release n <
>
package version 'b' of Ubuntu release n < package version 'c' of Ubuntu release n+1 -- and so on <
>
so a < b < c <
>
In other words: ensure there is always a proper upgrade path <
>
One may use 'dpkg --compare-versions'.
* a tilde ('~') in the version string usually indicates a backport, like: 1.2.3-3ubuntu1~20.04.1
== Patch / Fix ==
* References:
* https://wiki.ubuntu.com/UbuntuDevelopment/Patches
* https://packaging.ubuntu.com/html/fixing-a-bug.html
* https://packaging.ubuntu.com/html/fixing-a-bug-example.html
* https://packaging.ubuntu.com/html/fixing-a-bug.html#submitting-the-fix-and-getting-it-included
* https://packaging.ubuntu.com/html/patches-to-packages.html
* the recommended tool to handle fixes on a package level is quilt
(especially with debian/source/format)
* build fixed package (in PPA)
* also test fixed package (autopkgtest or sometimes tests are executed as part of the build process)
* reference LP bug always in debian/changelog
* 'submittodebian'will take you through a series of steps to make sure the bug ends up in the correct place in Debian
* for Ubuntu fixes either create a debdif or a MP (depending on the team)
* think about incl. multiple fixes at once (if there are some)
* if the multiple fixes are big, think about sending individual patches or merge proposals
(in case different LP bugs exist for them, this makes things easier)
* The 'ubuntu-dev-tools' incl. some useful tools like 'what-patch' and 'edit-patch'
== Packaging ==
* Rename file during Debian install
possible with dh >= 9 and dh-exec
make the .install file executable (chmod a+x debian/package.install)
add '#!/usr/bin/dh-exec' to the top of debian/package.install
and use "source => dest", like this:
#!/usr/bin/dh-exec
debian/default.conf => /etc/my-package/start.conf
* Upload issues with dput:
Sometimes dput does not work for me in case VPN is active.
If a dput upload hangs, retry with company VPN disabled.
* Check source and deb packages with lintian using:
'lintian -EvIL +pedantic'
Make sure that at least all errors are solved, and ideally the warning, too.
* "${shlibs:Depends}" in debian/control is expanded to:
ldd on binaries + dpkg -S on the library files (+ symbols files for finer-grained dependency)
* In case it's not possible to git-ubuntu clone a package, like:
$ git-ubuntu clone zhmcclient
fatal: could not read Username for 'https://git.launchpad.net': terminal prompts disabled
03/12/2021 14:04:29 - ERROR:Unable to find an imported repository for zhmcclient.
Please request an import by e-mailing usd-import-team@lists.launchpad.net.
there are a few option options:
* sometimes the corporate vpn is causing issues,
so disable VPN (in case it's active) and retry
* Send a request by eMail to usd-import-team@lists.launchpad.net to get scapy imported.
https://lists.launchpad.net/usd-import-team/
That may take some time.
* To get it permanently imported an entry in the whitelist is needed:
https://git.launchpad.net/usd-importer
example: Merge ~fheimes/usd-importer:MIR-mdevctl into usd-importer:master
Git lp:~fheimes/usd-importer MIR-mdevctl Merge into master
https://code.launchpad.net/~paelzer/usd-importer/+git/usd-importer/+merge/395767
* Or for the time being it can be manually imported by my-/yourself:
Example: git ubuntu import libbackuppc-xs-perl -d libbackuppc-xs-perl --no-push --no-fetch
applied to scapy: git ubuntu import scapy -d scapy --no-push --no-fetch
* Meta-information embedded in patches applied to Debian packages (DEP 3 headers) <
>
http://dep.debian.net/deps/dep3/ <
>
https://dep-team.pages.debian.net/deps/dep3/ <
>
* Sometimes the Origin URL of a quilt DEP3 header, that usually points to the upstream commit, can be broken: <
>
Origin: upstream, https://github.com/ibm-s390-linux/qclib6e8a1b640daa787d4ba1361c8fb90c1cfb3874df
# it needs to be: <
>
Origin: upstream, https://github.com/ibm-s390-linux/qclib/commit/6e8a1b640daa787d4ba1361c8fb90c1cfb3874df
Notice the "/commit/" - add this manually of course BEFORE building the source package and doing the dpkg-buildpackage, dput and debdiff !!!
* Standards-version upgrade checklist (debian/control) <
>
https://www.debian.org/doc/debian-policy/upgrading-checklist.html
* Upgrade checklist for supported debhelper compat levels (debhelper-compat-upgrade-checklist, debian-helper compat) <
>
https://manpages.debian.org/testing/debhelper/debhelper-compat-upgrade-checklist.7.en.html
== Binary Patch / Fix ==
* In case a patch is needed for a package that modifies one or more binary files in a source package, quilt (as used in debian/source/format '3.0 quilt') is not longer helpful, since it does not support binary patching ("git binary diffs are not supported").
* But there are at the following options to tackle or workaround this:
* Do not patch the package, rather than lift it to the latest version (version bump), <
>
that already incl. the latest binary files.
* Ignore the commit/patch that modified binary files. <
>
(I had one case where the binary was at test/, hence didn't actively fix something, <
>
rather than added another test case. Here it was save to skip it.)
* Put updated binaries under debian/ and use debian/source/include-binaries <
>
to have them ignored by the Debian packaging tools; <
>
but one needs to copy them over (and replacing potential older versions) prior to each build. <
>
(https://manpages.debian.org/bullseye/dpkg-dev/dpkg-source.1.en.html#debian/source/include-binaries)
* Do not deal with binaries inside debian/ directory at all <
>
and encode it in base64 and decode it at build time <
>
(for example done in case smaller images or icon files are needed).
(It's usually not great - and contradictory to the philosophy of Debian source packages - to have binaries inside of a source package, but it is sometimes just needed and the case; for example in test cases.)
== New packages ==
* References:
* https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
* https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going_through_MOTU
* http://packaging.ubuntu.com/html/packaging-new-software.html#next-steps
* http://bugs.debian.org/wnpp
* https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage
* https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html
* always check if there is an ITP (intent to package) bug filed against the wnpp package in Debian
* file a LP bug
* check that it meets the Ubuntu License Policy, means copyright / licensing requirements
* tag with 'needs-packaging'
* explain where the source is hosted (and coming from)
* explain how it is licensed
* packages that meet the requirements of the Debian Free Software Guidelines
should also be requested within Debian's Work-Needing and Prospective Packages (WNPP) process
by filing a Request for Package (RFP)
* Follow http://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage
to get a new package into Debian (https://ftp-master.debian.org/new.html).
* Submitting new packages through Debian is the preferred path.
But if your package is Ubuntu-specific or can't go into Debian for some other reason,
you can submit it directly to MOTU.
(Like the s390x maintainer are vacant in Debian, but it's an s390x specific package.)
* Build (and test) new package in PPA.
* package requires debian/watch file
* package must not have any known bugs or security issues
* package should have sane debian/ content
* changelog must reference the "needs-packaging" bug
* package should be lintian clean
* package should have the homepage referenced in debian/control header
* package must be advocated by at least two ubuntu-dev members (packager can be one)
* New packages need two MOTU sign-offs (or core-devs).
* New packages are screened in detail and are finally (after upload) reviewed by an archive admin.
* Feature Freeze is the latest approval date for a new package.
== Autobuilders / Builds ==
* References
* https://launchpad.net/ubuntu/+builds
* https://launchpad.net/ubuntu/
* https://wiki.ubuntu.com/BuildDaemons
* https://launchpad.net/builders
== Sync / Merge ==
* References:
* https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#SyncingAndMerging
* https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess#Merging_with_Upstream
* https://wiki.ubuntu.com/SyncRequestProcess
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/PackageMerging.md
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/Syncs.md
* http://merges.ubuntu.com/
* https://wiki.ubuntu.com/UbuntuDevelopment/Merging
* MoM (Merge-o-Matic): https://wiki.ubuntu.com/MergeOMatic
* General
* A sync copies a source package verbatim from an external repository into Ubuntu, overwriting any package of the same name. This is used when a newer version of it is available, and should be included in Ubuntu, and happens automatically during some phases of the release cycle. To request a sync, follow the SyncRequestProcess.
* A merge is a three-way merge of a package which originated in an external repository. This is used when there is a newer version available from the external repository, but the package has also been modified (branched) in Ubuntu. Merge-o-Matic assists with this work, and the Merging page explains how and when to merge. Packages which are maintained in Bazaar can and should be merged using Bazaar itself.
* Merge (as in ubuntu-maintainers-handbook)
Server team does merges using git-ubuntu - similar to a git rebase,
where commits from one point are replayed on top of another.
* also splitting larger commits into smaller logical units,
one commit per logical unit (per bug/fix, d/changelog, d/c)
(old-style commits that lumped multiple changes)
* Start a rebase: git rebase -i lp1234567/old/debian
* Change the commit(s) you're going to split from pick to edit.
* git reset to get your changes back: git reset HEAD^
* Now add the commits of a logical unit each, let's say some patches, d/rules, d/control, d changelog
* and end the rebase with 'git rebase --continue'
* add tag split (git ubuntu tag --split --bug 1234567)
* harmonizing d/changelog commits into two commits: a changelog merge and a reconstruction.
* Sync (as in ubuntu-maintainers-handbook)
"For other sync situations, you can review this.
Outside of the server team process the common way is to request for an explicit sync
via filling a Launchpad Bug or using the 'requestsync' tool."
https://manpages.ubuntu.com/manpages/impish/man1/requestsync.1.html
in case one has permissions to upload the package to Ubuntu: 'syncpackage' (copy source packages from Debian to Ubuntu)
* merge: debdiff of NEW Debian package and NEW Ubuntu package
* some general MERGE/SYNC notes to remember:
* always to a test build (e.g. in PPA) on all relevant architectures (as usual)
* if tests are available, run them as well
* also do an package install and update test
* and check the package content (dpkg -c )
* look for upstream bugs that can be fixed at the same time
* check for any "reverse-depends -a source src:" (esp. with libs)
and test build them as well, pointing to the test PPA (or using the same)
* do the source package build using -v, like:
dpkg-buildpackage -S -d -v7.6.0-4ubuntu1 --sign-key=...
this causes the 'in-between changelog items' to appear in the .changes file
(means all changelog entries from previous to new version)
* make sure the LP bug for the merge is referenced in the changelog
(since lot's of things are needed to create and populate the LP bug,
I start the work w/o having a LP bug number; so don't forget to add it later!)
* if working based on the Merge-o-matic files there is usually a proposed changelog file
either update this properly or create a new/current entry using 'dch -i'
* check if the version is correct (MERGES and SYNCS aren't SRUs!)
* update the version from UNSTABLE (or so) to the current development release (kinetic)
* update the urgency (should usually be medium, and not low as in the 'mom' template)
* if reusing the 'mom' template overwrite the mom mail with yours
and update the date to the current one! (not needed is using 'dch -i')
* Examples for MERGE:
* 'ferret-vis' - MERGE
LP#1986565 - "Please merge ferret-viz 7.6.0-5 into kinetic"
https://bugs.launchpad.net/bugs/1986565
ferret-vis (7.6.0-5ubuntu1) kinetic; urgency=low
* Merge from Debian unstable, remaining change:
+ Build without lto. lto-disabled-list can't be used (d/rules), because
dpkg-buildflags is called after changing the package base directory.
* 'libgcrypt20' - MERGE
LP#1974277 - "Please merge libgcrypt20 1.10.1-2 (main) from Debian unstable (main)"
https://bugs.launchpad.net/bugs/1974277
> libgcrypt20 (1.10.1-2ubuntu1) kinetic; urgency=low
* Merge from Debian unstable. (LP: #1974277) Remaining changes:
+ d/p/disable_fips_enabled_read.patch
Disable the library reading /proc/sys/crypto/fips_enabled file
and going into FIPS mode.
libgcrypt is not a FIPS certified library.
* Removed d/p/0001-Always-include-config.h-in-cipher-assembly-codes.patch
since it's already included in the new version.
* Removed d/p/0001-poly1305-fix-building-with-arm-linux-gnueabihf-gcc-1.patch
since it's already included in the new version.
* Refreshed d/p/12_lessdeps_libgcrypt-config.diff
and d/p/disable_fips_enabled_read.patch due to offsets.
https://launchpadlibrarian.net/602209655/debdiff_libgcrypt20_of_Debian_1.10.1-2_and_Ubuntu_1.10.1-2ubuntu1.patch
* 'atlas' - MERGE
LP#1961518 - "Please merge atlas 3.10.3-12 into jammy"
https://bugs.launchpad.net/bugs/1961518
> atlas (3.10.3-12ubuntu1) jammy; urgency=low
[ Frank Heimes ]
* Merge from Debian unstable. (LP: #1961518)
Solved merge conflict in d/control.
Remaining changes:
+ debian/libatlas-base-dev.install
+ debian/libatlas3-base.install
+ debian/patches/000?-*.patch
+ debian/rules
+ debian/source/include-binaries
[ Erich Eickmeyer ]
* Sponsored upload
https://launchpadlibrarian.net/587063572/atlas_3.10.3-10ubuntu3_3.10.3-12ubuntu1.diff.gz
* Examples for SYNC:
* 'tigervnc' - SYNC
LP#1960814 - "Sync tigervnc 1.12.0+dfsg-2 (universe) from Debian unstable (main)"
https://bugs.launchpad.net/bugs/1960814
tigervnc (1.12.0+dfsg-2) unstable; urgency=medium
* Re-upload as-is (and source-only).
https://launchpad.net/~fheimes/+archive/ubuntu/tigervnc/+packages
* 'nettle' - pushed for a SYNC
LP#1959469 - "[22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)"
https://bugs.launchpad.net/bugs/1959469
a bit tricky, since the symbols files have architecture-specific entries
so just merging the deltas that are spat out on a sample build does not work
one needs to merge all entries for all architectures at the same time - that's what I did
but since Debian supports even more architectures than Ubuntu I think this should be merged from Debian
Hence I've opened a Debian bug, asked to upgrade, pointed to the merge I already did, and offered my help ...
https://launchpadlibrarian.net/613585238/debdiff_nettle_3.7.3-1build2_to_3.8-0ubuntu1.diff
Magnus updated the package on the Debian side and it got auto-synched !
== Backports ==
* References:
* https://wiki.ubuntu.com/UbuntuBackports
* Backports work 'roughly' similarly to syncs, but have somewhat different requirements.
To request a backport, follow the UbuntuBackports process.
* backports have a tilde ('~') in their version string, like: 1.2.3-3ubuntu1~20.04.1
== Transition ==
* A transition occurs when changes in a package A require further changes to other packages B, C, ..., that depend on A.
To solve this, the packages B, C, ... that use or depend on package A, either need to be updated to a new version or recompiled.
(Packages blocking a transition might be postponed from testing so that the transition can complete.)
* To handle a transitions, all affected (source) packages must migrate together to keep the archive installable (and the dependencies satisfied)
* This happens in case of an SONAME bump (libfoo[n] changes to libfoo[n+1]), <
>
means if build dependencies (e.g. of a library) change significantly, <
>
like an updated/new version that comes with API/ABI changes. <
>
or simply in case of a renamed package.
* A rebuild of all packages that need that package or lib as build dependency is needed
(as well as testing, e.g. autopkgtests).
* To find all reverse dependencies use: reverse-depends -a source src:libica
* The currently active transitions can be found here: https://people.canonical.com/~ubuntu-archive/transitions/
* Examples: <
>
* small example: <
>
reverse-depends -a source src:libica <
>
Reverse-Build-Depends <
>
opencryptoki (for libica-dev) <
>
openssl-ibmca (for libica-dev) <
>
* mid-size example: <
>
reverse-depends -a source src:pcre2 <
>
- 5 'Reverse-Testsuite-Triggers' <
>
- 91 'Reverse-Build-Depends' <
>
* huge example: <
>
reverse-depends -a source src:zlib (zlib and htslib) <
>
- 55 'Reverse-Testsuite-Triggers' <
>
- 1435 'Reverse-Build-Depends' <
>
- 9 'Reverse-Build-Depends-Indep' <
>
(Same as Build-Depends, but only needed when building arch. independent packages.) <
>
- 23 'Reverse-Build-Depends-Arch' <
>
(Same as Build-Depends, but only needed when building arch. dependent packages.) <
>
* Transition for renamed package (https://wiki.debian.org/RenamingPackages) <
>
define a new binary dummy package with the same name as the old package in the control file of the new package.
The new source package takes over the binary dummy package, and the old source package, which is then binaryless, can be cleaned up.
* Example:
LP#1959421 - "[22.04 FEAT] Upgrade libica to latest version (crypto) (v4.0)"
incl. transition
https://bugs.launchpad.net/bugs/1959421
> libica (4.0.1-0ubuntu1) jammy; urgency=medium
* New upstream release LP: #1959421
* transition from libica3 to libica4
+ adjust d/control
+ migrate d/libica3.* to d/libica4.*
+ extended symbols file
* adjusting d/copyright
+ change tabs to spaces
+ update relevant copyright years
== MIR (main inclusion report) ==
* References:
* https://launchpad.net/~ubuntu-mir # MIR team
* https://github.com/canonical/ubuntu-mir # (new and latest and nicest doc)
* https://github.com/canonical/ubuntu-mir#process-states
* https://github.com/canonical/ubuntu-mir#templates-and-rules
* https://wiki.ubuntu.com/MainInclusionProcess
* https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
* https://wiki.ubuntu.com/ArchiveAdministration#Component_Mismatches_and_Changing_Overrides
* https://people.canonical.com/~ubuntu-archive/component-mismatches.txt
* Packages in Ubuntu main (and restricted) are officially maintained, <
>
supported and recommended by the Ubuntu project. <
>
Security updates are provided for them as necessary by Canonical, <
>
and Canonical's standard support services apply to these packages.
* Therefore, special consideration is necessary before adding new packages to these components. <
>
The Ubuntu MIR Team reviews packages for promotion from universe to main.
* One team at Canonical needs to own the package (will be responsible for it).
* Of course all dependencies also need to be in mail ('check-mir').
* A successful MIR will cause a dependency/Seed change to pull the package into Main.
* Data-only packages (like fonts) do not need to follow the entire MIR process.
* The MIR-bug reporter is the driver of the MIR process.
* Only binary packages should be promoted to main.
Sometimes source packages have binary packages that aren't actually needed in main,
like -doc or -dbgsym, these can stay in universe.
== Package Removal ==
* References:
* https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages
* This is done upon request
* create a LP bug request for this
* subscribe (NOT assign) ubuntu-archive to it
* remove both the source package and all binary packages?
* state why the package should be removed
* which Ubuntu release (series) to remove it from
* confirm that the binary packages have no rdepends (means no other package depends on them) <
>
include the output of 'reverse-depends -a source src:$package' <
>
and 'reverse-depends src:$package'
* Example: https://bugs.launchpad.net/bugs/2008240
* If help if needed on the decision to whether a package should be removed or not,
start a discussion on the 'ubuntu-devel' mailing.
== NBS ==
* References:
* https://wiki.ubuntu.com/UbuntuDevelopment/NBS
* https://people.canonical.com/~ubuntu-archive/nbs.html
* Binary packages that are not built from any source (anymore)
* some reasons for such cases:
* a library gets a new SONAME (libfoo[n+1]) (due to an update),
the previous version built libfoo[n]
* a package gets renamed by upstream and the renaming is reflected in the package name change
* such packages are not automatically removed from the archive,
since they still have reverse dependencies (packages depending on them)
* Sometimes one NBS package will depend on another, which can confuse a transition.
* In case a package has an alternate dependency, it will still show (but doesn't always need fixing).
* Remember that NBS removals are manual, which can confuse the results.
== Symbols ==
* https://wiki.debian.org/UsingSymbolsFiles
* ABI/API compatibility is a special
If a library breaks backward compatibility (i. e. changes existing API/ABI and introduces a new SONAME),
then this always needs approval from the release team, since all reverse dependencies need to be adjusted and rebuilt.
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
* dpkg-gensymbols - generate symbols files (shared library dependency information)
* 'check-symbols' (cmd) - verify symbols exported by a new library version
== Seeds ==
* References:
* https://wiki.ubuntu.com/SeedManagement
* current seeds: https://people.canonical.com/~ubuntu-archive/seeds/
* https://people.canonical.com/~ubuntu-archive/seeds/ubuntu.jammy/server-minimal
* current germinate output: http://people.canonical.com/~ubuntu-archive/germinate-output/
* https://launchpad.net/ubuntu-seeds
* https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/
* Seeds are lists of packages which are considered important to have in the main component of the distribution,
without explicitly listing all their dependencies and build-dependencies.
They kind of define the content of an Ubuntu distribution.
* There are several (primary) seed, like minimal, boot, standard, desktop, ship, live, and supported,
that define what goes into the archive's main component.
* Seeding a package pulls all of its dependencies into the appropriate part of the archive
and ensures everything needed to build that package is at least placed in supported.
* Examples are server, server-minimal, desktop, cloud-image, live, wsl
* sometimes they incl. platform specific entries, like:
==> * s390-tools [s390x]
* germinate — expand dependencies in a list of seed packages
It takes a list of (seed) packages and a mirror of the distribution, and produces outputs with
the seed packages and their dependencies and build-dependencies expanded out in full.
* The tool 'seeded-in-ubuntu ' can tell whether and how a given package is seeded
== Bileto / former "CI Train" ==
* References:
* https://wiki.ubuntu.com/Bileto
* https://wiki.ubuntu.com/Bileto#QA
* https://bileto.ubuntu.com/#
* https://bileto.ubuntu.com/#/ticket/4905
* https://bileto.ubuntu.com/log/4905/status/1219/
== Upload rights ==
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/MembershipInPackageSet.md
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/MembershipInMOTU.md
* https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/MembershipInCoreDev.md
== Kernel bug fixing / patching ==
* References:
* https://wiki.ubuntu.com/KernelBugFixing (step-by-step guide)
* https://wiki.ubuntu.com/Kernel/Dev/KernelPatches tips)
* cherry-pick lines: <
>
(cherry picked from commit de5012b41e5c900a8a3875c7a825394c5f624c05 linux-next) <
>
or just: <
>
(cherry picked from commit de5012b41e5c900a8a3875c7a825394c5f624c05) <
>
* backported lines: <
>
(backported from commit 1a82f6ab23659aa01a796d9d444ec9cc63ded26c linux-next) <
>
or just: <
>
(backported from commit 3d787b392d169d4a2e3aee6ac6dfd6ec39722cf2) <
>
[Frank Heimes: Resolve minor conflict due to additional includes.]
* In both cases add: <
>
Signed-off-by: Frank Heimes
* for kernel pull-requests: <
>
* for backports (applied with 'git am'): <
>
<
>
<
>
<
>
ADD a "From: " line <
>
<
>
BugLink: https://bugs.launchpad.net/bugs/1234567 <
>
<
>
... <
>
(backported from commit 012a224e1fa31fc256aab921f691598e03db6018) <
>
[Frank Heimes: Backport needs to use primary address space.] <
>
Signed-off-by: Frank Heimes <
>
* for cherrypicks: <
>
<
>
<
>
<
>
DO NOT add a "From: " line, otherwise you'll get duplicate ones <
>
BugLink: https://bugs.launchpad.net/bugs/1234567 <
>
<
>
... <
>
(cherry picked from commit 416e7f0c9d613bf84e182eba9547ae8f9f5bfa4c) <
>
Signed-off-by: Frank Heimes
* For a normal (means non PR) submission to the kernel teams mailing list <
>
use a subject line like this: <
>
][PATCH n/m] commit name> <
>
(Non PR submissions should be done btw. up to about 5 commits <
>
* setting kernel options: <
>
Remember the new way of handling kernel options (thx to arighi) via the annotations file and script: <
>
https://discourse.ubuntu.com/t/kernel-configuration-in-ubuntu <
>
https://lists.ubuntu.com/archives/kernel-team/2023-June/140230.html <
>
And notice that 'updateconfigs' must be run on the same target platform (Ubuntu release)
your kernel sources are made for, so that the correct tool-chain is used,
since some kernel options are depending on the tool-chain.
(Means run updateconfigs for jammy kernel sources on a jammy system, e.g. using chroot.)
A changing tool-chain between updateconfigs and build may (will) cause issues.
Alternatively remove any confusing kernel options by hand before building, but this is a bit error prone.
== Bugs / Triage ==
* References:
* https://wiki.ubuntu.com/Bugs/Triage
* https://wiki.ubuntu.com/Bugs/Triage?action=show&redirect=Bugs%2FHowToTriage
* https://wiki.ubuntu.com/BugSquad
* bugs related to me: https://bugs.launchpad.net/people/+me/
expands (for me) to: https://bugs.launchpad.net/~fheimes
* bugs I'm subscribed at: https://bugs.launchpad.net/~/+subscribedbugs
* bugs I'm commendted on: https://bugs.launchpad.net/~/+commentedbugs
* List of suggested bug responses: https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/BugReportResponses.md
== Packaging-Resources ==
* Ubuntu Packaging:
* (This is the link to the old Ubuntu packaging guide:
https://wiki.ubuntu.com/PackagingGuide <
>
that is no longer valid and redirects now to:) <
>
The (new) Ubuntu Packaging Guide (still wip, so expect some gaps) <
>
https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/ <
>
https://github.com/canonical/ubuntu-packaging-guide <
>
* broken down according to Diátaxis:
* Tutorial: https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/tutorial/
* How-to: https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/how-to/
* Explanation: https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/explanation/
* Reference: https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/reference/
* Ubuntu Maintainer's Handbook: https://github.com/canonical/ubuntu-maintainers-handbook
* Debian Packaging:
* How To Package For Debian: https://wiki.debian.org/HowToPackageForDebian
* Packaging (Debian Wiki): https://wiki.debian.org/Packaging
* Packaging Intro (Debian Wiki): https://wiki.debian.org/Packaging/Intro
* Debian New Maintainers' Guide: https://www.debian.org/doc/manuals/maint-guide/
* Debian Policy Manual: https://www.debian.org/doc/debian-policy/
* Packaging Tutorial Manuals (as PDF, available in different languages): <
>
https://www.debian.org/doc/manuals/packaging-tutorial/ <
>
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf <
>
* PackageManagement (Debian Wiki): https://wiki.debian.org/PackageManagement
* Debian Developer's Reference: https://www.debian.org/doc/manuals/developers-reference/:
* Debian Packaging School: Lesson 1: <
>
https://liw.iki.fi/liw/talks/debian-packaging-tutorial.pdf <
>
https://liw.iki.fi/liw/talks/debian-packaging-tutorial.odp
* Debian Packaging Tutorial (also package in Ubuntu archive): <
>
https://packages.ubuntu.com/noble/packaging-tutorial <
>
https://salsa.debian.org/debian/packaging-tutorial
== Further Reading/References ==
* https://wiki.ubuntu.com/MultiarchSpec
* https://packaging.ubuntu.com/html/debian-dir-overview.html
* https://people.canonical.com/~ubuntu-archive/
* Server team bugs (replace 'jj'J wit other codename abbreviations):
https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-tracking-bug-tasks.html#ubuntu-server
* Foundations team bugs (replace 'jj'J wit other codename abbreviations):
https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-tracking-bug-tasks.html#foundations-bugs
* Kernel (packages) bugs (replace 'jj'J wit other codename abbreviations):
https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-tracking-bug-tasks.html#kernel-packages
* Ubuntu OpenStack bugs (replace 'jj'J wit other codename abbreviations):
https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-tracking-bug-tasks.html#ubuntu-openstack
* https://wiki.ubuntu.com/SpecSpec
https://wiki.ubuntu.com/SpecTemplate
* Full changelog of a package: https://launchpad.net/ubuntu/+source//+changelog
* Full publishing history of a package: https://launchpad.net/ubuntu/+source//+publishinghistory