Memorandum

This page describes what I'm actually dealing with, on what I have actually worked and some tips that I have to remember for my MOTU journey Smile :)

On what I'm currently working?

Bugs / TODO

See also https://wiki.ubuntu.com/DidierRoche/MOTU/bugsaction

Pages still need reading

TIPS

tarball from SVN

  • to roll a new tarball :

    • /autogen.sh (which calls a ./configure) && make distcheck (or make dist if we want to by-pass all checks)

-> make distcheck builds in another folder inside sources to check that all includes are ok (with $(srcdir) for instance)

MOTU task/work Helper

-> "MOTU Beginner's tasks" should be fine

Important pages

Debconf:

Maintainer scripts:

Lintian tags:

Pbuilder complete guide:

some common tasks

Desktop file

transitional package

== Licence checking ===

Advanced bash guide

Bug Management

Bug tools

* To retrieive bugs title

  • if we only know the package 

bugnumbers -p <package>
  • -P for upstream project
  • if we have the bug number 

buginfo --title <bugnumber>

  • others options available to bugnumbers (-l url). See -h

Common bug response

Diff

List files touched by a diff.gz

  • lsdiff -z <package>.diff.gz

  • diffstat <package>.diff.gz

two arborescences and making diffstat

for instance:

  • diff -ruN f-spot-{0.4.4,0.5.0}/ | diffstat

versionning rules

<upstream>-<debian_revision>ubuntuX (where X is a progressiv number) For example: libc6 | 2.8~20080505-0ubuntu6 | intrepid | amd64, i386 upstream release is 2.8~20080505 the package is not in debian -0 and is at the sixth ubuntu revision: ubuntu6

Compare version

dpkg --compare-versions

Maintainer fields

packaging techniques

CDBS stuff

https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml

/usr/share/doc/cdbs/cdbs-doc.html

http://debathena.mit.edu/packaging/

* CDBS is patched to automatically symlink identical doc/ files (in debhelper.mk)

* examples of CDBS usage:

https://svn.ulteo.com/ovd/trunk/debian

.install (called with debhelper/CDBS)

File : <package>.install

Two notations, with one or two arguments: 

debian/tmp/etc/                           -> will copy all the content of debian/tmp/etc (build result) to debian/<package>/etc
system-cleaner-gtk.png usr/share/pixmaps  -> will copy system-cleaner-gtk.png (path relative) to debian/<package>/usr/share/pixmaps

include binary in a diff.gz (like .png)

  • Make it a string: icon.png icon.png > icon.png.uuencode (uuencode from sharutils package)

  • add sharutils as buildd in the control file
  • update the clean/build target to decode it at build time
    • with cdbs: 

clean::
        rm -rf  debian/icon.png

makebuilddir::
        uudecode debian/icon.png.uuencode

Documentation: https://wiki.kubuntu.org/PackagingGuide/Howtos/BinaryFilesInDiff

queuing and build

Special build option

  • Building without creating the source file: pdebuild

  • Avoid that pbuilder is creating each time diff.gz, orig.tar.gz and .dsc in the .changes files: --debbuildopts -b

Using bzr

NBS

Merge

  • MoM is at http://merges.ubuntu.com/

  • Outstanding utstanding merges are those that have not been tackled in Ubuntu at all across the current release
  • Updated merges means that newer Debian versions are available for merges packages that have already been done in the current release

patch system

  • to know which patch system is used: what-patch
  • to adapt a patch: filterdiff

autotools in a patch

Usually the autoconf patches are updated this way (at a patched configure, before is applied an configure.am corresponding patch):

  • move the current version <patch_corresponding_to_configure>.patch somewhere else

  • run cdbs-edit-patch/dpatch <patch_corresponding_to_configure>.patch

  • autoconf
  • rm -rf autom4te.cache
  • exit

check configure files and new dependency

if configure add a new dependency, for instance: 

  PKG_CHECK_MODULES(SMCLIENT, gtk+-2.0 gthread-2.0 sm >= 1.0.0)

-> sm has been added. Look at the corresponding .pc 

  apt-file search sm.pc
  libsm-dev: /usr/lib/pkgconfig/sm.pc

put some example configuration files in a package

It should be sent in /usr/share/doc/package/example

Source package

download manually .dsc file and extract the other files automatically

dget -x http://...dsc

dsc, orig and diff.gz other file downloaded, extracting them

dpkg-source -x ...dsc

If already downloaded: 

apt-source -x ...dsc

new packages and inline patch

  • Once, new version downloaded (given at the src tree root), with uscan if there is a debian/watch file: 

zcat ../foo-1.diff.gz | patch -p1

  • all can be automated by using uupdate in the src tree root of the old package 

uupdate ../foo_2.orig.tar.gz

special files

  • config.guess and config.sub are automatically updated on build by debian tools. No need to mentionned if a change in the changelog (we only list manual change, not automatic one)
  • debian/control.in update debian/control by, for instance, DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes fakeroot debian/rules clean

gobjection introspection (gir, typelib)

Binary Package

extract data part of a binary package

dpgk -x ....deb

dpkg-deb and control file management

  • dpkg-deb -e <package.deb> : Extracts the control information files into a subdir of the current dir named DEBIAN

  • dpkg-deb -I <package.deb> : Print a summary of the content as well as the control file

  • dpkg-deb -I <package.deb> <control file>: Print content of one of the <control file>s

  • dpkg-deb -f <package.deb> : Print control file information

package management

know from where a package comes from or is available

$ apt-cache madison bzr
       bzr | 1.3.1-1ubuntu0.1 | http://archive.ubuntu.com hardy-updates/main Packages
       bzr |    1.3.1-1 | http://archive.ubuntu.com hardy/main Packages
       bzr |      1.5-1 | http://archive.ubuntu.com intrepid/main Sources
$ apt-cache policy bzr
bzr:
  Installé : 1.3.1-1ubuntu0.1
  Candidat : 1.3.1-1ubuntu0.1
 Table de version :
 *** 1.3.1-1ubuntu0.1 0
        500 http://archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     1.3.1-1 0
        500 http://archive.ubuntu.com hardy/main Packages

