=== mruiz_away is now known as mruiz
=== bmk789_ is now known as bmk789
=== asac_ is now known as asac
* pitti waves15:55
* InsClusoe waves back..15:56
* db-keen stands aghast to be in the presence of InsClusoe15:56
InsClusoedb-keen: Pls don't say such things and embarass me...15:57
* pitti rings the schoolbell15:59
pittiso, who is here to learn about patching packages?15:59
pittiand how has the week been so far for you?16:00
rbr_I'm no programmer, just curious16:00
=== warp10 is now known as warp10_
AstralJavaHaven't had much time to follow other lessons, but plan to do so today. Great sessions ahead. :)16:00
pochuhey hey16:00
* warp10_ raises an hand16:01
pitticool, relatively quiet16:01
=== warp10_ is now known as warp10
pittiWelcome to the hands-on training session about how to patch Ubuntu source packages!16:01
pittiThis assumes that you already know what a patch is and how to handle .patch files in general (i. e. for upstream authors). Also, you should have a rough idea what an Ubuntu source package is.16:01
pittiThe purpose of this session is to teach you how to put a patch into an Ubuntu source package, since unlike rpm this is not very consistent still.16:02
pittiWhile I do some introduction, please install some packages and sources on your box which we will need for the training:16:02
pitti  sudo apt-get install dpatch cdbs quilt patchutils devscripts debhelper fakeroot16:02
pitti  mkdir training; cd training16:02
pitti  apt-get source cron udev pmount ed xterm16:02
pitti  wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch16:02
pitti  chmod 755 dsrc-new-patch16:02
pittiI deliberately picked the smallest packages I could find16:02
pittithis can run in the background while I continue16:03
pittiif anyone has any question, or I'm totally uncomprehensible (sorry for my English, I'm German), please do not hesitate to interrupt and ask *immediately*16:03
pittiAlso, don't bother trying to take notes, we'll sort that out at the end. You can fully concentrate on the discussion and examples.16:03
pittiok everyone?16:03
pittiLet's begin with a little bit of history:16:04
AstralJavaAlmost set.16:04
pitti== Why use separate patches ==16:04
pittiIn earlier times, people just applied patches inline (i. e. directly in the source code tree). However, this makes it very hard to extract patches later to modify them, send them upstream, etc. Also this means that new upstream versions are a pain, since they generate a lot of rejections when applying the package diff.gz to them.16:04
pittiWith split-out patches it is much easier to send them upstream, keep track of them, develop them, etc., since you always see which changes belong together.16:04
pittiThe ideal state is an unmodified tarball from upstream, plus clean and separate patches, plus the packaging bits in debian/. That means that lsdiff -z <sourcepackage>.diff.gz only contains debian/.16:05
pittiThe first attempts to split-out patches were pretty trivial: storing patches in debian/patches/, and adding some patch/patch -R snippets to debian/rules. This worked for small patches, but provided no tools for editing these patches, updating them for new upstream versions, etc.16:05
pitti(debian/rules is the central script for building a package, in case you don't know)16:05
pittiThus several standard patch systems were created which are easy to deploy and provide tools for patch juggling and editing.16:06
pittiWhat I would like to do now is to introduce the most common patch systems and show some hands-on demo how to add a new patch and how to edit one.16:06
pittiFor this, I will point at a source package from the current gutsy or hardy archive, quickly explain the patch system, and show how to apply some (braindead) modifications to it.16:06
pittiI recommend you to do the same steps in a terminal, so that you get a feeling for the process and can immediately ask questions.16:06
pittiis everyone fine with this approach?16:06
pitti= cron: inline patches ==16:07
pittiNo patch system at all, nothing much to say about this. So this is an example of the "old" style of packaging, a counter-example16:07
pittiYou directly edit the files in the source tree.16:07
pittiThis is convenient for a simple and quick change, but will bite back for new upstream versions (see above) and is inconvenient for submitting patches upstream, or reviewing for merges.16:07
pittiif you do 'lsdiff -z <package>.diff.gz' and you see changes which are not in debian/, then you probably have such a package16:08
pittii. e. in this case lsdiff -z cron*.diff.gz16:08
pitti(you can also take a look at it to see how all patches are lumped together)16:08
pittiso, I think I do not need to say anything else about cron, unless someone has a question16:08
pitti== udev: separate patches, but no standard patch system ==16:09
pittiThis case is the most complicated one since you have to do all the hard work manually.16:09
pittiIn order to make you understand what a patch system does, and to give you a fallback method that will *always* work with any patch system, I handle this first.16:09
pittiThe good news is that you will seldomly be required to actually do this procedure, since for many packages there are nice tools which make things a charm.16:09
pittiThe bad news is that it may seem utterly complicated for people who never did it before, but I would like you to understand what's actually going on behind the curtains of the tools.16:09
pittiBTW; when I'm too fast, don't hesitate to ping16:10
pittiSo please do not desperate if you do not fully understand it at first; there's written documentation and you can always take your time to grok it.16:10
pittiThe general approach, which you can print out and hang over your desk :) is:16:10
pitti1. copy the clean source tree to a temporary directory /tmp/old16:10
pitti2. apply all patches up to the one you want to edit; if you want to create a new patch, apply all existing ones (this is necessary since in general patches depend on previous patches)16:11
pitti3. copy the whole source tree again: cp -a /tmp/old /tmp/new16:11
pitti4. go into /tmp/new, do your modifications16:11
pitti5. go back into /tmp and generate the patch with16:11
pitti  diff -Nurp old new > mypatchname.patch16:11
pitti6. move the newly generated patch to <original source dir>/debian/patches/mypatchname.patch16:11
pittiin general we want the following diff options:16:12
pitti-N -> include new files16:12
pitti-u -> unified patches (context diffs are ugly)16:12
pitti-r -> recursive16:12
pitti-p -> bonus, you can see the name of the affected function in the patch16:12
pittidoes anyone have a question about the principle method?16:12
pitti(I'll do a hands-on example now)16:12
AstralJavaAll good here.16:13
warp10here too16:13
bobbosame here16:13
pittiso, open a shell, ready your fingers :)16:13
pittiudev example 1, let's create a new patch 92_penguins.patch:16:13
pitticd udev-* # -113 on gutsy, -117 on hardy16:13
pitti-> now we are in our original source tree where we want to add a new patch16:13
pitti  cp -a . /tmp/old16:14
pitti-> create a copy of the clean sources as reference tree16:14
pitti  pushd /tmp/old16:14
pitti-> go to /tmp/old; 'pushd' to remember the previous directory, so that we can go back conveniently16:14
pitti  debian/rules patch16:14
pitti-> apply all already existing patches; of course we could use the 'patch' program to do it manually, but since debian/rules already knows how to do it, let's use it. The actual name for the patch target varies, I have seen the following ones so far: patch, setup, apply-patches, unpack, patch-stamp. You have to look in debian/rules how it is called.16:14
pitti  cp -a . /tmp/new; cd ../new16:15
pitti-> copies our patched reference tree to our new work directory /tmp/new where we can hack in16:15
pittithat's the preparatory part16:15
pittilet's do a braindead modification now16:15
pitti  sed -i 's/Linux/Penguin/g' README16:15
pitti-> changes the README file; of course you can use your favourite editor, but I wanted to keep my examples copy&pasteable16:15
pittiand now we create a patch between the reference and our new tree:16:15
pitti  cd ..16:16
pitti-> go back to /tmp, i. e. where our reference tree (old) and hacked tree (new) is located16:16
pitti  diff -Nurp old new > 95_penguins.patch16:16
pitti-> generate the patch (Ignore the 'recursive directory loop' warnings)16:16
pitti  popd16:16
pitti-> now you should be back in your original source tree (when you did the pushd)16:16
pitti  rm -rf /tmp/old /tmp/new16:16
pitti-> clean up the temporary trees16:16
pitti  mv /tmp/95_penguins.patch debian/patches16:16
pitti-> move the patch from /tmp to the source tree's patch directory, where it belongs.16:16
pitti*uff* :)16:16
pittiNow take a look at your shiny new debian/patches/95_penguins.patch.16:16
pittiand give a ping when you are ready16:17
* warp10 is ready16:17
pittigreat, that goes very smoothly today :)16:18
pittiif you do 'debian/rules patch', you'll see that the patch applies cleanly16:18
pittiwarp10, AstralJava, dargol, db-keen: caught up?16:18
warp10pitti: sure!16:19
AstralJavaYeah, sorry was AFK for a bit.16:19
pittiso, obviously that's not the end of the wisdom, but if you do these steps a couple of times, you should get a feeling for how to create the most complicated patch conceivable16:20
pittiso this procedure is the life safer if anything else fails16:20
pittiquestions so far?16:20
AstralJavaNope. :)16:20
pitti(just drop them into #-chat)16:20
pittiPretty much work, isn't it? Since this happens pretty often, I created a very dumb helper script 'dsrc-new-patch' for this purpose.16:20
pittiFirst, let's bring back udev to the previous state by removing the source tree and re-unpacking the source package:16:21
pitti  cd ..16:21
pitti  rm -r udev-*16:21
pitti  dpkg-source -x udev_*.dsc16:21
pittiThen, using my script, above steps would reduce to:16:21
pitticd udev-*16:21
pitti  ../dsrc-new-patch 95_penguins.patch16:21
pitti^ this now does all the preparation for you and drops you into a shell where you can edit the code16:22
pitti  sed -i 's/Linux/Penguin/g' README16:22
pitti  <press Control-D to leave the subshell>16:22
pittithat looks slightly better, doesn't it?16:22
pittilook at debian/patches/95_penguins.patch, it should look exactly like the one created manually16:23
pittiIf you like the script, please put it into your ~/bin, so that it is in your $PATH16:23
pittibut I had to torture you with the close-to-the-metal method for the sake of understanding.16:23
pittiYou might have noticed that we applied all previous patches before creating our's. Does someone have an idea why this is done?16:23
warp10some patches could depend on other patches16:24
pittiwhich means?16:24
AstralJavaThey need to be applied in order.16:24
AstralJavacorrect order, that is.16:24
dargolthey coud only aply to the patched source16:24
pittii. e. patch 22 can change the same file that patch 7 did, and patch 22 might not even apply to the pristine upstream source.16:25
pittidargol: exactly16:25
pittiThat's why you will commonly see numeric prefixes to the patch files, since they are applied asciibetically in many patch systems (including the application of patches in udev).16:25
pochuwith that script I won't need dpatch-edit-patch anymore ;)16:25
pittipochu: oh, you do16:25
pittiwe'll get to that later16:25
pittidsrc-new-patch is a hack which mostly works for packages without a real patch system, but split-out patches16:26
pittilike udev16:26
pitti(which is really a bug we should fix)16:26
pittibut makes a nice example :-P16:26
pittiSince above procedure is so hideously complicated, patch systems were invented to aid you with that.16:26
pittiLet's look at the most popular ones now (they are sufficient to allow you to patch about 90% of the archive's source packages; for the rest you have to resort to the manual approach above).16:26
pochuah, found it16:26
pittidargol: ?16:26
pitti== pmount: cdbs with simple-patchsys ==16:27
dargol(wrong place)16:27
pitticdbs' simple-patchsys.mk module matches its name, it has no bells and whistles whatsoever.16:27
pittiHowever, it is pretty popular since it is sufficient for most tasks16:27
pittiand long ago I wrote a script 'cdbs-edit-patch' which most people can live with pretty well.16:27
pittiThis script is contained in the normal cdbs package.16:27
pittiYou just supply the name of a patch to the script, and depending on whether it already exists or not, it will create a new patch or edit an existing one.16:27
pitti(dsrc-new-patch can currently *not* edit existing patches, mind you; patches welcome :-)16:28
pittibut real patch systems can do that of course16:28
pitti  cd pmount-*16:28
pittieveryone please look in debian/patches, debian/rules to get a feeling how it looks like16:28
pittii. e. in debian/rules you simply include simple-patchsys.mk, and that'll do all the magic16:28
pittiand debian/patches looks pretty much like udev16:28
pittiso, let's mess up pmount a bit16:29
pittiand add a new patch16:29
pitti  cdbs-edit-patch 07-simple-readme.patch16:29
pitti  echo 'This should document pmount' > README16:29
pitti  <press Control-D to leave the subshell>16:29
pittieasy, isn't it?16:29
pittithis will take care of applying all patches that need to be applied, can change patches in the middle of the stack, and also create new ones16:29
pittiEditing an already existing patch works exactly the same way.16:31
pittiso I won't give a demo16:31
pittiBTW, "cdbs-edit-patch" is slightly misleading, since it actually only applies to simple-patchsys.mk. You can also use other cdbs patch system plugins, such as dpatch or quilt.16:31
AstralJavaNothing at the moment, no. :)16:32
pitti(sorry, some #-chat action going on)16:32
AstralJavaAll good, all good. :)16:32
pitti== ed: dpatch ==16:32
pittidpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch'16:32
pittipackages which use this build-depend on 'dpatch', and debian/rules includes 'dpatch.mk'16:32
pittiThe two most important things you should be aware of:16:33
pitti * dpatch does not apply debian/patches/*, but instead applies all patches mentioned in debian/patches/00list, in the mentioned order. That means that you do not have to rely on asciibetical ordering of the patches and can easily disable patches, but you have to make sure to not forget to update 00list if you add a new patch.16:33
pitti(forgetting to update 00list is a common cause of followup uploads :-) )16:34
pitti * dpatch patches are actually scripts that are executed, not just patches fed to 'patch'. That means you can also do fancy things like calling autoconf or using sed in a dpatch if you want.16:34
pittiusing dpatch for non-native patches is rare, and normally you do not need to worry about how a .dpatch file looks like16:34
pittibut I think it's important to mention it16:34
pittiso if you ever want to replace *all* instances of Debian with Ubuntu in all files, write a dpatch with a small shell script that uses sed16:35
pittiinstead of doing a 300 KB static patch which won't apply to the next version anyway16:35
pittiThe manpage is very good and has examples, too, so I will only give one example here:16:35
pittiThis will edit an already existing patch and take care that all previous patches are applied in order:16:35
pitti  cd /whereever/you/unpacked/the/source/ed-0.716:35
pitti(if you are still in the pmount directory: cd ../ed-0.7)16:36
pitti  dpatch-edit-patch 05_ed.1-warning-fix16:36
pitti  <edit stuff, press Ctrl+D>16:36
pittiso that's exactly like cdbs-edit-patch16:36
pittiok, now we edited a patch, that's pretty easy, right?16:36
pittinow let's create a new one; this is different from cdbs-e-p16:37
pitti  dpatch-edit-patch foo 07_ed.1-spelling-fixes16:37
pitti  <edit stuff, press Ctrl+D>16:37
pitti  echo foo.dpatch >> debian/patches/00list16:37
pitti^ this is the new bit; you have to explicitly add a new patch to that 00list index file16:37
pittiThis will create a new patch foo.dpatch relative to the already existing 07_ed.1-spelling-fixes.dpatch.16:38
pittiIf your patch is very confined and does not depend on other patches, you can leave out the second argument.16:38
pittiBTW, you even have bash commandline completion for dpatch-edit-patch!16:38
AstralJavaFine here. :)16:39
pittidb-keen, phoenix24: ok?16:39
pitti== xterm: quilt ==16:40
pittiquilt is the other non-dumb standard patch system. Like dpatch, it has a list of patches to apply in patches/series (to use debian/patches, packages need to add a sylink).16:40
pittior set $QUILT_PATCHES to debian/patches16:41
pittiIt is non-trivial to set up and has a lot of advanced commands which make it very flexible, but not very easy to use.16:41
pittinontrivial to set up for Debian source packages, that is16:41
pitti(it's not hard either, but more work than simple-patchsys, and even dpatch)16:41
pittiit's not that widespread, but common enough to handle it here, and it apparently gains more popularity16:41
pittiI will only show a small example here16:41
pitti  cd /whereever/you/unpacked/the/source/xterm-22916:42
pittiif you followed me exactly, that should be cd ../xterm-22916:42
pitti  export QUILT_PATCHES=debian/patches16:42
pittiThis is necessary because the default patch directory for quilt is ./patches. But for Debian-style source packages we want to keep them in debian/patches, because that's the convention.16:42
pittiNow let's edit the already existing patch 901_xterm_manpage.diff:16:42
pitti  quilt push 901_xterm_manpage.diff16:42
pittithis will apply all patches in the stack up to the given one16:43
pittiapply inline right in the source tree, that is16:43
pittiunlike quilt, cdbs-edit-pattch, and dpatch-edit-patch, quilt doesn't create temporary directories with a copy, but remembers old versions of the files and uses the normal working tree16:43
pittia bit like version control (svn, bzr, etc.)16:43
pittinow let's edit a file that is already touched by the original patch16:43
pitti  sed -i 's/Copyright/Copyleft/' xterm.man16:44
pittilet's commit the change:16:44
pitti  quilt refresh 901_xterm_manpage.diff16:44
pitti^ updates the patch file with your recent changes16:44
pitti  quilt pop -a16:44
pitti^ unapplies all patches to go back to pristine source tree16:44
* pitti waits a bit for people to catch up and finish the example on their keyboards16:45
pittiok everyone?16:45
bobboyep, done16:45
pittilook at debian/patches/901_xterm_manpage.diff to see the effect16:45
cprov-out#join ubuntu-classroom-chat16:45
* pitti hands cprov-out a slash16:45
cprov-outsorry ...16:45
pittiFinally, let's add a new patch to the top of the stack:16:46
cprov-outpitti: thanks ;)16:46
pitti  quilt push -a16:46
pitti'-a' means 'all patches', thus it applies all further patches after 901_xterm_manpage.diff up to the top16:46
pitti  quilt new muhaha.diff16:46
pittiregister a new patch name (which we want to put on top of the patch stack)16:46
pitti  quilt add README16:46
pittiyou have to do that for all files you modify, so that quilt can keep track of the original version16:46
pittithis tells quilt to keep track of the original version of README16:46
pitti  sed -i '1 s/^/MUHAHA/' README16:47
pittimodify the source16:47
pitti  quilt refresh16:47
pittiupdate the currently edited patch16:47
pitti  quilt pop -a16:47
pittithis will finally create debian/patches/muhaha.diff with the changes to README16:47
pittias I already said above, quilt has a patch list, too16:47
pittiin debian/patches/series16:47
pittiwhich is much like debian/patches/00list for dpatch16:48
pittiexcept that you don't edit it manually usually16:48
pittiif you push -a, then the patch will land on top of the patch stack, and will automatically be put at the end of series16:48
pittiof course you can create the patch in other levels of the patch stack16:48
pittisometimes, when you pull changes from upstream CVS, it's better to put them at the bottom of the stack16:48
pittii. e. upstream changes shuold generally come *before* distro-specific changes16:48
pittisomeone has an idea why this is done?16:48
pittior, rather, should be done16:49
dargolsame as before, upstream changes are only guarantied to work on original source16:50
pittifirst that16:50
pittiand second, it forces you to port your local patches to the updated source16:50
pittiso that, when you update to a new upstream version which incorporates the patch, it's much easier16:51
pittii. e. the closer to upstream a patch is, the more stable are your distro patches16:51
pittiok, that was the hard bit :)16:52
pitti== A glimpse into the future ===16:52
pittiAs you saw, Debian source packages do not have any requirements wrt. structure, patch systems, etc.16:52
pittiother source package systems like SRPM are much stricter wrt that.16:52
pittiThis of course means more flexibility, but also much more learning overhead.16:52
pittiAs a member of the security team I can tell tales of the pain of a gazillion different source package layouts... :)16:52
pittithere has been an attempt to teach an official patch system to dpkg itself ("dpkg 2.0", aka. "Wig&Pen format")16:53
pittibut unfortunately development on it has ceased16:53
pittiTherefore some clever people sat together the other day to propose a new design which would both give us a new and unified source package and patch system that uses bzr (with a quilt-like workflow).16:53
pittiThis would also integrate packages and patches much better into Launchpad and revision control in general.16:53
pittiPlease take a look at https://wiki.ubuntu.com/NoMoreSourcePackages if you are interested in this.16:54
pittiso, thanks a lot for your attention!16:54
pittiI hope it was a bit useful for you16:54
pittiwe have five more minutes for Q+A16:54
pittihttps://wiki.ubuntu.com/PackagingGuide/PatchSystems is some written documentation about patch systems16:55
pittia nice reference about what I explained here16:55
AstralJavaCan't come up with any questions really at this point, but thanks very much Martin for this session! :) Highly beneficial to over the steps in correct order and manner. :)16:56
pittiwarp10| QUESTION: If I need to apply a patch to a brand new package, or to fix a bug, or whatever, and a patchsystem has not been deployed yet, which (or how) should I choose?16:56
pittithat's mostly a matter of taste16:56
pittiif adding a patch system is actually justified in terms of keeping the delta to Debian low, then I'd give the following guidelines:16:56
pitti * if the package already uses cdbs, simply include simple-patchsys.mk and add the patch16:57
pittino question with this, that's unintrusive16:57
pitti * if the package doesn't use cdbs, and you get along with dpatch, use that16:57
pitti(please ask questions here now)16:58
pittiETA for NoMoreSourcePackages is currently undefined16:58
pittiright now we try to push forward the complete bzr import of ubuntu packages16:58
pittiwhich is a first step16:58
pochuQUESTION: do you know where to find some good documentation regarding working with .rej files? (as we don't have time now to explain it)16:58
pittiI don't know docs, sorry16:58
pittibecause at that point it's really common sense and experience16:59
pittiif there was a programmatic way how to resolve them, we wouldn't need them in the first place :)16:59
pitticdbs-edit-patch and dpatch-edit-patch will deal with it16:59
pittii. e. if a patch doesn't apply, they give you the .rej, you resolve them manually and Ctrl+D16:59
pochuthat's what I mean, how to resolve them16:59
pittimake sure to delete the .rej after resolving17:00
pittithey deliberately don't ignore .rej files17:00
pittijust to make sure you don't accidentally overlooked them17:00
pittiok, my time is up17:00
dargolthank you for the class!17:00
pochuthanks pitti17:00
bobbothanks pitti17:00
pittiplease continue questions to me personally or in -chat17:00
AstralJavaThanks again, that was super. :)17:00
pittithanks everyone!17:00
warp10thank you pitti, that was very interesting :)17:01
cprov-outpitti: great, thank you.17:01
phoenix24thanks pitti!!17:01
cprov-outright, about time to start PPA session ...17:01
cprov-outWho is here for the PPA session (take 2) ?  (say +1)17:02
snewlandI will sit this one out, sorry17:03
cprov-outwell, I guess, we have to continue with a smaller audience that the last session ... np17:03
cprov-outso questions can be asked in #ubuntu-classroom-chat ...17:04
cprov-outIn the last session, we have started with the 3W approach (WHAT - WHERE - WAIT) to teach people how to use PPAs. See the session transcription in  https://wiki.ubuntu.com/MeetingLogs/devweek0802/PPAs1.17:04
cprov-outAs a brief summary of the PPA cycle:17:04
cprov-out * WHAT: signed source uploads (reusing orig.tar.gz from ubuntu Primary archive);17:04
cprov-out * WHERE: tell dput to upload it to ppa.launchpad.net (override changesfile target if you want);17:04
cprov-out * WAIT: wait the source to be built (restart the cycle if you received a build-failure-notification).17:04
cprov-outI'm very happy to say that the last LP release (done on Wednesday) make the 'WAIT' stage very shorter17:05
cprov-outnow a build request is queued immediately after we recognize the new source, so the only waiting involved in the PPA cycle is related to the buildfarm load17:06
cprov-outwe currently have 3 i386, 3 amd64 and 3 lpia builder, which is quite enough to make everyone happy :)17:06
cprov-outsorry, 'LP release' was a confusing term17:07
cprov-outI was referring to the last Launchpad codeline release, which happened 2 days ago17:07
cprov-outa new set of features in Launchpad is released every month ...17:08
cprov-outPPAs ... Let's sort some questions, I don't believe you don' t have any ?17:09
cprov-outphoenix24: QUESTION: Could you tell a little about PPA ?17:09
phoenix24Nope, None.17:10
cprov-outyou can check the transcription of the last session, but briefly  it a 'parallel instance of the services used to maintain ubuntu primary archive'17:11
cprov-outit's a *public* service and anyone using Launchpad is welcome to try.17:11
cprov-outit allow any user to upload, build, publish and distribute their own packages17:12
cprov-outyou just need to be familiar with debian/ubuntu development tools to build the source package you want to change, all the rest is done by Launchpad.17:13
cprov-outphoenix24: does it answer you question ?17:13
cprov-outwarp10: QUESTION: Why doesn't LP provides a sparc builder too?17:13
phoenix24Yes, thanks!17:13
cprov-outwarp10:  the PPA builders are based in XEN VMs for proper isolation of the sources being built, and XEN doesn't support sparc officially17:14
cprov-outwarp10: yet ...17:14
cprov-outwarp10: QUESTION: Do PPAs build packages just like Soyuz does? I mean: If a package builds fine on a PPA, may I be 100% sure that it will build fine with buildd?17:15
* warp10 likes the "yet ..." :-)17:15
cprov-outwarp10: yes, the 'ubuntu infrastrucure' mentioned above is Soyuz. I'm glad you actually notice it :)17:16
cprov-outwarp10:  yes, I've read sometime ago that there were some effort on the sparc XEN port. I'm sure out IS team will be more than happy to adopt it when it gets official and stable enough.17:17
cprov-outwarp10: QUESTION: can you anticipate plans for future improvements of PPA? What kind of new features are to be implemented?17:17
cprov-outwarp10: yes, I can ... the current focus of our sub-team is allow quicker and simpler workflow to get work done in PPAs merged into ubuntu17:18
cprov-outwarp10: for instance the REVU application (MOTU review system) which is the path to get new source officially uploaded to ubuntu17:19
cprov-outthat's pretty much it, 'integration' is the word to define our goals in the next 2 or 3 months17:20
cprov-outsecretlondo: QUESTION: how much space do we get for our PPA - and are there ways of increasing it?17:21
cprov-outsecretlondo: by default you get 1GiB, but it can be increased by an launchpad administrator by request17:22
cprov-outsecretlondo: you simply need to justify why you need more space, for instance, 'I'm playing with firefox3 and openoffice packages' :)17:22
cprov-outwarp10: sorry, I didn't answered you question about what are the main differences of PPA backend and Ubuntu backend17:23
cprov-outwarp10: first, we automatically override all package uploaded to PPA to the main component17:24
cprov-outwarp10: in the case it is being copied/synced to ubuntu primary archive it won't necessarily like in main and will be submitted to other ogre-model restricitions.17:25
cprov-outPPA builders also don't extract translations neither mangles the package information as they would do in ubuntu primary archive.17:26
cprov-outThose are the only simplifications we have in PPA that makes it slightly different than the ubuntu primary archive.17:27
cprov-outAFAICS, none of this should be a problem from the development print of view and they help users to get their job done in a quicker way.17:27
cprov-outwarp10: did I addressed all the points you wanted ?17:28
warp10cprov-out: you absolutely did, thank you :)17:28
cprov-outtamrat: QUESTION: I get the error "Signer has no upload rights at all to this distribution." when I try to upload sth to my personal archive. What could be wrong?17:29
cprov-outtamrat: you are possibly not uploading to your PPA, but instead to ubuntu, check your ~/.dput.cf config17:29
cprov-outtamrat: ensure you are using the target with 'incoming = /~<username>/ubuntu/'17:30
cprov-outokay, I have a question myself: QUESTION: how do I delete a package from my PPA ? How long does it takes to be removed from my archive ?17:32
cprov-outanyone interested ?17:32
cprov-outUse +me/+archive/+delete-packages UI (allowed for PPA owners or team-admins), select one or more of the published sources and type a comment. The will be immediately marked as DELETED in the UI, within 20 minutes they won't be listed in the archive indexes and they will be removed 24 hours after the deletion (the remover runs every night).17:32
cprov-outphoenix24: ehe, thanks. I was feeling alone.17:33
phoenix24QUESTION: It's a very generic question, what's the utility of providing PPAs ?17:33
cprov-outphoenix24: in very basic terms, it allow more contributions to the ubuntu itself17:34
cprov-outphoenix24: we are looking for very talented people not yet added in ubuntu-keyring ;)17:34
cprov-outkidding, but that's the real goal of PPA. It's meant to allow more an more people to be able to contribute with FOSS17:35
phoenix24To me PPA's seem to be, like personalized.. Package-Builders with StorageSpace & Computational power.17:36
cprov-outsecretlondo: QUESTION: does the changes in translations between PPA and soyuz mean that localisation doesn't work on PPAs? Or is that just connected to rosseta?17:36
cprov-outsecretlondo: yes, PPA doesn't support changes in translation, neither bugs, atm17:36
cprov-outphoenix24: right, I prefer to see the effects in people, behind the machines/systems.17:37
secretlondoI think it's great that i'll have my own little repo to play with :)17:37
phoenix24Yesh! that's likely.17:38
cprov-outQUESTION: How can I sign my PPA repo ? It's so annoying atm !17:38
cprov-outwho wants to know about it ? :)17:39
cprov-outI knew it ! ;)17:39
phoenix24tellme tellme!!17:39
cprov-outright, we are working on a the infrastructure bits to allow signed PPAs17:40
cprov-outfirst, let me explain why we will not signed them with a single 'Launchpad PPA' key as we do in the ubuntu archive17:40
cprov-outif we do that, we would be hiding the problem under the carpet .., the things we expect to have by using a signed/trusted information wouldn't be exactly reached17:42
cprov-outwe would create a system that would sign *anything* that it was request to ...17:43
cprov-outa user would trust it once and install *everything* coming from LP PPAs w/o any warning.17:44
cprov-outwhat we will provide is a mechanism that you can trust effectively. Launchpad will handle unique GPG keys for each PPA and do the signature/revocation on demand.17:45
cprov-outI promise to give you more details in the next ubuntu-week :)17:46
cprov-outwhen it will be probably implemented.17:46
cprov-outany other questions ?17:47
* phoenix24 is reading the previous PPA talk.17:48
cprov-outwe have 10 minutes yet, maybe you want to discuss previous rejection-messages you have upload stuff to your ppa. Let me find one.17:52
cprov-outQUESTION: what does "MD5 sum of uploaded file does not match existing file in archive" error means ?17:54
cprov-outit means that there is already a file with the same name published in ubuntu or in your PPA, it usually refers to a different orig.tar.gz17:55
cprov-outups: QUESTION: After deleting a package from the PPA, can I re-upload the same version again?17:56
cprov-outups: good question, thanks17:56
upsi've tried it, unsuccessfully :)17:56
cprov-outups: yes, you can, but you will have to wait it to be removed from the archive, normally 24 hours17:57
cprov-outups: and there is also a issue with the origs files being hold by previous publications, the deleted candidate won't be removed17:58
upscprov-out: not sure i understood the last statement17:58
cprov-outups: the best approach is to always use a higher source version17:59
cprov-outups: it's complicated, but let's say you have foo-bar_1.0 published in gutsy and you uploaded foo_1.1 (using the same orig.tar.gz) to hardy17:59
cprov-outups: if you request foo_1.1 deletion, it won't be removed from disk because foo_1.0 is requiring the orig to remain published18:00
cprov-outups: do you see how the removals in a poll-based repository works ?18:01
upsok, that's what happened when i tried it18:01
* dholbach hugs cprov-out18:02
cprov-outups: so, bump the version and forget about this, diffs and dsc are very small18:02
upsthat explains it, thanks18:02
cprov-outdholbach: thanks, it's all yours.18:02
cprov-outups: great, thanks you for asking.18:03
dholbachthanks a lot cprov-out for a great session - you rock!18:03
dholbachyou all enjoyed the cprov PPA show? :)18:03
cprov-outthank you all for attending the session18:03
* ups nods18:03
AstralJavaThanks a lot Celso! Great answers.18:03
* polopolo missed it :(18:03
dholbachBring it On!18:03
dholbachnext up is the MOTU Q&A Session18:03
dholbachit's a session we have each Friday, usually at 13:00 UTC in #ubuntu-classroom18:04
dholbachso if you have any questions, any problem you want a few people to look at, there's an hour dedicated just for that18:04
dholbachof course there's always #ubuntu-motu and the mailing lists, but it's usually a smaller audience and a nice get-together :)18:05
LucidFoxHow do I make one specific dependency ignored by dh_shlibdeps?18:05
dholbachwe usually start with introduction so we know who's new and who just joined the contributors world18:05
* dholbach is Daniel Holbach, MOTU for quite a while and hopes you all enjoyed UDW as much as I did18:05
dholbachwho else is here?18:06
dholbachjust secretlondo and LucidFox? :)18:06
* AstralJava is18:06
reconand me.18:06
* warp10 is Andrea Colangelo MOTU contributor who would like to see a Developer Week... well... every week! *grin*18:06
jpatrickdholbach: hi :)18:06
akshayI am Akshay Dua and this is my first time in a ubuntu chat room. I am currently working through the packaging guide.18:06
secretlondoI'm Caroline Ford, I'm a bug traiger who is involved in tuxpaint upstream. I intend to learn packaging and become a MOTU (eventually)18:07
akshayoh, and hi everyone18:07
* recon is the n00b trying to find something to package. And failing.18:07
dholbachBRING IT ON! That's the spirit and what I'd like to hear! :-)18:07
* LucidFox is Matvey Kozhev, a recently approved MOTU and beginning Debian contributor18:07
* Iulian is Iulian Udrea and would like to join the MOTU world18:07
dholbachperfect :)18:07
* polopolo already asked a question btw18:07
db-keenDaniel Brumbaugh Keeney is the slow builder of a great Ruby Debian packaging machine called Tanzanite18:07
dholbachok... we have a few questions in the queue already18:07
dholbach<LucidFox> How do I make one specific dependency ignored by dh_shlibdeps?18:08
dholbachLucidFox: can you explain to those who just came here what dh_shlibdeps is for... in a nutshell18:08
LucidFoxdh_shlibdeps is a script for debian/rules that automatically fills dependencies for a package based on shared libraries its binaries link with18:09
reconthat sounds useful.18:09
dholbachit's the best thing since sliced bread :)18:09
dholbachso if you add   ${shlibs:Depends}  as a variable to the Depends: line of your package in debian/control in the end it will have all the library dependencies automagically filled in18:10
dholbachLucidFox: I just heard of cases where that was necessary 2 or 3 times - the only solution I seem to remember right now is messing with debian/substvars18:10
recondholbach: well, if you wanted to ignore a dependency, couldn't you just edit it out of the control file?18:11
dholbachLucidFox: I think one package was ffmpeg or some media library18:11
dholbachLucidFox: and the other one libgoffice (because it built a -gtk and a -gnome variant) or something18:11
* eddyMul is Eddy Mulyono, packaged a bunch of stuff for Gentoo, and now looking at helping out Ubuntu18:11
james_w"dh_shlibdeps -- -xpackage-name" is worth a try18:11
dholbachrecon: no, because you have just ${shlibs:Depends} there which gets all the library depends automatically filled in18:12
LucidFoxrecon> No, the dependencies are generated during build and inserted into the deb's control file, and debian/control is untouched18:12
james_w<-- James Westby, MOTU hopeful18:12
secretlondoI can see a situation if you are backporting something - eg dapper doesn't have SDL_pango, and programX can be compiled without it18:12
dholbachLucidFox: better to try what james_w said first :)18:12
dholbach<polopolo> QUESTION: what ask the ubuntu team of its MOTU? or: what do you first to know before you are motu?18:12
james_wsecretlondo: in that case you would normally edit the "Build-Depends" to remove the package so that it wasn't linked with.18:13
LucidFoxsecretlondo> in this case, it's usually sufficient to remove the -dev package from debian-control, in some cases also pass a --disable-X argument to configure18:13
* RainCT is Siegfried Gevatter, MOTU since some weeks and hoping to become a DD someday18:13
secretlondook thanks18:13
* jpatrick is Jonathan Davies, MOTU (~2 years) and Debian contributor18:14
dholbachpolopolo: I answered that question on http://wiki.ubuntu.com/MOTU/FAQ - it seems to be a regular question coming up "Do I need to know a lot of programming languages to become a MOTU?"18:14
dholbachlet me quote from the wiki page18:14
dholbachMuch more important than having a lot of progamming experience is18:14
dholbach * being a good team player18:14
dholbach * learning by reading documentation, trying things out and not being afraid to ask questions18:14
dholbach * being highly motivated18:14
dholbach * having a knack for trying to make things work18:14
dholbach * having some detective skills18:14
dholbachpolopolo: I know it's kind of hand-wavy but I hope it helps to answer your question18:14
james_w * like being hugged by dholbach18:14
* dholbach hugs james_w :-)18:15
dholbach<akshay> QUESTION: I am confused about the differences between the use of the underscore and the hyphen while packaging. Why are they needed? Which one to use when?(<package>-<version> vs <package>_<version>)18:15
polopolodholbach: yes, you have, thank you18:15
dholbachakshay: use the hyphen in the version number in debian/changelog and the underscore when you name the files18:15
akshaygreat, thanks!18:15
dholbachso it's        gedit_2.23.4.orig.tar.gz    and   gedit_2.23.4-0ubuntu.diff.gz18:16
dholbachbut it's 2.23.4-0ubuntu1 in the debian/changelog18:16
dholbachok great18:16
dholbach<recon> QUESTION: Why would you need a seperate chroot to make packages, ala pbuilder, as opposed to the rest of your system?18:16
dholbachrecon: pbuilder is useful because it helps you to pinpoint which build-depends you need exactly18:16
recondholbach: ...should'a thought of that one.18:17
dholbachrecon: I usually tend to have lots and lots of libraries installed on my regular machine, but that's not what happens on the build daemon: the buildd takes a minimal chroot, then adds only the Build-Depends18:17
RainCTrecon: and you don't need to install all build dependencies on your machine18:17
dholbachalso it's a "clean system"18:17
dholbachright, good point RainCT18:17
dholbach<db-keen> QUESTION: .desktop files belong in different places depending on kde3/kde4/gnome. How is this usually handled in a debian package?18:17
james_wrecon: it also allows you to build for a release that you are not running, e.g. to backport to dapper.18:18
dholbachdb-keen: they are just installed into one place18:19
dholbachas I understand it gnome-panel (for example) understands where to look them up18:20
dholbachplease correct me if I'm wrong - I never dived into this18:20
RainCTUntil now I installed everything in /usr/share/applications/18:20
dholbachRainCT: that's where I install .desktop files to too18:21
RainCTthere is some directory for KDE but I'm not sure how this works.. perhaps jpatrick or someone other can elaborate on this18:21
dholbachwhat I've experienced is that menu entries for KDE files pop up in my menu even if I use GNOME, so if KDE3/4 uses a different directory, they still are shown :)18:22
dholbach<secretlondo> QUESTION: (sorry if this is the wrong session). What is a "native package" - I've read that the underscore vs hyphen thing is connected to "native packages"18:22
RainCTand then .desktop files can also be used for stuff other than the menu, placing the file in some special directory, but I don't know neither how this works...18:22
dholbachsecretlondo: that's a good question - it gets asked a lot :)18:22
dholbachsecretlondo: a non-native package is the "usual" case where you take an upstream tarball directly from their website, rename it to        <software>_<upstreamversion>.orig.tar.gz18:23
dholbachthen extract it, add the debian/ubuntu packaging, then build the source package18:23
dholbachand get a <software>_<upstreamversion>-<ubunturevision>.diff.gz18:24
dholbachso it's a clear separation between 'upstream code' and 'distro code'18:24
* secretlondo nods18:24
akshaynow i understand more...thanks for the question secretlondo18:24
dholbachin the case of a native package, it's all just one .tar.gz18:24
dholbachso for example ubuntu-artwork which has no released upstream tarball18:24
dholbachit's    ubuntu-artwork_45.tar.gz18:25
dholbachno .diff.gz18:25
dholbachno "ubuntu revision" number18:25
dholbach<akshay> QUESTION: Where can I find the current distro revision? (e.g. <package>-2.23.4-0ubuntu1)18:25
dholbachakshay: can you try to rephrase your question? I'm not sure I understand18:25
dholbach<RainCT> akshay: what version number a package has in hardy, you mean?18:26
dholbach<akshay> RainCT: precisely18:26
RainCTakshay: you can find the version number checking on http://packages.ubuntu.com/<package name>18:26
dholbachif you run hardy, you can just run;    apt-cache showsrc <package>18:26
dholbachif you don't run hardy yet, you can either check out RainCT's page or http://launchpad.net/ubuntu/+source/<package>18:26
geseror use the rmadison tool from devscripts18:27
RainCTor if you have a hardy entry in /etc/apt/sources.list (a deb-src is enough, which you should have to be able to use "apt-get source") then you also see it with apt-cache18:27
dholbachwhat I really like is          aptitude changelog <source package>18:27
RainCTapt-cache show package | grep Version       will give you both, the version in Gutsy and the version in Hardy in that case18:27
akshayunderstood. Thanks.18:27
dholbachany more questions? any problems you ran into? things that are not quite clear from other sessions? things you've always wondered? like what james_w's favourite kind of music is?18:28
dholbach<polopolo> QUESTION: When I upload a package to REVU, but it's not possible to add it to hardy, should it be added to the next version or should I try it again when the time's comes again?18:29
dholbachpolopolo: always upload 'to the current development release'18:29
dholbachit should be quick enough to update to 'intrepid' once it's open :)18:29
polopolodholbach: ok I understood18:30
dholbach<akshay> QUESTION: What is the "XSBC" in  XSBC-Original-Maintainer?18:30
dholbachakshay: that's something I wondered myself18:30
dholbachand I think somebody asked it before, somebody else answered and I forgot it again18:30
RainCTX: User defined (not defined in the debian policy), SBC = the field should be visible in the Source, in the Binary and in the Changes file18:30
akshaydholbach:np I know what goes in the field so its ok18:31
norsettoX just mean is an extra-flag user defined18:31
norsettoSBC are for source, binary and control respectively18:31
dholbachakshay: there you go - it's always good to ask :)18:31
norsettomeans the field will be added to those packages18:31
akshaythanks guys18:31
RainCTnorsetto: what do you mean with 'control'?18:31
norsettoops, changes :-)18:32
RainCTcool, I didn't say it wrong :)18:32
polopolodholbach: well, if there are no questions, I wanna know why you are a part of MOTU? whatś the history in it?18:32
dholbachpolopolo: nice question :)18:32
dholbachback when I joined the MOTU team, I really should have spent the time on my thesis instead18:33
dholbachbut I had to update a library to a newer version and I had done it in a personal repository (PPA did not exist back then), so mvo (and others) encouraged me to do it right18:33
dholbachand join the team18:34
dholbachthe processes were all very different but what I liked so much about working in the Ubuntu team was the pioneer atmosphere18:34
akshaydholbach: I am doing my PhD too, do you advice against joining the MOTU now :)18:34
rZrmay i ask a question ?18:34
dholbachthere's always something to do, always something to take care of, new teams to found, people to plan new things with etc18:34
rZrabout yestaday package xnetcardconfig ?18:34
dholbachakshay: not at all - I finished my thesis on time :-)18:34
dholbachrZr: fire away18:35
akshaygreat, then I have nothing to worry about18:35
rZrI submited the debdiff18:35
* dholbach hugs akshay18:35
rZrand removed the original maintainer from debian/control18:35
akshayi feel loved18:35
dholbachrZr: I replied on the bug18:35
rZrsince the package never entered debian18:35
dholbachrZr: we usually don't do that unless we really intend to maintain the package18:36
akshaygot to go, this was a lot of fun. Will be back next week. bye18:36
rZrso i dont see why we should keep a reference to debian18:36
dholbachbye akshay18:36
james_wakshay: this session is normally earlier in the day, so don't get caught out.18:36
rZrdholbach: I plan to "adopt" this one and pushing into debian then18:36
RainCTbye akshay18:36
dholbachrZr: in this case the upstream author is listed as the maintainer18:37
dholbachrZr: you probably should get in touch with him before changing the maintainer field18:37
rZrok will do then18:37
dholbachrZr: I was just surprised you changed it18:37
dholbachok great18:37
dholbach<RainCT> QUESTION: Is the priority= field in debian/changelog used for anything in Ubuntu?18:37
dholbachRainCT: that's a good question for Kamion :)18:37
dholbachthe only use of it I know is that dpkg will complain if you tell it to remove an essential package18:38
LucidFoxRainCT> I assume you meant urgency?18:38
RainCTups, yes18:38
LucidFoxI've been wondering it as well18:38
dholbachoh, you mean urgency?18:38
dholbachurgency is not used at all18:38
dholbachit's pointless to change it18:38
LucidFoxwhile we're at it, what is priority in debian/control used for? Is there any difference between optional and extra for Ubuntu?18:39
RainCT(19:38:16) dholbach: the only use of it I know is that dpkg will complain if you tell it to remove an essential package18:39
dholbachLucidFox: I think that synaptic (and other package managers if they support it) will display it in different categories18:39
rZrdholbach: I feared that XSBC-Original-Maintainer field is tracked and generate unwanted trafic to debian ..18:39
dholbachit has its relevance in the policy, but that's all I know18:39
james_wessential is not actually part of the priority.18:39
rZrdholbach: since no process ever started regarding debian  and this package18:40
rZrno RFS or ITP18:40
LucidFoxrZr> If a package is actively maintained in Debian, Ubuntu generally commits itself to small, nonintrusive changes, and tries to push everything not Ubuntu-specific back to Debian18:40
dholbachrZr: no, it doesn't, we still set it for NEW packages (that never were in Debian)18:40
LucidFoxhence the need for XSBC-Original-Maintainer being the Debian maintainer18:40
dholbachall current questions answered?18:41
rZrLucidFox: the package i am talking about is a custom built out of debian18:41
RainCTjames_w: argh I'm stupid today :P18:41
secretlondono - there are more in -chat18:41
LucidFoxOoh, Japanese.18:41
dholbach<secretlondo> QUESTION: Is there an easy way of reusing PPA work. I'm planning on using my PPA to experiment with packaging18:41
dholbachsecretlondo: can you explain what you mean by 'reusing'?18:42
rZrdholbach: I'll update the debdiff, contact the author and merge it to debian then18:42
dholbachrZr: great, thanks18:42
james_w<secretlondo> as in getting the same package in, say, intrepid18:43
secretlondogetting it into, say, intrepid. In the last session celso said something about making a connection between PPAs and REVU18:43
rZrdholbach: debian would never accepted a such package as it was anyway ;)18:43
rZrsecretlondo: that's would be nice indeed18:43
rZrsecretlondo: an a branch manager then ..18:44
dholbachsecretlondo: not right now unfortunately - REVU has features that PPA does not have (diff between uploaded versions, etc), that's why we currently stick with REVU for NEW packages18:44
dholbachit's unfortunate and yet another site to register for, but that's all I can say right now18:45
RainCTdholbach: eh.. there's no signup :)18:45
dholbachright, you have to join the team and ask for the keyring to be synced18:45
dholbach<db-keen> QUESTION: well then ignoring .desktops, how should a Debian package handle files that may or may not be installed based on some system aspect?18:45
dholbachdb-keen: can you explain a usecase?18:46
db-keenSometimes a program might use a configuration system like GConf if it is available, but can easily work without it, just won't persist settings between sessions18:47
dholbachpackages usually install files in one place, if they might be needed in another place you can use symlinks for that18:47
dholbachif it's files that probably are not needed at all, you could stick them in a separate package that is only recommended or something18:48
db-keenI just wouldn't be sure where to put a gconf schema without gconf installed18:49
RainCTdb-keen: add gconf to recommends or suggests dependending on how necessary it is (recommends are usualy installed automatically, suggests not)18:49
dholbachdb-keen: just install the gconf schema, it's just a few kb extra, if it's not needed and it's ok to not be used, it will live in /usr/share/gconf/schemas18:49
dholbach<polopolo> QUESTION: If I wanna upload a package to ubuntu/debian, is it needed to call the devolper of the upstream package first? or not? and if yes, what if I cannot find the upstream devolper?18:50
dholbachpolopolo: if you upload a NEW package, you act as its maintainer - that's a role of responsibility18:50
dholbachpolopolo: because you liaise between the upstream developers, the package's users, other developer and so on18:50
dholbachyou're one of the important bonds that make open source happen and that ubuntu is built upon18:51
dholbachso yeah: it's great if you let upstream know and have a good relationship with them18:51
dholbachit's also one of the things that make work in the open source landscape and particularly in Ubuntu so exciting18:51
dholbachyou're in touch with a lot of people18:51
dholbachand if you fix things, you make a lot of people very happy :-)18:51
polopolodholbach: ok, I undersrand it ,well, there are no question, can I ask a personal question?18:51
dholbachpolopolo: go for it18:52
polopolodholbach: why do you use linux and now windows? howlong do you use linux? howlong do you use ubuntu? and why ubuntu and not mandriva pclox opensuse etc?18:52
dholbachI guess you mean "not windows", right? :)18:53
norsettonot what?18:53
polopoloyes, not windows sorry18:53
dholbachI just use windows for my taxes stuff, there's just no work-able program for that in the Linux world (if somebody knows something that works for German taxes, please let me know)18:53
secretlondothere is something as we had a sync request for it as it was on the 2007 version18:54
dholbachI've used Linux for 8 or 9 years now and I was always excited by the people and what they make happen18:54
* secretlondo remembers the bug ;)18:54
snewlandpolopolo: many of us probably have input on that question18:54
dholbachI find it so much more usable and it's great fun to be part of the huge community18:54
dholbachI used Debian before I used Ubuntu, all the people who invited me to join the community then finally made it18:55
dholbacheverybody was friendly (and forgiving when I messed things up)18:55
dholbachespecially seb128, he was really patient with me, when I did not understand shlibdeps in the first place :)18:55
db-keenI'm still unsure of how I should be doing this: If gconf isn't installed, should I still be putting files in that directory?18:56
dholbachdb-keen: yeah18:56
* seb128 hugs dholbach18:56
* dholbach hugs seb128 back18:56
dholbachit's great to work with seb128 :-)18:56
dholbachdo we have any other questions?18:56
* polopolo gonna ask to dholbach: gonna include this personal talk also on the ubuntu wiki or not?18:57
dholbachpolopolo: sure :)18:57
dholbachOK everybody, if that's it, let me give you a few final pointers:18:57
dholbachhttp://wiki.ubuntu.com/MOTU/GettingStarted <- bookmark it and go from there :)18:58
dholbachnext MOTU Q&A Session every Friday 13:00 UTC18:58
dholbachthere's also always #ubuntu-motu and ubuntu-motu@lists.ubuntu.com18:58
dholbachthanks everybody for this great session - you ROCK18:58
AstralJavaGot distracted for a bit, but thanks Daniel again for your time! :)18:58
* polopolo wanna thank dholbach for this session18:59
pranithdholbach, thank you18:59
secretlondothank YOU!18:59
emgentheya people18:59
IulianThanks dholbach!18:59
dholbachnext up we have Stefan sistpoty Potyra - a great guy, MOTU for quite some time and somebody who always manages to make time for you18:59
* sistpoty bows18:59
sistpotythanks for the introduction dholbach :)19:00
jpatrickRainCT: /usr/share/applications/kde/ or kde4?19:00
dholbachHe's going to give you a two hours talk about Library Packaging19:00
RainCTjpatrick: both19:00
dholbachso keep your favourite drink handy and enjoy the show!19:00
* dholbach hugs sistpoty19:00
phoenix24Hello sistpoty !!19:00
* sistpoty hugs dholbach19:00
sistpotyat least I hope, we can do the session in two hours19:00
sistpoty(last time, it was much longer, but I try to be short ;)19:00
sistpotyok, so who's around for library packaging?19:01
sistpotyraise your hands ;)19:01
* secretlondo is lurking as this will be too hard19:01
snewlandsame here, lurking19:01
\shsistpoty: renewing my knowledge so let's do it19:01
dholbach+1 :)19:01
* daishujin hopes he understands some of this session19:01
* polopolo is here to learn!19:01
sistpotyok, first off... this session will be a two part session19:01
sistpotyin the first part, we'll learn the grey theory with some practical examples19:02
sistpoty-> everything you don't know about symbols and always wanted to ask ;)19:02
sistpotyin the second part, we'll take a look at a practical example, together with a few more hints19:02
sistpotyfor the first part, I guess all you need is readelf, gdb, nm, gcc, objdump (I guess build-essential is enough to have installed for these)19:03
sistpotyin the first part, we'll take a close look at shared objects...19:03
sistpotyshared objects can be used in two ways:19:03
sistpoty1) as a plugin mechanism (to be loaded with dlopen)19:03
sistpotyand 2) as shared libraries19:04
sistpotywe'll focus solely on 2) here19:04
sistpotyan ELF shared object (.so) is a collection of symbols together with some meta-information19:04
sistpotya symbol denotes any named entity in c (or c++), e.g. a function call or a (global) variable19:05
sistpotyone of the meta-information about a symbol in a shared object is the section it resides in19:05
sistpotye.g. if it has a default value, can be executed... we'll soon look at this19:05
sistpotyactually now... so everyone get http://www.potyra.de/library_packaging/example.c19:06
sistpotyoh, if there are any questions, don't hesitate to ask :)19:06
sistpotyeveryone got that file?19:06
sistpotythen let's compile it:19:07
sistpotygcc -c example.c -o example.o19:07
sistpotynow let's take a look at the (not yet shared) object file...19:07
sistpotynm example.o19:07
sistpotywhat you see there, are the symbols in the object file19:08
sistpotythe rightmost thing is the name19:08
sistpotythe letter before is the type of the symbol19:08
sistpotyupper case letters denote, that the symbol is visible outside of the object file as well19:09
sistpotywhile a lower case letter means that it is local to the symbol19:09
sistpotyhence, e.g. extern_global could be used by a different c-file while static_global could be only used from the c-file we just compiled19:09
sistpotyshort overview of the types, and what they mean:19:10
sistpotyt -> text section (may be mapped readonly), executable19:10
sistpotyd -> initialized data (statics, initialized globals)19:10
sistpotyc -> uninitialized data (uninitialized globals)19:10
sistpotyr -> read only data (const variables), not necessarily read only though.19:10
sistpotyu -> undefined. We use a symbol from elsewhere, which will get resolved later by the loader19:11
sistpotyyou can find these in the manpage of nm for reference19:11
sistpotynow, let's compare this with the c-code19:11
sistpotyfor example the symbol "extern_global" is defined as "int extern_global;"19:12
sistpotyit's not initialized with a value, hence the type nm spits out is "c"19:12
sistpotyand since it can be used from other c-files, it's an upper case letter19:13
sistpotyany questions so far?19:13
snewlandsurprisingly clear so far19:13
sistpotyok, let's build a shared object from example.c19:13
AstralJavaJust a clarification that you probably meant "local to the module", instead of *symbol.19:14
AstralJavaErr... that was a question, sorry. :)19:14
sistpoty*looking* (I pasted some stuff *g*)19:14
AstralJavaGotcha. :)19:14
sistpotyAstralJava: can you give me the line? ;)19:15
snewlandsistpoty: while a lower case letter means that it is local to the symbol19:15
AstralJavaYes, that.19:15
sistpotyah... right... of course local to the object file (or c-file that gcc translate to an object file)19:16
sistpoty<phoenix24> sistpoty: QUESTION : Why is there no symbol information for "int local_var" (local_function)?19:16
sistpotygood question, phoenix24: anyone got the answer for him?19:16
phoenix24Coz its a local variable ?19:16
snewlandthose would be taken from the local system?19:17
sistpotyphoenix24: exactly19:17
phoenix24but, static_local_var is static.19:17
sistpotylocal variables inside functions reside on the stack19:17
sistpotythese will get put on the stack, once the function is called, and will get removed when the function returns19:17
sistpotyhence these are not part of the object file19:18
sistpotyhowever static local variables will be in the data section... because they keep their value in the next funciton call19:18
sistpoty-> part of the object file19:18
sistpotyok, now let's build a shared lib, shall we?19:18
sistpotygcc -Wl,-z,defs -Wl,-soname,libexample.so.1 -fPIC -shared example.c -o libexample.so19:19
sistpotythe -Wl,... are commands that gcc passes to the linker19:19
phoenix24please explain a bit on them.19:20
sistpotyok, the first one basically tells the linker, that it needs an entry for every symbol (i.e. no unresolved symbols)19:20
sistpotynote, that an "U" entry is ok here as well19:20
sistpotybecause that would mean that it is linked against an shared object, which contains the symbol (the implicit libc, which gcc will always add here)19:21
sistpotyI'll come to the soname part later in the session... this option will specify that libexample.so should have the soname libexample.so.119:21
slangaseksistpoty: might I interject a clarification regarding -Wl,-z,defs?19:22
sistpotyslangasek: sure19:22
slangasekwhat that option really means is that, at build time, ld must be able to find a match for each undefined symbols in one of the shared objects that you're linking against19:22
slangaseki.e, it controls *how* " U " symbols are handled19:23
sistpotythanks for the clarification slangasek!19:23
dooglusspecifically, does -Wl,z,defs mean that ld will be passed the "-z defs" flag?19:23
sistpotydooglus: exactly19:23
sistpoty-Wl,something means to pass something as an option to ld19:24
sistpotythe -fPIC will tell gcc to produce position independent code... I'll just say that it is needed to shared objects and not go into details here ;)19:24
sistpotyfinally, -shared tells gcc to produce a shared object19:25
sistpotynow, to match the shared objects, you have on the system, let's strip it19:25
sistpotystrip libexample.so19:25
sistpotyerm... what I wrote... (just messed things up locally *g*)19:26
sistpotylet's take a look again with nm19:26
sistpotynm libexample.so19:27
phoenix24No symbols : nm: libexample.so: no symbols19:27
sistpotylet's try to get it right... as it's a shared object, we're interested in the dynamic symbols19:27
sistpotynm -D libexample.so19:28
dooglussistpoty: can I ask a question?19:29
sistpotydooglus: sure19:29
* siretart notices that the output of eu-nm (from elfutils) is much clearer that binutil's nm19:29
dooglussistpoty: this "so" is a shared object - has any linking been done yet?  when we were talking about options being passed to ld, has that happened yet?  the term 'shared object' makes me think it hasn't been linked yet (like a .o hasn't)19:30
sistpotydooglus: good one19:30
sistpotyfor a shared object, linking has been done19:30
slangasekyes, it's "partially" linked, with final linking happening at runtime via ld.so19:31
dooglusI thought so - I 'damaged' one of the 'fprintf's in the file, and it refused to compile any more - I was surprised.19:31
siretartthere isn't much difference between an ELF shared object and an executable. the executable happens to have a function called main(), though :)19:32
dooglusok, thanks19:32
snewlandso does the ELF19:32
snewlandsiretart: have a main I mean19:33
sistpotysnewland: yes, because the main is still in there (s.th. libraries usually don't contain)19:33
snewlandk thanks19:33
slangasekdooglus: you might like to compare the results with and without the -Wl,-z,defs19:33
slangasek(in the case of damaging the fprintf)19:33
sistpotythere are also other tools to look at the shared object's information19:34
sistpotylet's try readelf -s libexample.so19:34
doogluswith the -Wl,z,defs I see "example.c:(.text+0x56): undefined reference to `myfprintf'" - without it I see no error at all19:35
sistpotyexactly, because in the first call, the linker definitely wants to resolve myfprintf, in the second one it won't19:35
snewlanddooglus: I thought the command was -Wl,-z,defs19:36
dooglussnewland: I typed it out badly by hand there.19:36
sistpotyok, let's take a look at the output of the readelf command19:36
sistpotyanything interesting that you note?19:36
snewlandsize 019:37
sistpotyI'm not too sure what size 0 means exactly (probably, that it doesn't take any storage space in the shared object itself)19:38
sistpotybut let's look at what eddyMul has found19:38
sistpotythese are versioned symbols19:38
sistpotyi.e. the name of the symbol contains a version as well19:38
sistpotyoh, I should explain s.th. first19:39
sistpotyin an shared object (and a normal object as well), there can be only one symbol with a specific name19:39
sistpoty(apart from dirty linker commands getting used)19:40
sistpotythat means, you couldn't have two symbols with the name stderr19:40
sistpotyhowever, in the c-library uses versioned symbols, hence the version is part of the symbol19:40
dooglusGLIBC is written all in capitals; I've never seen it in capitals before19:41
sistpotyso stderr could be defined for example by an older version as well19:41
sistpotyhowever this symbol from our shared object would then always get resolved to the one of 2.019:42
sistpoty(or mine against 2.2.5)19:42
sistpotyprinting out symbol versions is s.th. which afaik nm doesn't do19:42
sistpotyhence, when looking at libraries, nm should be avoided19:43
sistpotyyou can also use objdump to look at a shared object19:43
sistpotyit can tell other important information as well19:43
sistpotylet's try this19:43
sistpotyobjdump -x libexample.so19:44
sistpotythis will produce lot's of output19:44
sistpotyobjdump -p libexample.so19:44
sistpotywill give much less output with the most interesting information19:44
sistpotyso let's see what objdump -p libexample.so will tell us19:44
sistpotythe most interesting bits are19:45
sistpotythe SONAME19:45
sistpotyand the NEEDED enty (there can and usually is more than one NEEDED entry)19:45
sistpotythe SONAME entry denotes some kind of "version" of the shared object, denoting a stable abi19:46
sistpotythat means basically that you can always use a newer version of a library with the same SONAME as an older version19:46
sistpotyand your program using it will still work19:46
sistpotyanyone recalling, where the SONAME entry came from?19:47
stdingcc -Wl,-soname...19:47
sistpotystdin: perfect19:47
AstralJavaDamn, beat me to it!19:47
sistpotyhowever that means, that someone set it manually19:48
sistpotyor in other words, if the person who set it did s.th. wrong, you might end up with a changed ABI19:48
sistpotylet's take a look what problems can arise by an example19:49
sistpotyfirst, let's get http://www.potyra.de/library_packaging/libmyhello-1.0.1.tar.gz19:49
sistpotyextract it and compile it19:49
sistpotytar -xvzf libmyhello-1.0.1.tar.gz19:49
sistpotyif you've got it, please install it (with root privs):19:50
sistpotysudo make install19:50
sistpotyno worries, it will only place stuff under /usr/local, and comes with an uninstall rule as well19:50
AstralJavaWe're brave people. :)19:50
sistpotyof course you can look at the makefile, if you don't trust me :P19:51
sistpotynow run ldconfig (with root privs as well), so that ld will be notified to look out for s.th. new19:51
sistpotyof course a library alone is no fun yet, so you want a program using it as well: http://www.potyra.de/library_packaging/hello_prog-1.0.tar.gz19:52
sistpotyyou'll only need to compile this one19:52
sistpotylet's try it: ./hello_prog 1019:53
sistpotyamazing software, right? *g*19:53
sistpotyeveryone got it so far?19:53
sistpotyok, so now let's check out the new library version19:54
sistpotyyou should know the procedure... extract, make, sudo make install19:55
sistpotyif you've got it, please try to run the application again (not to rebuild it, just run the one you've got)19:56
AstralJavaEeewwww.... symbol lookup error!19:57
sistpotyok, let's try to find out what happened...19:57
sistpotylook at the symbols, that are undefined in hello_prog19:58
sistpotyreadelf -s hello_prog19:58
sistpotyin readelf, these are listed as "UND" btw.19:58
sistpotyyou'll see, that hello_prog will want a symbol called print_hello19:59
sistpotyif you look at the old shared object, there indeed is such a symbol19:59
sistpoty7: 00000000000005a0    32 FUNC    GLOBAL DEFAULT   11 print_hello19:59
sistpotythe new library however doesn't come with one20:00
sistpotyhence, the ABI is obviously not stable20:01
sistpotythe term ABI refers to the abstract binary interface20:01
sistpotyit means, the symbols (by name) defined in the shared object and their type20:01
sistpotyfor functions, it also means how the symbols can be used (i.e. how many parameters must the function have, and of which type must these be)20:02
sistpotyas you've seen, once you remove a symbol, the ABI is not stable (because any program might have used it)20:03
sistpotythe type of a symbol shouldn't change as well20:03
sistpotythis information can be easily found out with the tools you know so far20:04
sistpotyhowever to find out the arguments of a function call, symbol names and type alone are not sufficient20:04
AstralJavaWas just about to ask. :)20:04
sistpotyone possibility is to use the debug information (which however is no longer present in binary packages)20:05
sistpotyfor debug information, gdb is our tool of choice20:05
sistpotylet's try (pick one of the two library versions you like)20:05
sistpotygdb libmyhello.so20:05
sistpotyinside gdb, you can type20:06
sistpotyinfo functions20:06
sistpotyyou can also look at the type (as in the programming language's type, not to confuse with the symbol type) with20:07
sistpotyinfo variables#20:07
sistpotyhowever this will only work, if debugging symbols are still present20:07
sistpotyyou can compare this, after running strip on the shared object20:07
sistpotyok, how about makeing a 5 minute break now, and then sum up part 1 and start with part 2?20:09
AstralJavaWorks for me.20:10
sistpotyok, then let's continue at 20.15 UTC (in the hope my local clock is correct)20:11
sistpotyeveryone back?20:16
sistpotyok, let's sum up part 120:17
sistpotyso far, we've learned that we can lookup the symbols via nm, readelf and objdump20:17
sistpotya stable ABI means, that no symbols are removed and the symbols type is not changed... also that the corresponding c-convention (e.g. number of arguments of a function, type of arguments of a function, type of a variable) is not changed20:18
sistpotyin contrast (what I didn't mention yet), is the API20:18
sistpotya stable API denotes, that a program will still be able to compile with a new library20:19
sistpotyyou can have a stable API but have breakages in the ABI of course20:19
sistpotye.g. if things get moved from a c-file to inlined version in the header file20:19
elisee(I just managed to catch up, very instructive so far :))20:20
sistpotyif the SONAME stays the same, it means that the library author *believes* that the ABI is stable20:20
=== phoenix24_ is now known as phoenix24
sistpotybut it's no guarantuee, since it's set by a human ;)20:20
sistpotyoh, one thing I missed: the NEEDED entry20:21
sistpotyor entries20:21
sistpotythe NEEDED entry in a shared object means, that a shared object with such a SONAME is needed20:22
sistpoty(likewise in a elf-binary aka program)20:22
sistpotyit's needed, because unresolved symbols, which the loader will resolve are defined there20:22
sistpotylet's take a short look at a real world example20:22
sistpotyobjdump -p /usr/lib/libgnome-2.so.020:23
sistpoty(in the hope, that everyone has this shared object)20:23
sistpotythese NEEDED entries point to shared objects (with the same SONAME), that contain symbols that libgnome-2.so.0 uses, but doesn't define20:24
sistpotyI guess you all know ldd20:24
sistpotylet's compare20:24
sistpotyldd /usr/lib/libgnome-2.so.020:24
sistpotycan anyone spot the difference?20:25
phoenix24sistpoty: please brief about ldd.20:26
sistpotyphoenix24: ok20:27
eliseeldd seems to return the whole dependency tree with path to the SO file20:27
sistpotyldd will basically do the same thing, that the loader will do20:28
sistpotyi.e. it will resolve the NEEDED entries to shared objects20:28
sistpotyand as elisee wrote, will do the same for the shared objects found as dependencies as well20:29
slangasekin fact, ldd uses the loader to do what it does ;)20:29
sistpotyit will finally spit out the *pathes* to the shared object it found20:29
eliseelinker / load = the same program?20:29
eliseewith different options20:30
sistpotyelisee: nope... the linker is used at *compile* time... to find out the NEEDED entries20:30
slangasekby "loader" here we're talking about ld.so, which is the runtime linker, yes20:30
sistpotyelisee: the loader will take the NEEDED entries as input and find the object file at *run time*20:31
eliseesistpoty, I get that20:31
eliseeand ld.so is automatically loaded by the OS? because it's a shared object too, right?20:31
phoenix24got it.20:31
sistpotyelisee: that's what I assume, but I guess slangasek could tell in more detail ;)20:32
slangasekelisee: the way this works under Linux is that when you exec() a program, the kernel looks at the head of the file, sees that it's an ELF file, and passes control to ld.so to work out what to do with it20:33
eliseeat least it looks like, according to the ld.so man page20:33
eliseeok thanks a lot, all of this is so instructive20:33
sistpotyfinally, a very important note, which we'll dig into in part 2: shared objects with a different SONAME can be installed side-by-side20:35
sistpotyany further questions to part 1 so far?20:35
sistpotyok, then let's go for part 220:36
sistpotywhile my plan was to actually have everyone package libmyhello, I guess we'll never do that in time20:36
sistpotyluckily, I've got s.th. prepared, let me look at where to get it :)20:36
sistpotybzr branch http://bazaar.launchpad.net/~sistpoty/+junk/library-packaging-session20:37
sistpoty(in the hope, that everyone has bzr installed)20:37
eliseei guess anyway it can be quickly installed by anyone through Ubuntu repositories20:38
sistpotyeveryone got it?20:38
eliseeok for me20:39
sistpotyok, since this contains the upstream code as well, we'll first need to make a tarball of it20:39
sistpotycd libmyhello/0.1 && make dist20:39
* sistpoty tries to remember the funny build system used for the package20:40
eliseeI don't know much about packaging, and I wonder : does that kind of Makefile gets written by a human-being?20:41
eliseeor do tools do it for us?20:41
sistpotyelisee: is this a question whether I am human? :P20:41
sistpoty(I wrote everything there by hand)=20:41
LaserJockelisee: he's not20:41
eliseesistpoty, aren't you? ;)20:41
sistpotyheh, no comment *g*20:42
LaserJockhe's an advanced cyborg cron job20:42
AstralJavaSo AI devel is much further than They(tm) let us believe, huh?20:42
sistpotyok, if you've got the make dist, you'll need another dir20:44
sistpotyin libmyhello, make the directory work20:44
sistpotyif you've got that, go to the subdir packaging, and just call make (this will place some symlinks into ../work)20:45
sistpotyoh, hard links, it seems20:45
sistpotyit will also extract the packaging I prepared20:46
sistpotyeveryone got it so far?20:46
eliseegot it20:47
sistpotyok, first off, before looking at anything, a *very* good resource is the debian library packaging guide... keep that under your pillow, when working on libs ;)20:48
phoenix24subdir named "packaging ?",20:48
eliseephoenix24, library-packaging-session/libmyhello/packaging20:49
sistpotyphoenix24: libmyhello/packaging20:49
sistpotyif everyone got it, let's start with the control file library-packaging-session/libmyhello/work/libmyhello-1.0.1/debian/control20:51
sistpotythe work directory should contain the extracted package, hence libmyhello-1.0.1 in there is the directory which I'll refer from now on20:52
sistpotyin debian/control, there are two (binary) packages for this library defined20:53
sistpotythat's pretty much standard (except some libraries ship an application as well, or have big documentation)20:53
sistpotythe first one, will contain the shared object20:53
sistpotythe libmyhello1 package name is special:20:54
sistpotyit is related to the SONAME that is defined in the shared object it contains20:54
sistpotysince shared objects with a different SONAME can be installed side-by-side, the packaging must respect this20:54
sistpotyhence the relation of the package name to the SONAME, but it also has other consequences20:55
sistpotyin libmyhello1, there mustn't be a file which would have the same name (in the same directory) as a file from a shared object with a different SONAME20:56
sistpotyhence putting e.g. a manpage, or an application in there won't work20:56
sistpotythis package is the thing, which will (on the users) system usually get installed, because another package (usually an application using this shared object) draws in20:57
sistpotyothers than that, there is no much use to install it directly20:57
sistpotyin contrast, the -dev package contains everything that is needed to compile programs against the shared object20:58
sistpotythis means the header files which programs must include, but also in our case the libmyhello1.so symlink20:59
sistpotyerm... sorry libmyhello.so symlink in /usr/lib20:59
sistpotynow, what's that symlink good for?20:59
eliseethere's no version in it because we link against a share object and not an abi version, right?21:00
sistpotyelisee: right21:00
sistpotyusually, we'll always want to call s.th. like21:00
sistpotygcc -lsomelib21:00
sistpotythis will make gcc to search for a shared object call libsomelib.so21:01
sistpotyin the library path21:01
sistpoty(it prepends lib and appends .so, iirc .a is also possible if no .so is found, but I'm not 100% sure on this)=21:01
sistpotyhence it makes sense to include the .so in the -dev package, so that programs will find the (right) shared object when linking21:02
sistpotyoh, for the .a: these are static libraries21:02
sistpotysince these will be part of the resulting program, and won't get loaded at run time, there is no such thing as a SONAME for these21:03
sistpotyIt's simply not needed21:03
eliseeso one can't name a .so file without lib prepend to it? or will it first try without the lib?21:03
sistpotyhence these are also part of the -dev package (if there)21:03
eliseewithout the 'lib' prefix I mean21:03
sistpotyelisee: I'm not 100% sure, but what I know: yes21:04
sistpoty(and looking at my /usr/lib/ directory seems to underline that)21:04
sistpotyelisee: of course plugins (which are also shared objects, opened via dlopen) can use whatever names they wish21:05
sistpotybut we didn't want to look at these here ;)21:05
sistpotyback to the control file21:06
sistpotythe -dev package must always add a (hard) dependency on the shared object21:06
sistpotyon the package containing the shared object21:06
sistpotybecause you can't link anything with just a symlink ;)21:06
sistpotythat's the depends line of libmyhello-dev21:07
sistpotyothers than that (and where the example is not too exact), the -dev package must also make sure, that every library, that's needed for compiling is drawn in21:07
sistpotye.g. if I'd use stuff from libasound2 (because it's e.g. included from libmyhello headers) then there must be a dependency on libasound2-dev21:08
sistpotyoh, sometimes, it makes sense, to also name the -dev package correlating to the soname, in case you want to have more than one version of the library in the archive21:09
sistpotye.g. if many apps won't compile with the new version21:09
sistpotyok, so why do we need to make sure, that the library package (libmyhello1) is installable together with a package of a different SONAME (e.g. libmyhello2), even if we plan to have only one version in the archive?21:12
eliseebecause the user might need two versions of the library21:13
h3sp4wn_upgrades maybe ? (either way aptitude wouldn't have that issue)21:13
eliseebecause he has two programs needing these two different versions21:13
sistpotyexactly elisee and h3sp4wn_21:14
sistpotyjust consider, that the user has a package called hello_prog installed. It was built and got the dependency on libmyhello121:14
sistpotynow libmyhello2 is available21:14
sistpotythe library however won't get upgraded (unless a different package needs it)21:15
sistpotyand libmyhello1 can only be uninstalled, in case hello_prog was removed21:15
sistpotyso in the archive, we'd rebuild hello_prog. That way it will pick up libmyhello2 as a dependency21:16
sistpotythen, and only then, hello_prog of the user can get upgraded (and this would draw in libmyhello2 then). However libmyhello1 wouldn't automatically go away21:17
sistpotygot it?21:17
AstralJavaFigured as much. So how do we get rid of deprecated libs when no app needs them anymore?21:17
sistpotyAstralJava: since these (should) always get drawn in by s.th. and not installed by hand, "apt-get autoremove" will do that trick21:18
eliseethe package managers usually provide a way to remove no-longer-needed automatically installed dependencies21:18
eliseeyeah, apt-get autoremove, that's what I mean21:18
AstralJavaOkay thanks!21:19
sistpotyok, I guess debian/rules is not too exciting. maybe apart from one call21:19
sistpotythis one will create a shlibs file21:19
sistpotyan shlibs file contains the info, which library package contains which shared object (together with the version of the library package that's needed for it)21:20
eliseeit's built with the info we've just put in control?21:21
sistpotythis is a special part of a debian package... you can find all shlibs files of installed packages in /var/lib/dpkg/info21:21
sistpotyelisee: yes. It also can contain the info that a specific version is required (I'll come to that in a minute)21:22
sistpotyspecific version of the package even21:22
eliseesorry, yet another question: can't figure out what "dh" means in dh_makeshlibs21:23
sistpotyelisee: that means it's a debhelper command21:23
sistpotydebhelper contains commands to make common needed tasks of packaging easier21:23
sistpotye.g. dh_shlipdebs is basically a wrapper to dpkg-shlipdeps...21:24
sistpotywhich will take care that anything with ${shlibs:Depends} in debian/control will get replaced by a dependency to the library package21:25
sistpotynow how does it do that?21:25
sistpotyit looks up the NEEDED entries (with tools, we've learned in part 1) of every elf (both binaries and shared objects) and checks via the shlibs files on the system, which package it needs21:26
sistpotynow let's reconsider part 1... a stable abi (and hence a stable SONAME) means no symbols get removed and their type and meaning don't change21:27
sistpotyhowever upstream could add new features (e.g. new functions) which would result in new symbols21:27
sistpotyand the ABI would still stay the same21:28
sistpotyi.e. programs that use the old shared object can use the new shared object21:28
sistpotybut what, if a program uses exactly one of the new symbols?21:28
sistpotyit could then not run with an old shared object not containing the symbol yet, which however is not different in regards to the soname21:29
sistpotyhence on the mere basis of an SONAME there doesn't seem to be a solution21:29
sistpotyluckily the debian packaging system can help here21:30
sistpotyas I stated earlier, the shilbs file may also contain a version21:30
sistpotyyou can specify the version that goes in there with the -V parameter of dh_makeshlibs21:30
sistpotyso, in case there are new symbols in a package, you'll always want to use that:21:31
sistpotyany program, that uses the newer functionality, cannot compile against the old version (we've seen what happens with -Wl,-z,defs)21:32
sistpotyso it will need to compile the newer version of the -dev package... and the shlibs mechanism contains then a shlibs file which will state:21:32
sistpotyyou'll need a this version or a later one of lib...21:32
sistpotywas that too fast?21:33
eliseeso there's a numbering scheme inside the shlibs different from the SONAME version?21:33
slangasekSONAME documents each backwards-incompatible ABI change21:34
slangasekshlibs gives you the other piece, to document backwards-compatible ABI changes21:34
eliseeI don't really know what these shlibs are in fact, but maybe it's not the purpose to explain this now21:34
sistpotyoh, then I *was* too fast21:35
sistpotylet's try again...21:35
sistpotyif you've got a shared library with a given soname, the shlibs file will basically say in what debian package this can be found21:35
sistpotybut it will also say what version of the debian package you need (at least)21:36
sistpotyin case a program gets built, which contains NEEDED entries (i.e. uses symbols from some shared object)21:37
sistpotythe shlibs file will be used to lookup in what package the shared object is21:37
eliseeok, that's much clearer this way for me21:37
sistpotythis is then added as a dependency to the programs package (actually ${shilbs:Depends} in debian/control will get replaced by the found entries)21:38
sistpotyok, any other questions?21:38
AstralJavaProbably loads, but they might pop up in practice. Can't think of any right now.21:39
sistpotyok, then I guess one final hint (as I've once again used more time than available):21:39
sistpotyas we learned today, the most difficult bit is *upgrading* a library package21:40
sistpotythere, you must ensure, that the ABI doesn't break21:40
sistpotyof course you should also keep a look what packages build against this package (not that you'll upgrade it and every using package won't build any longer)21:41
sistpotybut the tricky part is to ensure ABI stability21:41
sistpotyI hope, you learned some tools with which you can check that today21:41
AstralJavaDefinitely! What a fantastic session it was.21:42
eliseethanks a lot :)21:42
sistpotyothers than that, there exists a package which can be a help, but I forgot it's name... slangasek: what creates the manifest again?21:42
=== ianc is now known as IanC
sistpotyok, sorry I really have completely forgotten the name of the package...21:45
sistpotyhowever thanks for coming, and I hope once you'll maintain a library package, you'll be prepared ;)21:46
AstralJavaCan you post it on ubuntu-motu@ or something later on?21:46
sistpotyAstralJava: you mean which package I mean?21:46
AstralJavaAgain, thank you very much for this, hugely appreciated! :)21:46
AstralJavasistpoty: That's right, if/when you recall or somebody else verifies it.21:47
sistpotyit must be in the old logs... but I'll post it ;)21:47
slangaseksistpoty: manifests are created by dpkg-dev itself now, no?  dpkg-gensymbols?21:47
slangasekor icheck, for API manifests21:48
sistpotyslangasek: no, that package which parses the c-code and produces a .manifest file21:48
AstralJavaThanks, Stefan and Steve.21:49
sistpoty(strange enough I was searching for iwcheck the whole time... close but no hit)21:49
sistpotythanks for listening ;)21:49
sistpotynow, I'll have a cool drink :)21:49
AstralJavaWell deserved it too. :)21:50
eliseeleaving, have a good night (or maybe day) everyone21:53
* slangasek waves21:53
AstralJavaMe too, was a fine day today. Hope to see similar soon again. :) Bye all.21:54
=== emgent is now known as carlo__
=== carlo__ is now known as emgent

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!