=== baggio is now known as DannyBoy === DannyBoy is now known as Daniel [01:48] Any MOTU available for chat? [01:58] I'm still here [01:58] Any MOTU available for chat? [02:07] Daniel: have you looked in #ubuntu-motu ? === dholbach changed the topic of #ubuntu-classroom to: Please join #ubuntu for support | This channel used for scheduled classes and invitational tutoring | Ubuntu Developer Week info: Information and Logs: https://wiki.ubuntu.com/Ubuntu === dholbach changed the topic of #ubuntu-classroom to: Please join #ubuntu for support | This channel used for scheduled classes and invitational tutoring | Ubuntu Developer Week info: Information and Logs: https://wiki.ubuntu.com/UbuntuDeveloperWeek | Ubuntu classroom transcripts: https://wiki.ubuntu.com/ClassroomTranscripts | How to ask questions: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Rules === asac_ is now known as asac === Ketzal is now known as Ketzal_out === pochu_ is now known as pochu [11:46] Hi all! === Ketzal_out is now known as Ketzal [14:13] * popey hugs dholbach [14:14] hey popey [14:14] * dholbach hugs popey back :) === dholbach_ is now known as dholbach [14:41] damn i want that it is 16:00 :P [14:42] so everybody's excited already? :-) [14:45] dholbach, the excitement seems to be not there currently ;-) [14:45] tuxmaniac: patience - wait another 75 minutes ;-)) [14:46] * tuxmaniac goes for dinner in the meantime [14:47] boink. UTC. [15:34] hey jono - excited about UDW? :) [15:37] dholbach: wooo! :) [15:38] :-) [15:39] dholbach : I'm mostly interested in the Packaging 101 session, do you mind if I lurk in the earlier classes? [15:39] * jetsaredim was thinking the same [15:40] flicck: absolutely not - it's definitely worthwhile lurking in the other sessions [15:40] thank you for the welcome, will do [15:45] is packaging 101 coming up? [15:46] danbhfive: it's 15:46 UTC - the schedule is up at https://wiki.ubuntu.com/UbuntuDeveloperWeek [15:46] kk, thanks dholbach [15:46] date -u is your friend :-) [15:47] hello people [15:50] hi, patching packages is here? [15:51] * pitti waves [15:51] fftb: yes, in 9 minutes [15:51] great thx [15:51] WELCOME EVERYBODY! [15:51] This is the first ever Ubuntu Developer Week and I hope you're all very excited [15:51] because I am :-) [15:51] :) [15:51] The schedule is up at https://wiki.ubuntu.com/UbuntuDeveloperWeek [15:51] and the rules are up athttps://wiki.ubuntu.com/UbuntuDeveloperWeek/Rules [15:52] are there going to be transcripts of these sessions for people who can't make it? [15:52] basically: please keep all chatter out of this channel, ask questions in #ubuntu-classroom-chat instead [15:52] and make sure you prefix them with QUESTION: ... [15:52] so they're easier to spot [15:52] jetsaredim: yes, there are links on the schedule page already and they will be filled up with the logs afterwards [15:53] are there any other questions before we start? [15:53] dholbach: ok - sorry must've missed that [15:53] also, most of the topics should already have documentation in the wiki [15:53] jetsaredim: no problem [15:54] the first speaker is Martin Pitt, also known as pitti [15:54] * pitti bows [15:54] he's the author of jockey (formerly knows as restricted-manager), apport and a bunch of other tools, in his days as our security king he had to touch myriads of packages, so he knows a lot about patching packages [15:55] we still have 5 minutes until the session starts so you all have time to grab a comfy chair and your favourite drink before we start [15:55] so, who is actually here for the patching packages hands-on training session? [15:55] be gentle with pitti, we still need him :) [15:56] heh [15:56] * jetsaredim is here to soak up as much as possible [15:56] jetsaredim: welcome! [15:56] * TuxCrafter i am here for the packaging training and want to now when the end of the session is here an when there are pauses? [15:56] hands on training session? [15:56] sessions start on the hour, for a little less than an hour [15:57] amachu: yes; a theoretical speech about patching wouldn't be very useful, I guess [15:57] then you can as well just RTFM :) [15:57] pitti: should help [15:58] * TuxCrafter is back in 10 min [15:58] Wow... lot's of people here. Congrats dholbach! [15:58] don't forget people - you can start your MOTU adventure at https://wiki.ubuntu.com/MOTU/GettingStarted [15:58] agoliveira: yeah, everybody's excited :) [15:58] good point, Mr. Bacon :) [15:59] * dholbach hugs jono [15:59] jono: I'm still waiting for the movie :) [15:59] agoliveira: heh [15:59] * pitti hugs dholbach for organizing this event [15:59] * jono hugs dholbach :) [15:59] * dholbach hugs jono and pitti :) [15:59] * pitti rings the classroom bell [15:59] enjoy the show! [15:59] let's start [16:00] * agoliveira gves a apple to pitti [16:00] an apple [16:00] Welcome to the hands-on training session about how to patch Ubuntu source packages! [16:00] This assumes that you already know what a patch is and how to handle .patch files in general (i. e. for upstream authors). [16:00] and want to learn how to put them into packages properly, to get them into Ubuntu [16:00] so, can you please quickly raise your hands if you are participating? [16:00] * agoliveira here [16:01] raise [16:01] just to see how big the audience is [16:01] * jetsaredim here [16:01] raise [16:01] * andy101 raises hand [16:01] yep [16:01] * bfallik raises his [16:01] \o/ [16:01] raises hand [16:01] pong [16:01] great [16:01] here [16:01] o/ [16:01] yo [16:01] wow [16:01] here [16:01] * Picklesworth raises his hand :) [16:01] yeü [16:01] yes [16:01] * pitti is impressed [16:01] · [16:01] / raises [16:01] here [16:01] hi [16:01] if 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:01] here [16:01] * tseliot raises his hand [16:01] * TrXuk here [16:01] hand [16:01] * emgent here [16:02] OTOH, if you have deeper technical questsions, please ask in #-chat [16:02] Also, 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:02] * awalton__ quacks. [16:02] Let's begin with a little bit of history: [16:02] == Why use separate patches == [16:02] yes, please take your questions to #ubuntu-classroom-chat and prefix them with QUESTION: [16:02] == Why use separate patches == [16:02] In 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:03] With 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:03] The ideal state is an unmodified tarball from upstream, plus clean and separate patches, plus the packaging bits in debian/. That means that lsdiff -z .diff.gz only contains debian/. [16:03] The 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:04] Thus several standard patch systems were created which are easy to deploy and provide tools for patch juggling and editing. [16:04] --- [16:04] What 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:05] For 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. I 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:05] is everyone fine with this approach? [16:05] any questsions so far? === Square is now known as Squares [16:06] If you want to try the stuff yourself, please do the following commands (on gutsy) as preparation: [16:06] sudo apt-get install dpatch cdbs quilt patchutils devscripts [16:06] ^ common build tools [16:06] apt-get source cron udev pmount ed xterm [16:06] ^ the example source packages I'll be explaining [16:06] wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch [16:06] (I'll talk about this later) [16:06] chmod 755 dsrc-new-patch [16:06] (make my script executable) [16:06] I deliberately picked the smallest packages I could find [16:07] * pitti waits a bit for people to do the preparations; any questions so far? [16:07] nope [16:07] too fast [16:08] I posted question on ubuntu-classroom-chat on previous Q. [16:08] ^ common build tools [16:08] ubuntu_learner: I answered it there, did you see it? [16:09] Kaasethu: are those that pitti asked to install [16:09] ah, the ^ means "explanation for the previous line" [16:09] like an upwards arrow (sorry if that was unclear) [16:09] thanks - [16:09] now got it (I think) [16:10] so, I think most people should have downloaded the lot now? [16:10] == cron: inline patches == [16:10] No patch system at all, nothing much to say about this. You directly edit the files in the source tree. This 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:10] if you do 'lsdiff -z .diff.gz' and you see changes which are not in debian/, then you probably have such a package [16:11] i. e. that's a good counterexample for what we want to achieve with patch systems [16:11] all changes are lumped together, not really documented, you don't see which are Debian specific, which are upstream bug fixes, new features, etc. [16:11] (some KDE packages have autoconf stuff directly in the diff.gz, but that is ok) [16:11] so, I think I do not need to say anything else about cron, unless someone has a question [16:12] just look at the diff.gz to see how packaging and code changes are wildly mixed [16:13] == udev: separate patches, but no standard patch system == [16:14] if you look at udev's diff.gz, you see that it only has debian/, and split-out patches in debian/patches [16:14] one per logical change [16:14] However, udev is the most complicated case of a "patch system", since you have to do all the hard work for creating/managing patches manually. [16:14] In 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:15] The 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:15] The 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:15] So 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:16] * agoliveira rekons udev is evil [16:16] The general approach which all patch systems follow, and which you can always do yourself, is: [16:16] agoliveira: for various reasons :-P [16:16] 1. copy the clean source tree to a temporary directory /tmp/old [16:16] pitti: Bingo! [16:16] 2. 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:17] 3. copy the whole source tree again: cp -a /tmp/old /tmp/new [16:17] 4. go into /tmp/new, do your modifications [16:17] 5. go back into /tmp and generate the patch with [16:17] diff -Nurp old new > mypatchname.patch [16:17] 6. move the newly generated patch to /debian/patches/mypatchname.patch [16:18] don't worry, I'll do an example [16:18] that's just the general recipe for printing out and hang over your bed/PC/whereever you need it :) [16:18] in general we want the following diff options: [16:18] -N -> include new files [16:18] (which is quite common) [16:18] -u -> unified patches (context diffs are ugly) [16:19] -r -> recursive [16:19] -p -> bonus, you can see the name of the affected function in the patch [16:19] does anyone have a question about the principle method? [16:20] ok, some hands-on example [16:20] open a shell, ready your fingers :) [16:20] udev example 1, let's create a new patch 92_penguins.patch: [16:20] cd /whereever/you/unpacked/the/source/udev-* # -113 on gutsy, -117 on hardy [16:21] -> now we are in our original source tree where we want to add a new patch [16:21] cp -a . /tmp/old [16:21] -> create a copy of the clean sources as reference tree [16:21] pushd /tmp/old [16:21] -> go to /tmp/old; 'pushd' to remember the previous directory, so that we can go back conveniently [16:22] debian/rules patch [16:22] -> 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:22] (I have a silly script which just attempts all of those until one succeeds :) ) [16:22] cp -a . /tmp/new; cd ../new [16:23] -> copies our patched reference tree to our new work directory /tmp/new where we can hack in [16:23] got an error with the first patch command [16:23] oh? [16:23] (darn, I tested them two hours ago on hardy) [16:23] snhome: you mean with debian/rules patch? [16:23] yes [16:24] (see -chat) [16:24] let's do a braindead modification now [16:24] sed -i 's/Linux/Penguin/g' README [16:24] -> changes the README file; of course you can use your favourite editor, but I wanted to keep my examples copy&pasteable [16:24] and now we create a patch between the reference and our new tree: [16:25] (btw, please cry out in -chat when I'm too fast) [16:25] cd .. [16:25] -> go back to /tmp, i. e. where our reference tree (old) and hacked tree (new) is located [16:25] diff -Nurp old new > 95_penguins.patch [16:25] -> generate the patch (Ignore the 'recursive directory loop' warnings) [16:26] oops [16:26] sorry, you need "apt-get install debhelper" if you get errors about dh_testdir [16:27] * pitti fixes his notes and gives you guys time to catch up [16:28] mv /tmp/95_penguins.patch debian/patches [16:28] -> move the patch from /tmp to the source tree's patch directory, where it belongs. [16:28] *uff* :) [16:28] Now take a look at your shiny new debian/patches/95_penguins.patch. [16:30] error on the mv [16:30] pushd [16:30] you need to cd back to the udev_xxx dir [16:30] oops, sorry [16:30] you have to do "popd" before the mv [16:31] * pitti wishes there was an "erase previous line" IRC command [16:32] so, it's "diff", "popd", "mv" [16:32] please make a noise when you are ready [16:32] ready [16:32] noise [16:33] ready [16:33] ready [16:33] ready [16:33] peep [16:33] ready [16:33] ready [16:33] awesome [16:33] ready [16:33] debian/patches/95_penguins.patch looks plausible? [16:33] after that, if you do 'debian/rules patch', you'll see that the patch applies cleanly; please do 'debclean' afterwards to unapply the patches and get back a pristine source tree [16:34] if you don't have debclean, install devscripts, or do "fakeroot debian/rules clean" instead [16:35] it calls the 'clean' target, which means, clean up all built files, unapply patches, etc. [16:35] fakeroot worked for me [16:35] if it complains about missing build dependencies, use the fakeroot command [16:36] so, 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 conceivable [16:36] so this procedure is the life safer if anything else fails [16:37] Pretty much work, isn't it? Since this happens pretty often, I created a very dumb helper script 'dsrc-new-patch' for this purpose. [16:40] Sorry, I'm a bit late, so I decided to read from start, and just catch up. However, I'm stuck at debian/rules patch, gives me the error message: [16:40] dh_testdir [16:40] make: dh_testdir: Command not found [16:40] make: *** [patch-stamp] Error 127 [16:40] I've tried both debian/rules build and all the things you mentioned, but it doesn't seem to work. I've also looked in the file, but it doesn't seem to work... [16:40] Need devscripts ? [16:40] Don-1: please ask questions in #ubuntu-classroom-chat [16:40] Sorry. [16:40] hi [16:42] pitti: you fell of the internet? [16:42] minus the missing packages - how did the session go? everything seemed sensible? [16:43] I'm new at this so will need to study what we did [16:43] maybe we can do some general Q&A while pitti recovers from whatever problem he has right now [16:43] Here or at -chat? === livewire1 is now known as livewire [16:43] http://wiki.ubuntu.com/PackagingGuide/PatchSystems is a guide to patch systems [16:43] just ask in #-chat and I'll carry over the questions [16:44] so, once we patch the package, what then? [16:44] good question [16:44] :) [16:44] in most cases as an Ubuntu developer you work on existing packages [16:44] argh, sorry; my interweb tube broke [16:44] what's the last line you saw from me? [16:44] 21:53 < pitti> Pretty much work, isn't it? Since this happens pretty often, I created a very dumb helper script 'dsrc-new-patch' for this purpose. [16:44] ugh [16:45] ok, I'll go on there [16:45] let me just reply to jetsaredim [16:45] pitti: it was: "arrrghhhh....." [16:45] :) [16:45] jetsaredim: if you can upload your packages directly, you do that, if you can't you use the sponsorship process to get the patched package uploaded - jetsaredim: I'll talk a bit in my session about debdiffs [16:45] Using dsrc-new-patch, above steps would reduce to: [16:46] ../dsrc-new-patch 95_penguins.patch [16:46] (.., or wherever you downloaded the script) [16:46] dholbach: what about changing the package version, etc how does that get determined [16:46] sed -i 's/Linux/Penguin/g' README [16:46] [16:46] that looks slightly better, doesn't it? If you like the script, please put it into your ~/bin, so that it is in your $PATH [16:46] jetsaredim: I'll cover that in a different session :) [16:46] ah [16:46] * jetsaredim returns to lurking [16:47] but I had to torture you with the close-to-the-metal method for the sake of understanding. [16:47] You might have noticed that we applied all previous patches before creating our's. Does someone have an idea why this is done? [16:48] numbering [16:48] the patches have numbers? [16:48] well, it's related to that, yes [16:48] sequential, dependant ? [16:48] * chrome___ thinks that the patches might depend on each other [16:48] asserting patch interdependencies. [16:48] 2. 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:48] Patches can depend on each other, [16:49] i. 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:49] That'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:49] Since above procedure is so hideously complicated, patch systems were invented to aid you with that. [16:50] Let'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:51] == pmount: cdbs with simple-patchsys == [16:51] cdbs' simple-patchsys.mk module matches its name, it has no bells and whistles whatsoever. However, it is pretty popular since it is sufficient for most tasks, and long ago I wrote a script 'cdbs-edit-patch' which most people can live with pretty well. This script is contained in the normal cdbs package. [16:51] Many Ubuntu packages use the cdbs build system; you can look at the "Build-Depends:" line in debian/control (it has cdbs) to check === Heres is now known as Her0 [16:52] or look in debian/rules whether it has includes for /usr/share/cdbs [16:52] if you have that, then you can use the following script [16:52] You 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:53] everyone please look in debian/patches, debian/rules to get a feeling how it looks like [16:53] so, let's mess up pmount a bit [16:53] and add a new patch [16:53] cd /whereever/you/unpacked/the/source/pmount-0.9.16 [16:53] cdbs-edit-patch 07-simple-readme.patch [16:53] (drops you into a subshell for editing again, similar to dsrc-new-patch) [16:53] echo 'This should document pmount' > README [16:53] (some braindead modification) [16:53] [16:54] easy, isn't it? [16:54] this 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 ones [16:54] Editing an already existing patch works exactly the same way. [16:54] so I won't give a demo [16:55] questions? [16:55] sorry, my falling off the internet costed me 5 minutes, so I'll just quickly run through the other major patch system before I conclude [16:56] == ed: dpatch == [16:56] dpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch' [16:56] packages which use this build-depend on 'dpatch', and debian/rules includes 'dpatch.mk' [16:57] that script dpatch-edit-patch is actually pretty similar to the other two scripts I talked about [16:57] The two most important things you should be aware of: [16:57] * 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:57] (forgetting to update 00list is a common cause of followup uploads :-P ) [16:58] * 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:58] using dpatch for non-native patches is rare, and normally you do not need to worry about how a .dpatch file looks like [16:58] but I think it's important to mention it [16:58] The manpage is very good and has examples, too [16:59] There is a wiki page https://wiki.ubuntu.com/MOTU/School/PatchingSources which has examples for the most common patch systems [16:59] and how to use them [16:59] it's a good cheatsheet when you will actually get to this [16:59] pitti: http://wiki.ubuntu.com/PackagingGuide/PatchSystems :) [16:59] but with above tools you should be able to change the vast majority of packages [16:59] thanks for your attention! [17:00] BTW, I'll do the same session on Friday again [17:00] and hopefully catch up with the other stuff [17:00] :-) [17:00] pitti: thank-you [17:00] thanks pitti [17:00] thanks pitti [17:01] Nice, pitti! Very helpful :) [17:01] thanks pitti [17:01] than you [17:01] That's one more directory starting to make sense... [17:01] thanks a lot pitti [17:01] thanks! [17:01] next up we have cprov and mrevell, two launchpad hackers who can tell you a lot about a very cool feature of Launchpad called PPA: Personal Package Archives [17:01] thanks alot [17:01] Thank you! [17:02] thanks mate! It was truly helpful [17:02] Celso and Matthew: the stage is yours [17:02] Hi all, Welcome to the Personal Package Archive (PPA) session. [17:02] for those of you who have joined in later: please ask questions in #ubuntu-classroom-chat and prefix them with QUESTION: ... [17:02] Just for curiosity, say "me" if you are attending the PPA session. [17:02] me [17:02] * jetsaredim me [17:03] me too [17:03] me [17:03] me [17:03] * tamrat me [17:03] me [17:03] +1 [17:03] me [17:03] me [17:03] me [17:03] me [17:03] me - half of the session. [17:03] me [17:03] me [17:03] me [17:03] me [17:03] * nareshov too [17:03] me [17:03] me [17:03] me [17:03] me [17:03] me [17:03] rock on Launchpadders! [17:03] me [17:03] me listening [17:03] wow, lot of people here [17:04] This is great, thanks for coming everyone :) [17:04] me [17:04] me [17:04] me lurking ;) [17:04] so, as daniel said, make question on #-chat and before anything else thanks for coming. [17:05] So, first obvious question is "What is this PPA thing ?" [17:05] Launchpad provides the infrastructure to process, build and publish uploads for ubuntu primary archive. [17:06] the same set of sub-systems is available for all users via Personal Package Archives (PPA) in their own restricted archive. === Martinp24 is now known as Martinp23 [17:07] i.e., it's possible to have a Martin Pitti archive or a Mozilla Development Archive. [17:07] does it sound like a good definition for you all ? [17:08] please say '+1' if it's fine or add your comment. [17:08] +1 [17:08] +1 [17:08] 5 [17:08] +1 [17:08] +1 [17:08] +1 [17:08] 4 [17:08] +1 [17:08] i have to go now [17:08] + [17:08] +1 [17:08] +1 [17:08] 3 [17:08] thanks for everything [17:08] +1 [17:08] +1 [17:08] +1 [17:08] 2 [17:08] +1 [17:08] +1 [17:08] 1 [17:08] +1 [17:08] +1 [17:08] +1 [17:08] +1 [17:08] +1 [17:09] happy users :) [17:09] +1 [17:09] +1 [17:09]