OR rmadison (all available in Ubuntu repository)
$ rmadison bzr
       bzr | 0.8.2-1ubuntu3 |        dapper | source, all
       bzr | 0.15-0ubuntu2 |        feisty | source, all
       bzr |     0.90-1 |         gutsy | source, amd64, i386, powerpc
       bzr |    1.3.1-1 |         hardy | source, amd64, i386
       bzr | 1.3.1-1ubuntu0.1 | hardy-updates | source, amd64, i386
       bzr | 1.3.1~rc1-0ubuntu1~gutsy1 | gutsy-backports | source, amd64, i386, powerpc
       bzr |      1.5-1 |      intrepid | source, amd64, i386

If nothing is written, the package comes from main, otherwise: 

asterisk | 1:1.4.21.2~dfsg-1ubuntu1 | intrepid/universe | source, amd64, i386

Search dependencies and reverse dependencie

apt-cache rdepends <package>

(little | wc -l to know what is the impact of a package Funny :))

  • reverse build depends
    • build-rdeps

To know from with package a file is

  • if installed: dpkg -S <file> or dlocate (index)

  • if not installed: apt-file

To know if a package is installed (and other release)

  • dpkg-query -s $package
  • dpkg-query -l $package
  • apt-show-versions -a $package
  • dpkg --get-selections | grep $package
  • for dependencies (will only show installed one): apt-cache depends --installed $package

Send patch to upstream

debian:

  • automatically:

See https://wiki.ubuntu.com/Debian/Bugs#Using%20submittodebian%20to%20report%20bugs%20in%20Debian

http://svn.debian.org/ http://svn.debian.org/viewsvn/pkg-gnome/

GNOME

gpg stuff

The option keyserver-options auto-key-retrieve in ~/.gnupg/gpg.conf enable to retreive automatically unknown gpg key from gpg --verify ...dsc

other stuff

autotools

References:

libraries

Useful tools

  • objdump -p /path/to/lib.so... | grep SONAME

  • objdump -p /path/to/lib.so... | grep NEEDED -> put them as dependencies of -dev package…

  • nm -D (/!\ no version is explicitely seen)
  • To see them:
    • objdump -T
    • readelf -s
  • gdb lib.so (if not stripped) and then:
    • info functions (signatures availables)
    • info variables

Warning /!\ ldd is recursive, not nm

symbols and shlibs

.symbols have a better granularity over shlibs versions. shlibs version makes you depend on the version which ships the current abi version where when using symbols you depends on the version which has the symbols you require.

* also add DEB_DH_MAKESHLIBS_ARGS += -c4 to rules so the build fails if symbols mismatch

.a, .la and .so

  • .a are kept (cf libevview1 & libevview1.doc) and used for static linkage

  • .la are removed as only need for multiplateform linkage and can bring some troubles.

using LD_PRELOAD to fool librairies

autoreconf/autoconf

/!\autoreconf is when you change makefiles. If you change only configure autoconf should be enough + clean cache directory

documentation:

cmake:

conffiles

All files in /etc are automatically set as conffiles. No need to put them into conffiles.

http://wiki.debian.org/DpkgConffileHandling

MD5 autconf files files

They are located in /var/lib/dpkg/status, with the package control file. So, we will not find them in md5sums (and they seems to be generated at install time). However, if a conffile is modified during the postinst, the change is not taken into account in the md5.

/etc/init.d/foo parameters

The easiest way is to put them in /etc/default/foo and source this file in the init script, giving reasonnable default (event start=true or start=false parameter.

Some work on this is done in my loggedfs package.

=== add status to init script ===

  • status)

    • status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $? ;;

in debian/control:

  • lsb-base (>= 3.2-14),

Play with the archives

* https://edge.launchpad.net/ubuntu-archive-tools package

GNOMEries

where nnnn is the gnome bug number, it will give you the ubuntu bug if there is one

configure

  • GTK_DOC_CHECK: You have to add gtk-doc-tools as a b-d
  • /tmp/buildd/totem-2.25.3/configure: line 23439: GNOME_COMMON_INIT: command not found

/tmp/buildd/totem-2.25.3/configure: line 23440: GNOME_DEBUG_CHECK: command not found /tmp/buildd/totem-2.25.3/configure: line 23441: syntax error near unexpected token `maximum' /tmp/buildd/totem-2.25.3/configure: line 23441: `GNOME_COMPILE_WARNINGS(maximum)'

