memorandum

Differences between revisions 17 and 18
⇤ ← Revision 17 as of 2008-08-04 19:45:12 →
Size: 21349
Editor: put92-5-82-243-237-71
Comment:
← Revision 18 as of 2008-08-05 19:30:06 → ⇥
Size: 20916
Editor: put92-5-82-243-237-71
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:

 * check again the FTBFS for sgt-puzzles and open a bug in LP
((
Also, I was waiting the sgt-puzzles package in the FTBFS list: http://qa.ubuntuwire.com/ftbfs/ but that's not the case, why?
According to rmadison:
sgt-puzzles | 7983-1 | intrepid/universe | source, amd64, i386
so, looks like it builds fine in i386 and amd64. Why do you think it FTBFS? Anyway, in case it actually FTBFS, that page is upgraded regularly, so maybe you just need to wait a bit.
))
 * then, correct https://bugs.launchpad.net/ubuntu/+source/sgt-puzzles/+bug/61039

 * Need also to search about application-registry, madison. If you have good documentation under the hand :)
Well, probably man madison is the right place to start. BTW, probably you are more interested in rmadison, an handy tool, much faster than packages.ubuntu.com.		 See also https://wiki.ubuntu.com/DidierRoche/MOTU/bugsaction
 * correct the FTBFS (https://bugs.launchpad.net/ubuntu/+source/sgt-puzzles/+bug/255086) for sgt-puzzles and https://bugs.launchpad.net/ubuntu/+source/sgt-puzzles/+bug/61039

 * work on a NBS

 * man quilt :)
Line 136: Line 130:

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
Line 140: Line 144:
== Remaining questions ==

 * read https://wiki.ubuntu.com/UbuntuDevelopment/NBS. From example1: when did the breakage with package libminc0 happened? The first time we synced from debian the minc package and the build was runned, normally, it had to link (magically with ${shlibs:Depends}) to libminc2-1 and not libminc0 as the source doesn't exist on intrepid. (Or does the source for package libminc0 had existed in intrepid, and then, have been removed?).

 * Is it possible to find those results (reverse dependencies) by command-line: http://people.ubuntu.com/~ubuntu-archive/NBS/libkcal2b ?		 == Pending questions ==

 * Is it possible to find the reverse dependencies by command-line like this for libkcal2b: http://people.ubuntu.com/~ubuntu-archive/NBS/libkcal2b ?
Line 242: Line 244:
-> 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. -> 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.

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

Read these last few days (will be regularly updated and removed)

TIPS

Find MOTU task

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

Important pages

Create desktop file

Auto bug response

versionning

<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

queuing and build

Special build option

  • Building without creating the source file: pbuilder --debuild

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

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

Questions & Actions

Pending questions

  • Is it possible to find the reverse dependencies by command-line like this for libkcal2b: http://people.ubuntu.com/~ubuntu-archive/NBS/libkcal2b ?

  • 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)

Old questions

  • 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.

  • 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"]

DidierRoche/MOTU/memorandum (last edited 2010-11-01 10:44:29 by klabs)