=> it misses gnome-common in the OS that call autoreconf -i. Solution : install it! Smile :)

  • macro `AM_GCONF_SOURCE_2' not found in library

or

  • configure.ac:14: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library

configure.ac:14: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT

  • If this token and others are legitimate, please use m4_pattern_allow.

=> it misses libgconf2-dev

Gconf

Sabayon / pessulus

Some code for dbus (Policykit Code doesn't work)

Policykit (polkit-1) docs

KDEries

ninja's ppa

classic workflow

  • batget <kdepackage> (this will pull the tarball, prior version, and the bzr debian dir from lp)

  • cd <source directory>

  • batbuild
    • will 'debuild' the package
    • 'pbuild the package'
    • if successful, give a report of warnings and missing files upon completion
    • figure out what files to remove from the .install files
  • batbuild -b (it just debuild -s)
  • batsend (it collects information from the build (report, buildlog, filterdiff, bzr bundle, and *diff.gz))

Translation handling

(ex: pidgin)

  • X-Ubuntu-Gettext-Domain is used by ubuntu rosetta.

-> the glib and gnome-desktop ubuntu changes to use gettext do use this key to know what gettext file to use. ie upstream behaviour is to read the Name[locale]=... in the desktop directly and we do change that to call gettext so we can use language

  • packs.

But the gettext call needs to specify the domain to use so we write this information in the .desktop at build time

  • intltool is to run the intltool-update which is for ubuntu languagepacks

Misc

== man page==

Good documentation: http://www.wgdd.de/?p=65

triggers

http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/

advanced vim guide

http://www.swaroopch.com/notes/Vim_fr

Questions

Pending questions

Question to ask to IRC when having time

Old questions

  • language package. How does it works? I read this: https://wiki.ubuntu.com/MataroSessionsWorkshops/LanguagePacks from this page (https://wiki.ubuntu.com/UbuntuPackagingChanges). But no choice has been taken if we only look at this page. From what I understand, there is the language-pack-fr-base package which take a large amount of .mo in /usr/share/locale-langpack. But what happened, if, eg, the new version of let say, tuxmath 1.5.8-2 remove some entries for language pack? Rosetta is updated and then the package language-pack-fr-base is updated to (removing this entry). But if I really don't like tuxmath 1.5.8-2 and force dpkg to stick with tuxmath 1.5.8-1, there will be a compatibility issue regarding the translation (one entry is missing...)?

  • Why dh_make put everything in binary-arch and not some in independ target (for dh_manpages, for instance) ?

anyway, it's mostly related to the fact that these dh_ calls are a minority compared to the the rest of the package, and anyway they are related to an arch-dependant package yeah. consider, further, that some of the dh_ commands must be executed in order, and having some of them in -indep (that is a prerequisite for -arch) would make everything more difficulty.

  • Where to ship a localized manpage?

In the package directly. Ask pitti who is the langpack man (there is manpages-fr package). Seems to be more general stuff

  • .src.tar.gz

I have such a file on a merge : http://merges.ubuntu.com/f/freecol/REPORT it said that "Due to conflict or error, it was not possible to automatically create a source package. Instead the result of the merge has been placed into the following tar file which you will need to turn into a source package once the problems have been resolved." But the files resulting from the merge (orig.src.tar + diff.gz and pending merge) are already extracted in a directory. So, this tar is not useful.

I reckon that we can sometimes send directly those files to the tar instead of using dput on the .changes file, or does this tar (containing .orig.tar.gz + diff.gz) is really meanless?

Unfortunately I answered so late to this question (my apologies!) that freecol has been merged already and I can't check the merge. Anyway, MoM unable to build a source package is a common situation. In this scenario, the tar is actually useful, since it contains the result of the merge that MoM tries to do. Of course, MoM is just a fast and useful, but (very) stupid tool, and you need to *carefully* check what he made (even switching to a manual merge and leaving the MoM work apart).

=> Yeah, I did the merge Smile :)

I still have this .tar.gz but it is 14 MiB, so…

  • how to ensure the debian section of a package.

For instance, with swfdec0.8, I wanted to ensure that this source package was in main. So, I used http://www.debian.org/distrib/packages#search_packages, limiting the search to "main" section to be sure that swfdec0.8 is in main. But is there some kind of rmadison tool to target debian and not use this tricky process?

If you take a look to man rmadison, you will see that there is an handy option -u to force an URL to query, and there is a shortand "qa" to query http://qa.debian.org/madison.php. This is probably what you are looking for.

  • Easy one: What are the number next to make. For instance make[2], make[3], make[1] (recursivity level?) ?

  • how do you choose where you will upload the change with dput ?

For instance, we can upload in Ubuntu to release (during development) or release-proposed (for SRU). How to deal with that? Any documentation to point at (search in the wiki wasn't succesful for me). Also, did not remember well if, in ubuntu, there is another "destination".

Well, whatever package you upload to the archive, you always upload to the server that is listed in /etc/dput.cf (upload.ubuntu.com) under the label [ubuntu]. Then, according to the entry in the .changes file, the first line of the debian/changelog file, the upload is processed, build and published in the appropriate repository.

Warning /!\ try to see the .changes files in next merge Wink ;)

  • Did not understand that from -devel mail for jaunty :
  • please build your changes files with the -v option, so that changes done in Debian, but not in Ubuntu will be part of the changes file

-v is an option for debuild (and dpkg-buildpackage, of course, and dpkg-genchanges too) that "use changelog information from all versions strictly later than version" (taken from the man). As a contributor, you don't need to use it. You will need when you will be a MOTU, to upload merges to archives, so that the .changes file include not the last version information only, but all the changelogs since the one you indicate with -v.

You need to use -v$version, where $version is the latest ubuntu version, when you build the source package for a merge that you are going to upload. For example, right now ekiga is at 2.0.12-0ubuntu5 in Ubuntu and 2.0.12-1+nmu1. Whenever you will upload the merge, even if Debian ships new releases, you will need to use -v2.0.12-0ubuntu5. Since you will actually create the changes file, you will need to use -v when you sponsor someone else's debdiff too.

Keep in mind that not using -v is not a terrible mistake, but will make archive admins angry (and you never want an angry a-a) and will not impress your fellow MOTUs.

  • A question for a C specialist Smile :)

    • from intrepid, the compilation is made using FORTIFY_SOURCE to 2, with force the -02 option. From gcc, it said that this enforce to use the -g option (so debug mode!). So, every packages will have debugs informations.

Do you know this? Can you confirm?

it's true. And you can strip debug informations in a -dbg package in the way we discussed days ago (on the wiki itself, IIRC)

  • I can't find a package which describe when creating -dbg and -dev package
    • So, are there some page on the wiki describing that?

I didn't found any of them, both on the Debian and on the Ubuntu wiki. I googled a little and found this link ( http://maemo.org/development/documentation/how-tos/3-x/how_to_make_a_dbg_package.html ) but I'm not sure it follows good packaging practices (didn't read it thoroughly). I hove found some other links, but nothing appeared really interesting. Unfortunately, I have a very short time now, but you can try to search deeper, or just ask in #ubuntu-motu.

  • I can't figure out what is -dev package exactly (I read it somewhere, but it has gone out of my memory)

It simply contains files needed for the building of other packages. They are tipically used in the build-depends: field of debian/control

  • I assume that -dbg packages are created adding a new binary package to the same source package and compiled with a debug rule in debian/rules for that package, is it correct?

True regards adding a new binary stanza in debian/control. Regarding debian/rules, dh_strip used with the option --dbg-package is your friend. Taking a look to existing -dbg (and -dev, too) packages can give you a valid overview of how these packages are built.

  • stamp for debian/rules

Making a stamp enables us to not rerun a target if it is already stamped (patch, build...). I thought it was some kind of "best praticed" and should be handled manually (cf debian-policy). But looking at again the maint_guide (ap-phttp://www.debian.org/doc/maint-guide/kg-eg.fr.html), I look at this example: 

       config.status: patch configure
            ./configure --prefix=/usr --mandir=/usr/share
       build: config.status
            ${MAKE}
       clean: clean-patched unpatch
       clean-patched:
            $(testdir)
            $(testroot)
            ${MAKE} distclean
            rm -rf debian/imaginary-package debian/files debian/substvars
       patch: patch-stamp
       patch-stamp:
            dpatch apply-all
            dpatch call-all -a=pkg-info >patch-stamp
       
       unpatch:
            dpatch deapply-all
            rm -rf patch-stamp debian/patched

So, a patch-stamp file is created when patch or configure is called, but there is no test to see if the file exist (I would have done something like: 

       ...
       patch-stamp:
            if [ ! -f patch-stamp ]; then
                dpatch apply-all
                dpatch call-all -a=pkg-info >patch-stamp
             fi
       ...

So, just to confirm that creating a file with the name of a target in debian/rules handle this automatically. Your comment makes sense. Probably the author of that snippet of code really wanted to overwrite the file every time rules is run.

  • Meta-package/virtual package:

From the debian Policy, I do not understand very well if there is a difference. Apparently, it the virtual package should be created with the "Provides:" field of each depending packages. however, I had a try to look at ubuntu-desktop dependences and this is not "Provides:". Indeed, Ubuntu-desktop is a real binary package from the ubuntu-meta source package. So:

  • Are meta-pacakages really used?

  • When created a faked package (meta-package) or a virtual package? (imagining there is no maintainer script to use for the meta-package)

Said simple, a virtual package is just a way to ask for a generic application to be installed in order to allow your desired package to work fine. Imagine you want to package a video editing application, and this application need a C compiler. It could be whatever compiler you desire, doesn't matter what it exactelyis. In this case, you just add "c-compiler" as a dep of your package, and dpkg will use whatever package that has "c-compiler" in the provides: field. That's why this is a *virtual* package: it doesn't actually exists, but some package have that name in the Provides: field, meaning they provides the functionalities of that particular virtual package. The important concept is that you can't create a virtual package, they are listed here http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt and update regularly; you can only use one of these virtual packages when you need it. Regarding meta-packages: they are actually used, and ubuntu-desktop is one of them: it doesn't install (almost) nothing on your computer (except for a few files under /usr/share/doc), but depends on all the packages needed to have a working desktop. So, meta-packages are actual packages, tipically depending on a large number of packages and they are used for a very different reason compared to virtual packages.

Added remarks/pending question to the existing one:

  • some magic things: in the cups package, there is no dh_installdirs instruction in debian/rules, but the directories specified on debian/cups.dirs are created (I tested it) at install time. There is also no *dirs specification in debian/rules. What the magic? Smile :)

The magic is in the option -D of install. More about it at man install. BTW, for your future packaging works, you con forget about install and dh_installdirs using dh_install, a very powerful tool that I encourage you to use.

=> Ok, but I do not see this option either (no -D or -d in debian/rules of cups package). Even if I will then use dh_install most of the time. I want to understand Smile :)

Are you sure don't see any -D? Look at lines 78, 82, 94, for example. I see a mkdir too (altough I didn't went further too see what it actually does).

Warning /!\ I want to understand!

=> Hum, but it is targeting respectively:

  • packaging/cups-dbus.conf
  • debian/local/apparmor-profile

  • oh, is it this one with -d, no? install -d $(DEB_DESTDIR)/../cups/usr/share/cups/mime

The man is just about: 

 -d, --directory
              treat all arguments as directory names; create all components of
              the specified directories

       -D     create all leading components of DEST except the last, then copy
              SOURCE to DEST

So, from what I understand, as there is no reference to cups.dirs, I still not see why this file is taken into account (I'm bothering, no? ;)).

Unfortunately I have limited access to my packaging resources here, and can't check that package's debian/ dir. Maybe you can ask on #ubuntu-motu to have an answer to this question?

  • Finishing to read the debian policy (I do not find a confirmation in man bash/sh): 

FOO=${FOO:-bar}

This give to $FOO the bar default default if this one is empty. It is quite similar to: 

[[ -z "$FOO" ]] && FOO="bar"

-> Yes. A cleaner things is 

: ${FOO:-bar}

(: for not executing this

  • what does "dh_installdirs -i" stands for? I don't find this option in the man (there is just a quick reference to it). I found it in apache2 package.

-i is used to indicate an architecture independent package. Please, refer to man debhelper for more information.

  • what is installed by dh_installdirs is automatically removed at remove or purge time? Same question for is install manually (with mkdir ...) in debian/rules. If so, is it at removed time or purge one?

The only difference between remove and purge is that purge also removes configuration files. Configuration files are usually listed in conffile, or created byt postinst. This is an advanced topic, BTW norsetto (Cesare Tirabassi) gave an interesting lesson about Maintainer Scripts for MOTU school. You can read the log on this wiki, it is definitely a recommended reading

=> I do not understand the use of "|| true" there.

Since || represents a logical OR, and the second espression is evaluated only if the first one is false, looks like it is used to return a true value even is the first expression evaluates to false.

=> Hopefully my bases in shell enables me to follow that (I work everyday in huge shell scripts ;))

The reason for doing such a thing depends from the kind of package and from what ufw app update --add-new <profile> actually does. BTW, it is just a plain bash script, so there is nothing really special there.

=> So, I really don know for what it is useful, appart always return 0 as a return code (does the installation failed in postinst if the return code is not 0 ?).

=> Ok, I checked deeply and there is a lot of scripts beginning with set -e, so, I think we do not want to mark the package as unconfigured if it is not registred on ufw.

  • I reported the bug manually in BTS, generating .patch and clean everything that has to be cleaned. I saw at https://wiki.ubuntu.com/Debian/Bugs that submittodebian makes that and enables you to clean what has to be cleaned. But as we have to do the diff between the debian version and our last ubuntu one, cleaning everything that is not attached to our patch, if we have a package -ubuntu2 (or more), submittodebian will not work on every changes since debian one and so, the diff making the patch can not be the good one (as something can have been changed between -ubuntu1 and -ubuntu2, appears in the diff but will not appeared or appeared differently against the debian changes)?

It uses the parent source directory (that has to be a debian source directory)

  • the versionning of nvidia-kernel-common-20051028+1ubuntu8 is quite strange (even the folder is renamed when you do a dch -i). Do you have something particular to speak about those package (the ones with the versionning)?

Some packages are very strange indeed. They are usually snapshots from CVSs and similar and sometimes they have a date (like yyyymmdd) as a version number. Usually, they follow the same versioning, the only difference here is + instead of - (but not alwas). Sometimes you will see ~ too. ~ is nice if you need to test a package in your ppa, because 1.2.3-4~5 is lower than 1.2.3.4

  • Everytime I apt-get a source, apt-get can't find the gpg key

for instance: 

$ apt-get source lm-sensors
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Nécessité de prendre 204ko dans les sources.
Réception de : 1 http://archive.ubuntu.com intrepid/main lm-sensors-3 1:3.0.2-1ubuntu1 (dsc) [1205B]
Réception de : 2 http://archive.ubuntu.com intrepid/main lm-sensors-3 1:3.0.2-1ubuntu1 (tar) [176kB]
Réception de : 3 http://archive.ubuntu.com intrepid/main lm-sensors-3 1:3.0.2-1ubuntu1 (diff) [26,5kB]
204ko réceptionnés en 1s (152ko/s)   
gpg: Signature faite le lun 23 jun 2008 22:08:43 CEST avec la clé DSA ID 0F932C9C
gpg: Impossible de vérifier la signature: clé publique non trouvée
dpkg-source : extraction de lm-sensors-3 dans lm-sensors-3-3.0.2
dpkg-source : extraction de lm-sensors-3_3.0.2.orig.tar.gz
dpkg-source : mise en place de ./lm-sensors-3_3.0.2-1ubuntu1.diff.gz

"gpg: Impossible de vérifier la signature: clé publique non trouvée" stands for "gpg: Unable to check the signature: the public key can't be found". How to tell gpg to go to a public server to find the key?

After some research, I found the debian package debian-keyring (the one which is used, if I remember) to tell who is the maintainer in this or this package. So, I tried apt-get install ubuntu-keyring as this package exists. But well, it was already present. Do I have to perform a specific things to avoid the warning? (and so that, the key is checked, which is better)

Note: I have no issue when doing an apt-get install, the gpg key is well compared as I have no warning.

Try installing debian-keyring, it should fix your issue.

  • I do not understand the output of rmadison for this particular package: 

$ rmadison lm-sensors
lm-sensors | 1:2.9.2-5ubuntu3 |        dapper | source, amd64, i386, powerpc
lm-sensors | 1:2.10.1-2ubuntu2 |        feisty | source, amd64, i386, powerpc
lm-sensors | 1:2.10.4-1ubuntu1 |         gutsy | source, amd64, i386, powerpc
lm-sensors | 1:2.10.5-3ubuntu1 |         hardy | source
lm-sensors | 1:2.10.7-1 |      intrepid | source
lm-sensors | 1:3.0.0-4ubuntu1 |         hardy | amd64, i386
lm-sensors | 1:3.0.2-1ubuntu1 |      intrepid | amd64, i3861:2.10.7-1

that means the source version (1:2.10.5-3ubuntu1) in hardy is not the same that the binary (1:3.0.0-4ubuntu1), and that's the binary version is more advanced (having a higher version number) than the source??? But when I apt-get source lm-sensors, the corresponding version is 1:3.0.2-1ubuntu1 (see above). Some piece of the puzzle seems to be missing :/

Nothing strange: lm-sensors is the source package that builds libsensors-dev and libsensors3. lm-sensors is also the name of a binary package built from lm-sensors-3 (that is a source package). That explains everything Smile :)

  • What is Ubuntu Installer it builds a lot of stuff. Is it the result of sync request?

Indeed. The guy who asked the sync is in the Changed by: field. I'm not sure if it is used for other purposes too, please ask in #ubuntu-motu for more info.

  • I can't find any raisonable explanation for dh_icons: man dh_icons say it update Freedesktop icon caches. So, I was thinking about "oh yeah, this is why some package doesn't update the GNOME application menu and you have to log off/log on". But sgt-puzzle I created update it without having the steps in debian/rules… I google it without any help. Do you have an idea?

Icon files and desktop files are two different thinks. dh_icons should be called by any package that installs icon files. Something similar for .desktop files is done by dh_desktop.

  • how does ${shlibs:Depends} are calculated ?

calculated by dhdh_shlibdeps (man :)). There was a MOTU school session about it

  • try to work on NBS icedtea-java7-jre, build 3 successful debdiff attached to the existing bug (https://bugs.launchpad.net/ubuntu/+source/project-x/+bug/203636). Can't work on the 4th as there is a FTFBS and a merge pending (see https://wiki.ubuntu.com/DidierRoche/MOTU/bugsaction). Can I suscribe the bug to u-u-s even if the azureus package is not fixed yet? Indeed, I am a little concerned about the time I take to have them sponsored (my last one is still not taken into account) and that someone upload a package (maybe correcting other stuff) with the same package number…

You can, of course. Not always a NBS can be removed from the list, for example because it FTBFS like in this case. Regarding the sponsorship matter: it is a pretty bad problem. In this cycle, the queue of u-u-s is getting longer and longer, and this is not a nice thing. Anyway, continue adding your debdiffs to the bug reports and don't worry to much of that, it's a problem of your sponsors. Regarding other people uploading packages you work on: everyone should check the list of open bugs for that package and check if that bug is pending a debdiff. If someone uploads a a package for which you provided a debdiff, ping him (publicly, on #ubuntu-{motu,devel}) and show your disappointment.

  • NBS package icedtea-java7-jre:

    • I see that on debian/control for azureus, the Depends are the following: 

Depends:  openjdk-6-jre | icedtea-java7-jre | sun-java6-jre | sun-java5-jre, libcommons-cli-java, liblog4j1.2-java, libseda-java, libswt3.2-gtk-java

As I am working on the NBS package icedtea-java7-jre and | stands for "or", I can simply remove it, isn't it? It is. icedtea-java7-jre is a transitional package depending on openjdk-6-jre, so you can just drop that dep.

Possible to see it by $ apt-cache show icedtea-java7-jre?

  • But well, if so, I made a change for the package. It is the same case for freecol, which is versionned freecol_0.7.4.dfsg-1, (so no change from debian for Ubuntu) what will I have to put for the package name "Build1" or "Ubuntu1" (as I modified the dependency in debian/rules)?

the anser is: ubuntu1. The only case where you use build1 is when you absolutely don't touch anything (apart for a new entry in the changelog. If you change even a single char in a whatever file (different from debian/changelog) you introduce an ubuntu change and need to add ubuntu1 to the version.

  • And finally, to get sponsored, have I to feed a bug for each reverse dependency? (four in this case). (if yes, I can imagine that this is not needed when you are MOTU and you directly upload the concerned package)

Indeed. That's why NBS, altough *greatly* appreciated, are usually pretty boring to be achieved as a prospective|contributor developer, since usually you just upload a debdiff containing just a new-entry in the debian/changelog. Regarding the bugs, you can either file a bug for each different package, or open one bug ad add all the packages involved. Launchpad doesn't scale well when lots of tasks are opened for a bug (say > 30 tasks); on the other side, opening a lot of different bugs for the same issue is deprecated. Nice, huh? Smile :) 

-- intrepid/multiverse xxx deps on icedtea-java7-jre:
sun-javadb-client
sun-javadb-core
sun-javadb-demo

and they are not packages but are all on the same package (sun-javadb), I tried to install freecol and made a ldd on it, but it doesn't give a result! To be precise, sun-javadb-{client,core,demo} are tre binary packages built from the same source package (sun-javadb), so you just rebuild this one and get rid of the tree packages' rdepends. BTW, I have an idea of how NBS are calculated, but I'm not sure it really works this way. I don't want to give you wrong informations, so I encourage you to ask on #ubuntu-devel. IIRC, pitti is the man behind the tool.

-> NBS is based on declared binary package dependencies. This may not match the current source package (if successful builds have yet to publish (common in cases where the build fails)), and may not match ldd or similar tools depending on both the correctness of the analysis of those tools and the declared dependencies.

  • BTW, how do you choose the installed dependency package in such a case or how does apt work? (for, eg, to choose beetween openjdk-6-jre | icedtea-java7-jre | sun-java6-jre | sun-java5-jre) for azerus.
    • I reckon if one is already installed, it must use it.
    • but in the other case, it takes the first one?

IIRC, it does. Someone in #ubuntu-motu can probably confirm this: please, ask there.

  • Why there is a [NEW] in bug #255086 email notification and not in #61039 ?
    • For instance: "[Bug 255086] [NEW] FTBFS in intrepid for sgt-puzzles-7983"
    • and "[Bug 61039] Re: No desktop entries"

The only explanation I have is because I'm the only person to have confirmed it and nobody answered on it, or because the bug has less than xxx days… (both of the bugs have been "in progress" states and when I finished the debdiff, put them back in Confirmed before suscribing them at u-u-s)

I'm not sure if [NEW] is added to brand new bug only, or every time someone is subscribed to a bug. It should be the latter. BTW, it's a question regarding LP, please ask in #launchpad or file a question in Answer for the launchpad project..

for e.g: 

hppa build of darcs 2.0.2-2ubuntu1 in ubuntu intrepid RELEASE
Missing dependencies: libghc6-html-dev
Build started 3 hours ago on primero (hppa) and finished 3 hours ago taking a minute — see the log

Is that the source package needs libghc6-html-dev as a package but can't find it in the repo (so, this a manual dependencie putted in debian/controlà? Most of the time, I assume that is because this dependencie has be wrongly putted as not having it, appart from a FTBFS is uncommon, am I right?

Indeed. These FTBFS are caused by missing dependenices (because the package isn't there anymore, the version is wrong, the package is not available for whatever reason and so on). Sometimes, a give-back is enough to fix these issues; sometimes you need to fix something: it all depends on the actual problem behind that.

Depends on the type of the icon. xpm goes in pixmaps, png and other cachable icons in hicolor

  • Here, I read (https://wiki.ubuntu.com/PbuilderHowto) about pdebuild. In all examples in wiki.ubuntu, I read more debuild than pdebuild. So, I wonder about the advantage of pdebuild (as the man page is not very explicit and just say it gives a root environment before calling pbuilder).

Never used pdebuild in my whole life. :P I assume you can safely forget about it, or look at some wiki pages and play with it a little.

  • It seems that there is no way to put a commentary on the modification made with quilt (like # DP: for dpatch). Is it required?

quilt hasn't such a field. BTW, you can add a comment (preceeded by #) on the top of the patch, if you want.

  • In bash : ctrl+r for reverse search in history !N where N is the history line number

  • not sure to understand very well what --debbuildopts -b is used for when using pbuilder (I have noted this: How avoid that pbuilder is creating each time diff.gz, orig.tar.gz and .dsc in the .changes files: --debbuildopts -b)

--debbuildopts is used to send options to dpkg-buildpackage, and -b creates the binary package only, not the source one.

  • How to find which patch system is used (dpatch, quilt…)? Have a look at the builddeps (Build-Depends: debhelper (>= 4), halibut, libgtk2.0-dev, perl, quilt) or have a look at debian/rules.

...or use what-patch from the source tree root! Wink ;-)

  • In the change note, we can see that: 

Accepted:
 OK: crystalspace_1.2.1.orig.tar.gz
 OK: crystalspace_1.2.1-0ubuntu2.diff.gz
 OK: crystalspace_1.2.1-0ubuntu2.dsc
    -> Component: universe Section: games

I think that the "component" depend on where you put it manually when you upload the package (universe or multiverse for MOTU). The section is from debian/control. Is it correct?

Exactely.

  • how to know, from the build .deb what is the changelog (without having the .changes file)?

http://changelogs.ubuntu.com/ , maybe? Smile :) Jokes apart, if you install the deb, you will usually find the changelog in /user/share/doc/<package>/changelog.Debian.gz. Further, since .deb file is just an archive, you can unpack it, then unpack data.tar.gz and cd to that file. Since we are just speaking about that, unpacking the deb and browsing through its files is a nice excercise to understand what a .deb file actually is (in a few words, nothing more that a compressed directory structure and a few control files).

=> This has been done. I saw also a debian-binary file containing only 2.0. another control.tar.gz where we can find some control files that we created. But also, postinst, preinst and prerm script seemed to be generated (I think from debian/rules) by dh_pycentral. Do you know what it is used for?

postinst, preinst, prerm and postrm are the so-called Maintainer scripts. They are usually involved in allowing a smooth removal and upgrade of packages. You can find more informations about that in the Debian Policy, Debian Reference and Debian Maintainer's Guide. Another interesting document is this lesson by norsetto: https://wiki.ubuntu.com/MOTU/School/MaintainerScripts . BTW, Maintainer scripts are a pretty advanced topic, so you can safely ignore them (for now).

I assume that all the configuration scripts will be in control.tar.gz, preinst is before installing the package, postinst is after the package is set up and prerm is before removing the file (with --purge option). Is it correct? It is. They are just scripts, you can do (almost) whatever you want with them. More info on the documents I listed above.

In data.tar.gz, we find the installed files from /

  • sudo pbuilder update: you need to do it regularly, since your pbuilder chroot isn't updated when you issue apt-get update && apt-get upgrade.

  • auto-answers : the generic name seems to be used for the title bar of olive application Smile :)

  • what is the difference between debuild -S and debuild -S -sa ? (difficult to find any comment in the man page)

Maybe you should ask the difference between -sa and -sd. In a few words, -sa forces the inclusion of the orig.tar.gz; -sd forces the exclusion of orig.tar.gz and includes only the diff.gz. If you launch debuild without -sa or -sd, it will use -sa if the Debian revision is -0 or -1, -sd in other cases. You can easily understand this is done because you don't need to upload again orig.tar.gz if it is already in the archives when you just upload a minor revision (where orig.tar.gz doesn't change). You will not use these options during your contribution period (except for REVU and your PPA), since you just create debdiffs. Once MOTU, you will need to use it carefully to avoid either bandwith and time waste when -sa is misused, or a rejected upload when -sd is misused. BTW, you didn't found anything in the man page because debuild is a wrapper to dpkg-buildpackage, so you need to read man dpkg-buildpackage to find a full description for all the options.

  • first package built! I send you the debdiff by mail Smile :)

    • - next step, what to do? The debdiff must be sufficient for the patch, so:
      • - what do we send? there is the .changes which is signed and descriptive, .dsc to have the md5 of each files, debdiff, new diff.gz files...

-> attach your debdiff to the bug report, mark it as confirmed, unassign yourself, subscribe u-u-s

  • - ok, so what are the .changes used for ?

The .changes is used for the upload to the archives (or PPA, or REVU, or whatever). It is worth to be checked before uploading, to be sure that all the files to be uploaded are listed there, and that the changelog entries have been catched correctly with the -v option (especially when you are uploading a merge). Refer to man dpkg-buildpackage for more informations about the -v option.

  • Soyuz is the group of machine that accepts, build and publish packages

  • I try to manage categories now in the .desktop file: from what I understood (http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html), categories are used to correctly put the menu entry in the right place. So, I understand, by e.g. the use of "Categories=Game;", but why put some ahead precision, like "Categories=Game;BoardGame;" for instance.

-> do you have any idea on this?

  • Regarding the compile issue on intrepid of the package sgt-puzzles: I think that the package is currently dead on the automatic compiler. How to see which packages are on this stage? Do we have to fill a bug to fix it? Who mark it as confirmed (as normally, it is not the bug filler)?

-> cf http://qa.ubuntuwire.com/ and fill a bug

  • Proposed .desktop file: 

[Desktop Entry]
Version=1.0
Terminal=false
Exec=blackboxgame
Icon=blackbox
Type=Application
Categories=Game;BoardGame;
Name=Blackbox
Comment=Deduce position of balls

is it ok ?

The .desktop is ok, if the icon and binary have the right names. Testing it with desktop-file-install and verifying that it actually work in the true package is enough to be sure it will be accepted.

  • Development cycle.

Is this correct ?

=> sync from debian, freeze of import (until 26th of june). After, no new package (appart from exception). Ok, but for gnome, as its release is really near the end => exception for all gnome packages? No packaging work done until the end? That is to say that we only report bug and corrections to upstream, but not package it as the software will change later? Really good question. Well, Gnome has a permanent exception, so all Gnome-related packages are uploaded without any bureocracy. Other packages have an exception standing for the whole release cycle, like firefox3 during Hardy. The complete list is here: https://wiki.ubuntu.com/StandingFeatureFreeze (and will be updated soon)

  • how to manage localization on .desktop files?

translations are managed mostly through rosetta (https://translations.edge.launchpad.net/ubuntu). People can translate strings there (extracted from packages) and than translations are regularly collected in a package (language-packs) and made available to users. More informations on https://wiki.ubuntu.com/TranslationLifecycle and https://wiki.ubuntu.com/TranslatingUbuntu . => yes, but I was discussing indeed about my added .desktop files related to the bug, all the fields (names[countrycode]=...) will be added automatically to launchpad for translation? Had to be by transformed by hand by the packager

  • to apt-get source <last version of sgt-puzzles> I have to run Intrepid. So, I can't really make a fakeroot on intreprid running on hardy as I will just download the hardy version source and not intrepid one. How do you manage it? Directly downloading latest version on the web?

You don't actually need to run Intrepid to retrieve sources of packages in Intrepid. If you edit /etc/apt/sources.list you can change 'hardy' with 'intrepid' for your deb-src entry. In this way, when you do apt-get source, it will retrieve packages from Intrepid. BTW, remember to test your packages in Intrepid (a VM should be enough). I recommend you reading https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases for more informations.

Well, let's say it's a matter of tastes, and also you should consider what the original maintainer did to the package. If rules doesn't uses dh_install and uses "install" entries instead, just follow it. BTW, I encourage you to use dh_install (and debian/package.install) whenever is possible, since it is much reliable and easier to use and fix, avoids using lots of install entries in rules and takes care of everything needed to acutally install the files (even when a directory has to be created first).

  • what is the release team? We don't search for bug regarding its importance or milestone, but this team seems to deal with it.

We have two release team in Ubuntu: Ubuntu release and MOTU release. The latter one takes care of reviewing exceptions to the Feature Freeze in universe and multiverse. Ubuntu release does the same for main and restricted, has the final word on decisions regarding the release of Ubuntu, and actually oficially releases Ubuntu.

  • What are the different MOTU teams? There seems to be "MOTU Counci", "Desktop Team", "Server team", "Release team", ...?

MOTU Council is the body that takes decisions about MOTU activities and processes. It also approves new MOTUs and contributors. Other MOTU teams are just groups of people that take care of some packages. For example, MOTU-science looks after all the packages related with science, MOTU-torrent looks after the packages related to torrents, Ubuntu-QA is involved in Quality Assurance Activites for all the packages, and so on. We have many other teams that work on a particular field, for example Desktop Team works on GNOME, server team on packages related to server, etc.

No, confirmed is a good status for that bug. During the sponsorship process, when you are working on a bug you can set it to "in progress" and assign it to yourself. Once a debdiff is ready, attach it to the bug, de-assign yourself and mark the bug as "confirmed", and not "Fix committed" (that is used for other purposes). Once a sponsor uploads your work, the bug will be autoclosed ("Fix released") if you add (and you really should) a tag like (LP: #123456) in debian/changelog. -> ok, so, my question now is: how do you see that this patch is not commited (contrary to the one on my other question): following Mailing-List, installing intrepid and looking for the version number of the package in synaptic? or a web page to see last version of a package released in a specific version? --> well, there are several ways. First of all, if you click "overview" on launchpad you will see the version history for that package. Further, http://changelogs.ubuntu.com/ collects changelogs for the packages in the archives. One more way is pointing your browser to packages.ubuntu.com (or using rmadison) and checking what's the latest version.

You are right indeed. The problem there is a wrong autoclosing tag in debian/changelog: "(Closes: LP #234365)" instead of "(LP #234365)". Please, set the status to fix released. -> Done

Indeed. Please, untag it, and mark as "won't fix", meaning that we recognize the bug, but don't intend to actually fix it. Please, not that the bug affects both the package gnome-panel in Ubuntu and the project GNOME Panel (with a link to the upstream bug on bugzilla.gnome.org). The status of the bug upstream is auto-tracked, hence you need to close only the bug for the Ubuntu package. It is common to see a bug involving an Ubuntu package that is tracked in Debian and upstream too, so remember to distinguish them. -> Ok, understood. Seems to be logic to do not touch to copyright issue. So, I just put a commentary and untag it as I can't put the "Won't fix" status (not enough rights on LP).

Well, looks like an agreement about the documentation to be written has been reached, but noone actually wrote the docs, hence we can't say this bug is fixed. Please, let it as is (or fix it yourself! Smile :-) )

That's beacause it hasn't been actually fixed. The status of this bug is not so clear, and the last update on it is 4 months old. Maybe we should check that this bug is still present in Intrepid, and fix it if possible. Mind taking care of that? Please, try to reproduce the bug, or ask to the reporters if they still have this bug.

Not fixed yet. Iain fixed this bug in two different debdiffs. since the other debdiff fixes both bug #217232 and #124230, Cesare didn't uploaded the debdiff attached, and the other one is waiting for a sponsor.

  • When we link to a bug in upstream bugtracker, who take in charge of fixing it? upstream, us? How to decide who will take it in charge (linked with severity?) if the upstream dev doesn't respond.

Usually, upstream (or Debian) will be so kind to fix the bug. Of course, if you want, you can fix it yourself. Depending on how active and responding upstream is, and how important the bugfix is, we can fix it on our own, or wait for a move. There is not a golden rule, except that if you want to fix it, just do, send the fix upstream (who can even incorporate it in his own software and cheer your work), and be happy! Smile :)

  • For instance, there were today a SRU :

https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/245212 As I understand from my previous reading, SRU was done when it was really needed. Apparently, this is not the case there. So, what's the rules for this update? Well, pango is a pretty important package, and we had the need to bring the new pango release from intrepid into hardy. Since pango is an important one, the SRU has been applied and approved.

Try again, I am sure you will find an easy one. Consider subscribing to the bugs feed (http://feeds.edge.launchpad.net/ubuntu/latest-bugs.atom) or joining #ubuntu-bugs-announce to be informed of every new open bug on Launchpad.

CategoryMOTULog

Grold/Memorandum (last edited 2010-11-01 10:44:50 by klabs)