| === dholbach_ is now known as dholbach | ||
| === schmidtm__ is now known as schmidtm | ||
| === Asylo40876 is now known as CaptPizzle | ||
| === cprov-afk is now known as cprov | ||
| mok0 | ahem | 16:55 |
|---|---|---|
| norsetto | *cough* *cough* | 16:59 |
| ryuujin | huh | 16:59 |
| james_w | Hi all | 17:00 |
| norsetto | hi james_w :) | 17:00 |
| james_w | Is it my session now? | 17:01 |
| norsetto | the floor is yours ... | 17:01 |
| james_w | sorry, I'm a bit lost, I've just been in a meeting | 17:01 |
| mok0 | Yep it's you | 17:01 |
| james_w | cool | 17:01 |
| james_w | let's get started | 17:01 |
| james_w | who's here for some bzr love? | 17:01 |
| ktenney | indeed | 17:02 |
| Serdar | bizar love sounds funny, I'm in | 17:02 |
| james_w | cool | 17:03 |
| james_w | hi everyone, thanks for coming | 17:03 |
| james_w | my name is James Westby, I'm going to talk about using bzr for your packaging work | 17:03 |
| james_w | I'm going to go over some of the basics, and you can play along at home | 17:04 |
| james_w | if you're interested in bzr for packaging then there will be loads of cool stuff happening over the next few months, so keep an eye out | 17:04 |
| james_w | if I'm going to fast, or I don't explain something well enough then please yell and let me know | 17:05 |
| james_w | first of all we need to install the necessary tools | 17:05 |
| james_w | what release of Ubuntu is everyone running? | 17:05 |
| Bijoy | Hardy | 17:06 |
| swingnjazz | 8.04 | 17:06 |
| Oli`` | 810 | 17:06 |
| azmodie | hardy | 17:06 |
| james_w | if you are on Intrepid then "sudo aptitude install bzr-builddeb" is enough | 17:06 |
| pdragon | 8.04 | 17:06 |
| james_w | if you on Hardy then "sudo aptitude install bzr" | 17:06 |
| james_w | and you will need my PPA enabled to get the bzr-builddeb I will be using in the demonstration. | 17:06 |
| james_w | < Serdar> +QUESTION: what does bzr stand for? There is lack of information about that at https://wiki.ubuntu.com/UbuntuDeveloperWeek# | 17:07 |
| james_w | Serdar: bzr is a version control system, if you want to find out more then you can read bobbo's session from yesterday on bzr | 17:07 |
| james_w | those on Hardy will want https://edge.launchpad.net/~james-w/+archive | 17:08 |
| james_w | install bzr-builddeb - 2.0~ppa1~hardy1 from there | 17:08 |
| james_w | Serdar: https://wiki.ubuntu.com/MeetingLogs/devweek0809/BazaarIntro | 17:09 |
| james_w | deb http://ppa.launchpad.net/james-w/ubuntu hardy main | 17:09 |
| james_w | that's the sources.list line for hardy users | 17:10 |
| james_w | then "sudo aptitude update; sudo aptitude install bzr-builddeb=2.0~ppa1~hardy1" | 17:10 |
| james_w | then remove the line from your sources.list again so you don't accidentally install something else from there | 17:10 |
| james_w | on Monday the unstoppable dholbach gave a Packaging 101 session where he looked at the hello-debhelper package | 17:11 |
| james_w | you can find the log of the session at https://wiki.ubuntu.com/MeetingLogs/devweek0809/Package | 17:11 |
| james_w | I've prepared a small branch of this package for us to play with today | 17:11 |
| james_w | so once you have all of the tools installed then please run "bzr branch lp:~james-w/+junk/hello-debhelper" | 17:12 |
| james_w | you will get a new directory called "hello-debhelper" if you look in there you will see all of the files of the package | 17:12 |
| james_w | if you run "bzr log" in the directory you can see that this is a bzr branch with a couple of revisions | 17:13 |
| james_w | shout out once you've got that | 17:13 |
| nasam | Jep, got that | 17:13 |
| * Oli`` shouts | 17:13 | |
| kaaloo | got it | 17:13 |
| james_w | nice work | 17:13 |
| james_w | right, I've just pushed a new revision to my branch for us to play with, so please run "bzr pull" from the hello-debhelper directory | 17:15 |
| james_w | it should tell you that you have a new revision | 17:16 |
| james_w | if you run "bzr log" now you will see an extra revision | 17:16 |
| james_w | to look at the change that I made run "bzr diff -r2..3" | 17:16 |
| james_w | which means "show me the changes between revisions 2 and 3" | 17:16 |
| james_w | you'll see that I made a small change to the packaging | 17:16 |
| james_w | now, it's your turn | 17:17 |
| james_w | open "src/hello.c" in your favourite editor | 17:18 |
| james_w | and find the bit that prints "Hello, world!" in a box | 17:18 |
| james_w | line 115 | 17:18 |
| james_w | and edit it to say hello to you instead | 17:18 |
| james_w | win 14 | 17:18 |
| james_w | oops | 17:19 |
| chombium | <chombium> QUESTION: bzr pull returned: No revisions to pull. | 17:19 |
| james_w | chombium: what does "bzr revno" say for you? | 17:19 |
| chombium | 3 | 17:19 |
| chombium | but I got revision 2 and 3 with bzr log | 17:20 |
| chombium | seems it's ok | 17:20 |
| james_w | chombium: that's ok, you just grabbed the branch after I had done the push, it won't make a difference | 17:21 |
| james_w | once you've changed the greeting to say hello to you then save the file and run | 17:21 |
| james_w | bzr commit | 17:21 |
| james_w | this will open an editor window in which you should type your commit message | 17:21 |
| james_w | something like | 17:21 |
| james_w | Changed the greeting to say "hello" to me | 17:22 |
| james_w | give me a shout once you've done it | 17:22 |
| ktenney | ok | 17:22 |
| pdragon | done | 17:22 |
| nasam | done | 17:22 |
| kaaloo | ok | 17:22 |
| swingnjazz | done | 17:22 |
| mok0 | !!! | 17:22 |
| albert23 | done | 17:22 |
| Ampelbein | !!! | 17:22 |
| bobbo | done | 17:22 |
| james_w | great | 17:23 |
| james_w | at this point you could push your work to launchpad, but it's not necessary for this demonstration so we won't | 17:23 |
| chombium | done | 17:23 |
| james_w | instead I've got a change to the package that I propose you make in your branch | 17:23 |
| james_w | I've put this on launchpad for you to look at | 17:24 |
| james_w | so, you can "merge" this change, and review it, and decide if it is good or not | 17:24 |
| james_w | if you run "bzr merge lp:~james-w/+junk/hello-debhelper-proposed" | 17:24 |
| james_w | it will download my changes and try and merge them in to yours | 17:24 |
| james_w | < mok0> +QUESTION: what would happen if we push the new version? | 17:25 |
| james_w | mok0: you wouldn't be able to push to the location that you got the code from as only I can | 17:25 |
| mok0 | ok | 17:26 |
| james_w | you could push to a location that you own, and then either ask me to merge your changes, or simply keep a branch of your own to experiment with for a while | 17:26 |
| james_w | I see some of you have done the merge and have noticed a conflict | 17:27 |
| james_w | if you run bzr diff you will be able to see my changes | 17:28 |
| james_w | at the bottom you can see that I added a message about bzr. | 17:28 |
| james_w | as you didn't change anything in this area there was no problem in making that change in your tree, so it didn't cause a conflict | 17:29 |
| james_w | however, I changed the message to say my name, and you did the same | 17:29 |
| james_w | so we tried to do two different things to the same line, and bzr can't work out what to do | 17:30 |
| james_w | so it asks for our help | 17:30 |
| james_w | to do that it marks the area conflicted | 17:30 |
| james_w | if you try and run "bzr commit" now it won't let you, it tells us to resolve the conflicts first | 17:30 |
| james_w | open src/hello.c in your editor again, and find the same line as before | 17:31 |
| james_w | you will see your change, with mine below it | 17:32 |
| james_w | and <<<<<<<<<< above both >>>>>>>>> below them and ================== in the middle | 17:32 |
| james_w | these are "conflict markers" | 17:32 |
| james_w | we need to leave the text how we want, and without these markers | 17:32 |
| james_w | so you can delete my change, and all of the markers | 17:33 |
| james_w | or you could delete yours and leave mine | 17:33 |
| james_w | or you could change the message to say hello to both of us | 17:33 |
| james_w | or do whatever you want, it's your choice | 17:33 |
| james_w | so, fix the conflict however you like, and then save the file and run "bzr diff" | 17:34 |
| james_w | if you pastebin the output I will review it for you | 17:34 |
| ktenney | what about the new hello.c.* files? | 17:35 |
| james_w | ktenney: we'll deal with those in a moment | 17:35 |
| nasam | http://paste.ubuntu.com/43096/ | 17:36 |
| james_w | nice work nasam | 17:37 |
| azmodie | http://pastebin.com/m54562949 | 17:37 |
| james_w | azmodie: you kept your change | 17:38 |
| james_w | ? | 17:38 |
| azmodie | yeah | 17:38 |
| james_w | great, so it's not shown in "bzr diff" as those lines are the same as in the last revision you committed | 17:39 |
| james_w | ok, so the last step is to tell bzr we are happy with the state of the files now | 17:39 |
| james_w | run "bzr resolve src/hello.c" | 17:39 |
| ktenney | I kept your change | 17:40 |
| james_w | the hello.c.* files that ktenney mentioned should now be automatically removed for you, and you will be allowed to commit | 17:40 |
| james_w | "bzr resolve" will resolve all the files that no longer have conflict markers, so that can be quicker | 17:41 |
| james_w | once you've done that please commit | 17:41 |
| james_w | whenever you do a merge you should review the changes, as even when bzr doesn't mark any files conflicted you may not want all of the changes | 17:42 |
| james_w | now we can try building the package | 17:42 |
| james_w | that's why we installed bzr-builddeb, as it makes this easy | 17:42 |
| james_w | run "bzr builddeb" or "bzr bd" for short and you should see it get to work | 17:43 |
| james_w | there's more you can do, but now you know how to pass changes to packages around, merge them, deal with conflicts, and then build the packages | 17:44 |
| james_w | that's all I wanted to talk about today | 17:44 |
| james_w | are there any questions? | 17:44 |
| norsetto | see -chat ... | 17:44 |
| Oli`` | Yeah a few of us are getting "bzr: ERROR: A Debian packaging error occurred: Could not find upstream tarball at ../tarballs/hello-debhelper_2.2.orig.tar.gz" | 17:45 |
| james_w | that's a bug in bzr-builddeb that I think I have since fixed | 17:45 |
| james_w | can you all try running the command again? | 17:45 |
| nasam | Now it works | 17:45 |
| james_w | if it doesn't work second time then it's a new bug | 17:46 |
| james_w | ok, thanks, that'll be fixed in the next release | 17:46 |
| ktenney | dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 | 17:46 |
| mok0 | make[1]: *** No rule to make target `distclean'. Stop. | 17:46 |
| mok0 | m | 17:46 |
| azmodie | i had same error but adding the deb source ppa solved it. trying to download origional src ppa: deb-src http://ppa.launchpad.net/james-w/ubuntu hardy main | 17:47 |
| james_w | they sound like problems with the package | 17:47 |
| mok0 | Let's fix it, then | 17:47 |
| james_w | I'm not the person to teach you about packaging :-) | 17:47 |
| azmodie | ls | 17:48 |
| james_w | mok0: I'm not sure why that's failing the build, it should be a non-fatal error | 17:49 |
| mok0 | yeah | 17:49 |
| james_w | < norsetto> +QUESTION: can bzr bd work with pbuilder? | 17:51 |
| james_w | if you use plain pbuilder then "bzr bd --builder pdebuild" might do what you want | 17:51 |
| james_w | I need to work out how to make it play better with things like pbuilder-dist and sbuild though | 17:52 |
| james_w | what I do for now is build a source package ("bzr bd -S") and then call pbuilder-dist myself | 17:52 |
| james_w | < kaaloo> +QUESTION : You would still have to update the changelog beforehand ? | 17:52 |
| james_w | kaaloo: yes, you still have to do the changelog stuff yourself. | 17:53 |
| james_w | < mok0> +QUESTION: Is there a manpage for bzr bd? | 17:53 |
| james_w | mok0: no, but "bzr help bd" might help | 17:54 |
| james_w | also check /usr/share/doc/bzr-builddeb/ for the user manual | 17:54 |
| james_w | any last questions, as we are almost out of time | 17:54 |
| * dholbach hugs james_w | 17:54 | |
| james_w | hey dholbach, I wondered where you were | 17:54 |
| * james_w hugs dholbach | 17:54 | |
| james_w | < mok0> +QUESTION: is bzr bd and bzr-buildpackage the same program being run? | 17:55 |
| james_w | mok0: yes, bzr-buildpackage just execs "bzr bd", it's there more to try and help people find the command | 17:55 |
| mok0 | ok | 17:56 |
| james_w | right, thanks all | 17:56 |
| james_w | if you want more then you can talk to me at any time | 17:56 |
| chombium | thank you james | 17:56 |
| james_w | and remember | 17:56 |
| james_w | bzr rocks | 17:56 |
| mok0 | Thanks james_w!! | 17:56 |
| swingnjazz | well done, james_w :) | 17:57 |
| Coper | thanks james_w | 17:57 |
| bobbo | thanks james_w! | 17:57 |
| Ampelbein | thanks james_w! | 17:57 |
| azmodie | thanks james_w | 17:57 |
| pdragon | thanks! | 17:57 |
| james_w | thanks all | 17:58 |
| james_w | next up is norsetto himself I believe | 17:58 |
| norsetto | thanks james_w, very enlightening talk! | 17:58 |
| norsetto | lets start then, while the iron is still hot ... | 17:59 |
| sebner | norsetto: \o/ | 17:59 |
| norsetto | welcome everybody, I'm gonna talk about how to make a package update | 17:59 |
| norsetto | in particular, "all you wanted to know about whats next after dch -i" (at least I hope) | 18:00 |
| norsetto | hi sebner | 18:00 |
| norsetto | do we all know what we mean by a package upgrade? | 18:00 |
| rUkie | no i dont | 18:01 |
| norsetto | anyone ... don't feel shy ... | 18:01 |
| bobbo | upgrading to a new upstream release? | 18:01 |
| norsetto | bobbo: yes | 18:01 |
| norsetto | bobbo: thx | 18:01 |
| bobbo | \o/ | 18:01 |
| norsetto | we do have a package in our repository, foo-1, and upstream just released a new shiny foo-2 | 18:02 |
| norsetto | normally, we would get the update from debian, but there are cases when we don't | 18:02 |
| norsetto | for instance, if debian is in a freeze, or the package is orphaned, or its a native ubuntu package | 18:02 |
| norsetto | or we simply need it urgently, and then pass the result back to debian | 18:03 |
| norsetto | so far so good? please stop me if something is not clear, or I'm too slow/fast | 18:03 |
| norsetto | +<Coper> QUESTION: If i package a new package for Ubuntu should we notify debian so they get it? | 18:04 |
| norsetto | Coper: yes, definetively | 18:04 |
| Coper | how? | 18:05 |
| norsetto | ok, so, we now know we have a new upstream version, first thing to do is to get it | 18:05 |
| sebner | Coper: file a bug in Debian BTS | 18:05 |
| norsetto | Coper: you need to open a RFP or ITP bug in the bts, and submit the package to mentors.debian.net | 18:06 |
| mok0 | Good topic for a lesson! | 18:06 |
| norsetto | we can get the tarball manually, using http or wget | 18:06 |
| norsetto | if there is a watch file in the current package, we can use that | 18:06 |
| norsetto | just check if there is a debian/watch file, or give the command "uscan" at the source tree root | 18:07 |
| norsetto | uscan --verbose just gives you some more info about what it is trying to do | 18:08 |
| norsetto | finally, there could be a get-orig-source target in debian/rules that we can use | 18:08 |
| norsetto | for instance you can do "make -f debian/rules get-orig-source" to execute it | 18:08 |
| norsetto | be carefull to read changelog, copyright and README.Source, the previous packager might mention few things to be doing on the upstream tarball | 18:09 |
| norsetto | like, removing non distributable content, or repackaging | 18:10 |
| norsetto | ok, now that we have an upstream tarball, we need to rename it in accordance to our policy | 18:10 |
| norsetto | foo-2.tar.gz will become foo_2.orig.tar.gz | 18:11 |
| norsetto | like as we would do for a shiny new package | 18:11 |
| norsetto | now, the simplest case is if there are no changes to packaging and no changes outside of debian | 18:12 |
| norsetto | just untar your tarball, copy the old debian dir to the new source tree | 18:13 |
| norsetto | and finally add the new changelog entry | 18:13 |
| norsetto | I wish all updates were this simple :-) | 18:13 |
| norsetto | you still with me? | 18:13 |
| norsetto | ok, more difficult if in the previous package there were changes outside of debian | 18:14 |
| norsetto | for instance the previous packager made inline changes instead of using a patch system, you can check this by checking the old diff.gz | 18:15 |
| norsetto | in this case just copying debian won't be enough, we have to make all those changes outside of debian too | 18:16 |
| norsetto | you can do that manually, or using patch | 18:16 |
| norsetto | for instance "zcat ../foo-1.diff.gz | patch -p1" (given at the src tree root) | 18:16 |
| norsetto | here we can already have some pain, as some of the old changes might not apply anymore, or not apply correctly | 18:17 |
| norsetto | all the above procedure can be automated by using uupdate | 18:18 |
| norsetto | again in the src tree root of the old package, give the comman uupdate ../foo_2.orig.tar.gz and all these steps will be automatically performed | 18:18 |
| norsetto | now, as you should have guessed already, before doing all this we need to know what has changed in the new upstream tarball, and we need to check what the previous packager did with the old package | 18:19 |
| norsetto | any idea how we can check what is the difference between the old tarball and the new ? | 18:20 |
| norsetto | +<mok0> QUESTION: What's the difference between uscan and uupdate? | 18:20 |
| sebner | norsetto: diff? | 18:21 |
| mok0 | diff -r old new | 18:21 |
| norsetto | mok0: uscan just check and eventually download upstream tarball, uupdate do the update | 18:21 |
| norsetto | mok0: uscan can also do the update, depend on what it is in the watch file | 18:21 |
| norsetto | sebner: mok0: yes, diff is our friend | 18:22 |
| norsetto | I personally like diff -Nurb | 18:22 |
| norsetto | once you have the diff, you should check line by line and see what has changed upstream | 18:22 |
| RoAkSoAx | norsetto: uscan does the update if you add 'debian uupdate' in the watchfile right? | 18:22 |
| norsetto | RoAkSoAx: perfect | 18:23 |
| norsetto | tedious perhpas, but its really necessary | 18:23 |
| norsetto | ok, some example of the things that might have changed upstream and that needs to be considered in the packaging | 18:24 |
| norsetto | one important thing is license | 18:24 |
| norsetto | sometime upstream changes the licensing of their packages, or add new file with new licenses | 18:24 |
| norsetto | there is a tool you can use to help you detect these changes | 18:25 |
| norsetto | its called licensecheck and is in the devscripts package | 18:25 |
| norsetto | licensecheck -r --copyright | 18:25 |
| norsetto | will check all files in all subdirs and also check copyrights | 18:26 |
| norsetto | just an example, you may want to check bug 257664 | 18:26 |
| norsetto | https://bugs.launchpad.net/ubuntu/+source/picard/+bug/257664 since ubottu is on strike | 18:27 |
| ubot5 | Launchpad bug 257664 in picard "picard crashed with SIGSEGV in memset()" [Medium,Fix released] | 18:27 |
| norsetto | thanks ubot5, I love you | 18:27 |
| mok0 | thanks for no link :-) | 18:28 |
| sebner | lol | 18:28 |
| norsetto | you may want to download the old and the new package and see the diff | 18:28 |
| norsetto | as you can see from the changelog I detected some changes in the licensing, and updated debian/copyright | 18:29 |
| norsetto | another example is https://bugs.launchpad.net/ubuntu/+source/source-highlight/+bug/243692 | 18:29 |
| ubot5 | Launchpad bug 243692 in source-highlight "web pages with ~ do not underline correctly" [Undecided,Fix released] | 18:30 |
| norsetto | as you can see in this case the license was changed from gpl-2 to gpl-3 | 18:30 |
| norsetto | ok, any other things we should check? ideas? | 18:31 |
| norsetto | what about patches? | 18:31 |
| RoAkSoAx | norsetto: update patches to match new files ? | 18:31 |
| sebner | norsetto: another dependencies or newer versions | 18:32 |
| norsetto | RoAkSoAx: yes, does the old package have patches? Are they still needed anymore? Do they still apply correctly? | 18:32 |
| norsetto | sebner: yes, do we need new build-deps for instance | 18:33 |
| norsetto | sebner: this is usually reported in upstream ChnageLog, but sometime you only discover it by looking at upstream autoconf files (or Makefile) | 18:33 |
| norsetto | another thing to check, if the package includes a man page, check if there are upstream changes that needs to go in there | 18:34 |
| norsetto | and don't forget to update the man page date if you do that ;-) | 18:34 |
| norsetto | any change in file locations? Maybe upstream now isntall files differently, we may need to change our packaging | 18:35 |
| norsetto | will this new upstream version close an bug open in LP? | 18:35 |
| norsetto | if so, close it from the changelog | 18:36 |
| norsetto | is upstream web page changed? | 18:36 |
| norsetto | report the change in control and copyright | 18:36 |
| norsetto | is upstream now shipping a .desktop file, or new icons? | 18:37 |
| norsetto | make sure you install those | 18:37 |
| norsetto | maybe you need to remove those in the old package if they are obsolete | 18:37 |
| norsetto | sometime upstream changes few things which need you to change compilation flags | 18:38 |
| norsetto | for instance, some plugin which are now ON while you used OFF or viceversa | 18:38 |
| norsetto | if upstream is a library particular care has to be taken | 18:38 |
| norsetto | check if API/ABI change is reflected in SONAME/version | 18:39 |
| norsetto | you can use check-symbols or icheck to help you with that | 18:39 |
| norsetto | you may need a library transition, which involves perhpas rebuilding many packages already in the archive | 18:40 |
| norsetto | ok, perhaps at this point it is better to go together through an example | 18:40 |
| norsetto | anyone is working on an update at the moment? | 18:40 |
| sebner | norsetto: FF :P | 18:41 |
| nxvl | o/ | 18:41 |
| norsetto | nxvl: do you want to tell us which package? | 18:41 |
| nxvl | norsetto: terminator | 18:41 |
| nxvl | but it's not a good example since i maintain it on upstream bzr | 18:42 |
| nxvl | :D | 18:42 |
| * bobbo just did three... | 18:42 | |
| norsetto | bobbo, ok, sounds good, bug numer? | 18:42 |
| bobbo | bug #249997 | 18:43 |
| sebner | ubot5: hop hop hop | 18:43 |
| ubot5 | Factoid 'hop hop hop' not found | 18:43 |
| norsetto | ok, we also have the new upstream tarball in there :-) | 18:44 |
| norsetto | lets download the old package, create a htop directory and download it with "apt-get source htop" | 18:44 |
| bobbo | (https://bugs.edge.launchpad.net/ubuntu/+source/htop/+bug/249997) | 18:44 |
| ubot5 | Launchpad bug 249997 in htop "Package is outdated " [Wishlist,Fix released] | 18:44 |
| norsetto | bobbo: ok your version is in the rchive already :) | 18:45 |
| RoAkSoAx | bug 256439 | 18:45 |
| RoAkSoAx | https://bugs.launchpad.net/ubuntu/+source/ao40tlmview/+bug/256439 | 18:45 |
| ubot5 | Launchpad bug 256439 in ao40tlmview "Please update ao40tlmview to 1.04" [Wishlist,Confirmed] | 18:45 |
| bobbo | ooh, didnt know that, sorry! | 18:46 |
| norsetto | bobbo: no probelm :-) | 18:46 |
| norsetto | ok, lets check this one | 18:46 |
| norsetto | create an ao40tlmview dir and download teh src package in tehre with apt-get source ao40tlmview | 18:46 |
| norsetto | have we all got the current package? | 18:47 |
| norsetto | nobody? | 18:48 |
| norsetto | ok lets check the new upstream tarball | 18:49 |
| norsetto | there is no watch file, no link in the bug report | 18:49 |
| norsetto | we can check copyright and see what is the download location there | 18:50 |
| norsetto | which will give us this location: http://wwwhome.cs.utwente.nl/~ptdeboer/ham/ao40/ao40tlmview-1.04.tgz | 18:50 |
| norsetto | lets get it with wget: "wget http://wwwhome.cs.utwente.nl/~ptdeboer/ham/ao40/ao40tlmview-1.04.tgz" | 18:51 |
| norsetto | now we have to rename it so that its compliant with out policy | 18:51 |
| norsetto | what would the correct name be? | 18:51 |
| sebner | norsetto: ao40tlmview_1.04.orig.tgz | 18:52 |
| norsetto | sebner: indeed | 18:52 |
| norsetto | lets see what is the diff between these two upstream version | 18:52 |
| norsetto | lets untar the new tarball: tar xzvf ao40tlmview_1.04.orig.tar.gz | 18:52 |
| norsetto | and teh old one: tar xzvf ao40tlmview_1.03.orig.tar.gz | 18:53 |
| norsetto | now we can check the diff: diff -Nurb ao40tlmview_1.03.orig.tar.gz ao40tlmview_1.04.orig.tar.gz > ao40tlmview_1.04.diff | 18:54 |
| norsetto | sorry: diff -Nurb ao40tlmview-1.03 ao40tlmview-1.04 > ao40tlmview_1.04.diff | 18:54 |
| norsetto | as you can see there is only one interesting change | 18:55 |
| sebner | norsetto: makefile one? | 18:56 |
| norsetto | yes, this has no impact on us however | 18:56 |
| norsetto | so, its a very simple update | 18:56 |
| norsetto | if you check the old package, you will see that there are no changes outside of debian | 18:57 |
| norsetto | so, we just cipy the old debian dir and we add a new changelog entry | 18:57 |
| norsetto | we then rebuild the package | 18:58 |
| sebner | norsetto: though we have to change maintainer and that stuff | 18:58 |
| norsetto | if the rebuild is ok, we attach the new diff.gz to the bug report and ask a sponsor to upload it | 18:59 |
| norsetto | sebner: yes, if the package was not already an ubuntu package | 18:59 |
| norsetto | sebner: debuild will tell us anyhow ;-) | 18:59 |
| sebner | ^^ true | 18:59 |
| sebner | norsetto: and .dsc is not needed at the bug report? | 18:59 |
| norsetto | as you can see this is exactly what RoAkSoAx did, even if he added a coupld of additional changes | 18:59 |
| norsetto | sebner: no | 19:00 |
| sebner | norsetto: but it was once afaik!? | 19:00 |
| norsetto | ok, thats about it then | 19:00 |
| norsetto | sebner: no, as far as i know it was never required | 19:00 |
| sebner | O_o | 19:00 |
| sebner | ok | 19:00 |
| sebner | norsetto: thanks for this great session :D | 19:00 |
| norsetto | sebner: you may remember interdiff, but that is gone | 19:01 |
| norsetto | <albert23> norsetto: for an update, we should update the standards-version? | 19:01 |
| norsetto | albert23: you shouldn't in general, unless there is a change that warrants it | 19:01 |
| norsetto | albert23: but adding the watch file is a nice addition | 19:01 |
| sebner | norsetto: ah yes, interdiff | 19:02 |
| norsetto | any other question before I leave the floor to the next lecture? | 19:02 |
| sebner | norsetto: sebner@ubuntu:~/merges/ao40tlmview/ao40tlmview-1.03$ uupdate ../ao40tlmview_1.04.orig.tgz | 19:02 |
| sebner | uupdate: new version number not recognized from given filename | 19:02 |
| sebner | Please run uupdate with the -v option | 19:02 |
| norsetto | sebner: yes, thats because of the tgz extension | 19:03 |
| sebner | norsetto: ah only working with tar.gz? | 19:03 |
| norsetto | sebner: it should be ao40tlmview_1.04.orig.tar.gz or ao40tlmview-1.04.tgz (even though I'm not sure the latter will work) | 19:04 |
| sebner | norsetto: kk :) and shouldn it be licensecheck -r . ? | 19:04 |
| norsetto | sebner: yes, or * | 19:04 |
| norsetto | who is the next lecturer? | 19:04 |
| sebner | norsetto: kk because you were using --copyright ^^ | 19:04 |
| * mathiaz waves at norsetto | 19:05 | |
| norsetto | sebner: yes, --copyright also gives you the cipyright it finds in the headers | 19:05 |
| norsetto | hi mathiaz! | 19:05 |
| mathiaz | norsetto: hi :) | 19:05 |
| norsetto | so, unless there are further q we can leave the floor to mathiaz, I can asnwer questions in ubuntu-motu anyway | 19:05 |
| norsetto | mathiaz: its all your! | 19:06 |
| mathiaz | norsetto: thanks ! | 19:07 |
| mathiaz | After this technical session on packaging, I'd like to give an overview about the Ubuntu Server Team, who we are, how you can get involved (and put in practice what norsetto just taught you) and how we work | 19:08 |
| mathiaz | Who are we ? | 19:08 |
| mathiaz | We are a group of people that have an interest in server related software. | 19:09 |
| mathiaz | Most of the information can be found under our wiki pages at: | 19:09 |
| mathiaz | https://wiki.ubuntu.com/ServerTeam | 19:09 |
| mathiaz | As an extension we tend also to deal with setups found in corporate | 19:09 |
| mathiaz | environments, such as directory services (ldap, AD) web services or network | 19:09 |
| mathiaz | authentication. | 19:10 |
| mathiaz | Some of us are working for Canonical in the Server team. Others have services | 19:10 |
| mathiaz | running on Ubuntu and are interested in fixing bugs. | 19:10 |
| mathiaz | The Canonical server team is lead by Rick Clark (dendrobates) and composed of: | 19:10 |
| mathiaz | Chuck Short - zul, Dustin Kirkland - kirkland, Mathias Gug - mathiaz, Thierry | 19:10 |
| mathiaz | Carrez - Koon, they have a generalist profile. | 19:10 |
| mathiaz | Soren Hansen - soren, our virtualization specialist. | 19:11 |
| mathiaz | Kees Cook - kees and Jamie Strandboge - jdstrand, are member of the Ubuntu | 19:11 |
| mathiaz | Security Team. They will make a presentation about the Security team later this | 19:11 |
| mathiaz | week. | 19:11 |
| mathiaz | Nick Barcet - nijaba, is also working for Canonical as the Ubuntu Server product manager. | 19:11 |
| mathiaz | Regular contributors takes on important tasks and lead them to completion. | 19:11 |
| mathiaz | some of them include (listed in alphabetical order): | 19:12 |
| mathiaz | Adam Sommer - sommer - our documentation guru. He's taken the task to review | 19:12 |
| mathiaz | and update the Server Guide. Thus he is in contact with the Documentation team. | 19:12 |
| mathiaz | Ante Karamatić - ivoks - another long time contributor to the Server Team. Also | 19:12 |
| mathiaz | a member of MOTU, he has looked over the apache package and improved the bacula | 19:12 |
| mathiaz | package. | 19:12 |
| mathiaz | Neal McBurnett - nealmcb - he has multiple interest: documentation, | 19:13 |
| mathiaz | virtualization. | 19:13 |
| mathiaz | Nicolas Valcárcel - nxvl - lots of work in bug triagging and packaging. | 19:13 |
| mathiaz | He is also involved in the Security team and the MOTU team. | 19:13 |
| norsetto | nxvl kiks ass | 19:13 |
| mathiaz | Scott Kitterman - ScottK - main interest are mail services | 19:13 |
| mathiaz | If you're interested in postfix or clamav he is the man to talk to. He is also involved with the MOTU team. | 19:14 |
| mathiaz | We are a diverse group that have different interests. | 19:14 |
| mathiaz | We're also involved in other teams from the Ubuntu project. | 19:14 |
| mathiaz | This is one of the caracteristic of the Server Team: | 19:15 |
| mathiaz | we all share a common interest in server technologies, but have differents skills. | 19:15 |
| mathiaz | Thus being part of the team often means representing the Server Team in other areas of the Ubuntu project. | 19:15 |
| mathiaz | Being a contributor to the server team can be taken under different roles: | 19:16 |
| mathiaz | The helpers answers questions on the ubuntu-server mailing list and the #ubuntu-server IRC channel | 19:16 |
| mathiaz | Triagers dig into bugs the ubuntu-server LP team is subscribed to. | 19:16 |
| mathiaz | Our LP team is a bug contact for a list packages, such as samba, openldap, mysql or apache2. | 19:17 |
| mathiaz | The current list of packages can be found here: | 19:17 |
| mathiaz | https://bugs.launchpad.net/~ubuntu-server/+packagebugs. | 19:17 |
| mathiaz | A mailing list gathers all the bugs related to the ubuntu-server team: | 19:17 |
| mathiaz | ubuntu-server-bugs@lists.ubuntu.com | 19:17 |
| mathiaz | https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs | 19:18 |
| mathiaz | This is a great way to start with the LP bug tracker and doesn't require any knowledge of programming languages. | 19:18 |
| mathiaz | We're working closely with the BugSquad team - triaggers participate on their mailing lists | 19:18 |
| mathiaz | More information about the BugSquad team can be found here: https://wiki.ubuntu.com/BugSquad/ | 19:19 |
| mathiaz | And once in a while with have the honor of having our own HugDay where the whole bug triagger community helps us. | 19:19 |
| mathiaz | Once bugs have been triagged, it's time to fix them. | 19:19 |
| mathiaz | This is when the packagers | 19:20 |
| mathiaz | come into the game. | 19:20 |
| mathiaz | This role requires an interest in packaging. | 19:20 |
| mathiaz | We maintain a list of bugs that are easy too fix: | 19:20 |
| mathiaz | https://bugs.launchpad.net/~ubuntu-server/+mentoring | 19:20 |
| mathiaz | harvest is another source of bug lists. | 19:21 |
| mathiaz | Fixes can get easily make their way into the ubuntu repositories via the | 19:21 |
| mathiaz | sponsorship process. | 19:21 |
| mathiaz | https://wiki.ubuntu.com/SponsorshipProcess | 19:21 |
| mathiaz | Doing work on the packaging front leads to a close a collaboration with the MOTU team and is a great way to gain experience to become a MOTU. | 19:22 |
| mathiaz | https://wiki.ubuntu.com/MOTU | 19:22 |
| mathiaz | Testers are another way to take part of the Server Team activity. | 19:22 |
| mathiaz | This role doesn't require a lot of deep technical knwoledge. | 19:23 |
| mathiaz | We work with the Ubuntu QA team - https://wiki.ubuntu.com/QATeam. | 19:23 |
| mathiaz | Now that we've passed Feature Freeze, new features and new packages are available in the archive and need to be tested before released for wide spread consumption. | 19:24 |
| mathiaz | Here is an example: AD directory integration with likewise-open. | 19:24 |
| mathiaz | If you have access to an AD domain, installing ubuntu and testing if you can join the domain with likewise-open is an easy way to contribute to the Server Team right now. | 19:25 |
| mathiaz | Testers are now taking a more and more important role as we're approaching release: | 19:25 |
| mathiaz | alpha5 and 6 will be followed by Beta on October, the 2nd then RC up to Final on October, the 30th. | 19:25 |
| mathiaz | We're responsible for ensuring that the ubuntu-server isos are working correctly, which involves performing a dozen of tests for two isos. | 19:26 |
| mathiaz | The list of tests can be found in the wiki: | 19:26 |
| mathiaz | https://wiki.ubuntu.com/Testing/Cases/ServerInstall | 19:26 |
| mathiaz | Server hardware support is another area where testing is welcome. | 19:26 |
| mathiaz | We're trying to make sure that ubuntu can used on the main server hardware, so if you have access to such hardware, popping a cd into the machine, installing a standard ubuntu server and reporting that whether it has successfully installed or failed is an easy way to contribute to the server team. | 19:27 |
| mathiaz | This work is coordinated in the ServerTesting Team wiki pages: | 19:27 |
| mathiaz | ttps://wiki.ubuntu.com/ServerTestingTeam | 19:27 |
| mathiaz | There are also the Documentors | 19:28 |
| mathiaz | Browsing the ubuntu-server mailing list archive, lurking in the #ubuntu-server irc channel or going through the forum posts shows patterns in user's questions. | 19:29 |
| mathiaz | Recurring themes are identified and turned into documentation. | 19:29 |
| mathiaz | A wiki page in the community section of help.ubuntu.com is first created. | 19:29 |
| mathiaz | Once the quality has improved, a new section is added to the server guide. | 19:29 |
| mathiaz | All this work is undertaken by the Documentors of the Server Team. | 19:30 |
| mathiaz | Collaboration with the Documentation team is done on a daily basis to achieve consistency with other help resources. | 19:30 |
| mathiaz | More information about the Documentation team: https://wiki.ubuntu.com/DocumentationTeam | 19:31 |
| mathiaz | Adam Sommer leads the update and review of the Ubuntu Server guide. | 19:31 |
| mathiaz | The document is maintained in a bzr tree. | 19:31 |
| mathiaz | Helping Adam will introduce you to docbook and distributed versioning with bazaar. | 19:32 |
| mathiaz | Getting started involves following 3 steps outlined in the Server Team Knowledge base: | 19:33 |
| mathiaz | https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#Ubuntu%20Server%20Guide | 19:33 |
| mathiaz | There is also the option to go over server related wiki pages on the community help pages. | 19:33 |
| mathiaz | A good starting point is the Server page that has pointer to lots of howtos. | 19:33 |
| mathiaz | https://help.ubuntu.com/community/Servers | 19:33 |
| mathiaz | Another hat you can wear in the Server Team is the Developer one. | 19:34 |
| mathiaz | They develop new features usually specified during the Ubuntu Developer Summit that takes place at the begining of each release cycle. | 19:34 |
| mathiaz | Tracked by a blueprint we have around 3 months to get a new feature into Ubuntu. | 19:34 |
| mathiaz | Now that Feature Freeze is in place, we've moved our focus to testing and bug | 19:34 |
| mathiaz | fixing. | 19:34 |
| mathiaz | Thus the developer roles won't be very active until we release intrepid at the end of october. | 19:35 |
| mathiaz | As you can see, contributing to the Server Team can be undertaken in more than one way. | 19:35 |
| mathiaz | t usually involves a lot of interaction with other teams from the Ubuntu project. | 19:36 |
| mathiaz | It's also a good way to show your contribution to Ubuntu and helps getting Ubuntu membership. | 19:36 |
| mathiaz | The GettingInvolved page gives an overview of the roles I've talked about above: | 19:37 |
| mathiaz | https://wiki.ubuntu.com/ServerTeam/GettingInvolved | 19:37 |
| mathiaz | So how do we work ? | 19:37 |
| mathiaz | We track our progress on the Roadmap and meet once a week to discuss outstanding issues. | 19:38 |
| mathiaz | Our current work can be tracked on the Roadmap wiki page: | 19:38 |
| mathiaz | https://wiki.ubuntu.com/ServerTeam/Roadmap | 19:38 |
| mathiaz | We use the ubuntu-server mailing to coordinate our activities, discuss policy change in the team as well as helping out users. | 19:39 |
| mathiaz | How to join the Server Team and start contributing ?How to join the Server Team and start contributing ? | 19:39 |
| mathiaz | Joining the ubuntu-server team on LP is as simple as subscribing to the ubuntu-server mailing list and applying for membership on LP: | 19:40 |
| mathiaz | https://launchpad.net/~ubuntu-server/ | 19:40 |
| mathiaz | If you already know which role you'd like to contribute as, you can find a list of tasks in the Roadmap. | 19:41 |
| mathiaz | Don't hesitate to ask one of the team members involved in your area of interest. | 19:41 |
| mathiaz | Most of the information related to the ServerTeam can be found in the ServerTeam wiki pages: | 19:42 |
| mathiaz | https://wiki.ubuntu.com/ServerTeam. | 19:42 |
| mathiaz | If you're overwhelmed by all the available information and you're lost, come talk to me. | 19:43 |
| mathiaz | I'll help get out of the mist and we'll find a way you can get involved in the Server Team. | 19:43 |
| chombium | QUESTION: what do developers do during the freeze time? fixing bugs? | 19:43 |
| mathiaz | chombium: yes - we switch to bug fixing mode. | 19:44 |
| mathiaz | chombium: all of the members of the server team actually take part of the different roles | 19:44 |
| mathiaz | chombium: they should be thought of as hat rather then just a unique role | 19:45 |
| RoAkSoAx | QUESTION: "<mathiaz> They develop new features usually specified during the Ubuntu Developer Summit ..." Does this involves involves knowing some kind of programming language? (If Yes, which are the most common?)) | 19:45 |
| mathiaz | RoAkSoAx: new features don't necessarly involve programming langages | 19:46 |
| mathiaz | RoAkSoAx: for example, we discuss during last summit migrating openldap to use cn=config instead. | 19:46 |
| mathiaz | RoAkSoAx: that involved mainly packaging work (in this case shell scripting). | 19:46 |
| RoAkSoAx | mathiaz, so might involve just configuration changes? | 19:46 |
| RoAkSoAx | oh ok | 19:46 |
| RoAkSoAx | :) | 19:46 |
| mathiaz | RoAkSoAx: there are some features that require development work with programming langages | 19:47 |
| mathiaz | RoAkSoAx: for example pitti wrote the jockey utility - it was speced out during uds | 19:47 |
| mathiaz | RoAkSoAx: and he coded it using python | 19:47 |
| chombium | QUESTION: is there any preferred programming language for implementation of the features, or its up to the developer to decide? | 19:48 |
| mathiaz | chombium: python tends to be the prefered programming language used by the Ubuntu developer community | 19:49 |
| RoAkSoAx | QUESTION: And what about requesting or suggesting new howto's for the server guide? For example, what if i would like to contribute with a howto of how to install DRBD? | 19:49 |
| mathiaz | chombium: but we're gladly accepting contributions coded in other langages | 19:50 |
| chombium | mathiaz: i'm searching for a hole which I can fill :) | 19:50 |
| mathiaz | RoAkSoAx: I'd suggest to start with a wiki page on help.ubuntu.com/community/ | 19:50 |
| mathiaz | RoAkSoAx: once it has matured, you can branch the server guide and add a section about it. | 19:51 |
| RoAkSoAx | mathiaz, perfect, thanks. :) | 19:51 |
| mathiaz | RoAkSoAx: then you'd send your merge request to the ubuntu-doc mailing. sommer will probably have a look at it and review it. | 19:51 |
| mathiaz | RoAkSoAx: https://wiki.ubuntu.com/ServerTeam/KnowledgeBase#Ubuntu%20Server%20Guide <- outlines how to contribute to the Ubuntu Server Guide. | 19:52 |
| RoAkSoAx | ok cool :) | 19:54 |
| arquebus | mathiaz- some very important information here, you should post a log of this lecture in a wiki | 19:56 |
| mathiaz | arquebus: IIRC the logs will be posted somewhere on the wiki | 19:56 |
| arquebus | ok | 19:57 |
| laga | mathiaz: great session, thanks | 19:57 |
| chombium | arquebus: https://wiki.ubuntu.com/MeetingLogs/devweek0809/ServerTeam | 19:57 |
| arquebus | chombium: thx | 19:57 |
| mathiaz | If there are more questions, feel free to email me or ping me in #ubuntu-server | 19:58 |
| mathiaz | I'll leave the floor to cprov that will introduce you to the wonderfull world of PPA | 19:58 |
| chombium | thank you very much mathiaz! | 19:59 |
| cprov | mathiaz: thanks, you are the ubuntu-server star! | 19:59 |
| cprov | I guess we can start the 'Introduction to PPAs' session. | 20:00 |
| cprov | who is here to learn more about PPAs ? | 20:00 |
| laga | maybe i am. ;) | 20:01 |
| * siretart raises his hand! | 20:02 | |
| cprov | There is a overview document from previous PPA sessions that might be a useful read: https://wiki.ubuntu.com/CelsoProvidelo/PPASystemOverview | 20:02 |
| sebner | siretart: debian is missing this cool things :P | 20:02 |
| cprov | you can start asking question while I talk trivialities about what PPA is | 20:03 |
| Kurt | *raises hand* | 20:03 |
| cprov | I imagine a lot of people already know about PPA (Personal Package Archives) features in Launchpad | 20:04 |
| === mcas_away is now known as mcas | ||
| cprov | in few words, it's a groups of services already used to manage and maintain the Ubuntu distribution encapsulated in a way every launchpad user can benefit of it. | 20:05 |
| cprov | It includes the basic components used for Ubuntu: a upload-processor, a build-service and a repository builder. | 20:06 |
| cprov | basically, it helps users to get source packages built and published in the same way they would be if uploaded to the Ubuntu distribution. | 20:08 |
| cprov | The system is in production since the end of the last year, more overall stats can be found at https://edge.launchpad.net/ubuntu/+ppas | 20:09 |
| cprov | we are already over 1000 active PPAs (yay!) | 20:09 |
| cprov | laga: QUESTION: when will it be possible to sign packages on the PPA? | 20:10 |
| cprov | YES :) we are very committed to deliver this features (implemented in a proper way) early in this launchpad milestone. | 20:10 |
| cprov | laga: QUESTION: i seem to remember reading about a "replay attack" on PPAs. can you comment on that? | 20:11 |
| cprov | right, replay attacks (someone maliciously re-uploading a PPA package uploaded by a ubuntu maintainer) are completely solved in production. | 20:12 |
| cprov | PPA changesfiles are stored without the original signature and makes impossible to re-upload them. | 20:12 |
| laga | and how was it possible? --verbose ;) | 20:12 |
| cprov | laga: the original signature is not available anymore, you can't 're-play' | 20:13 |
| cprov | laga: QUESTION: is there an API for the PPAs, eg to make copying packages into another distro series easier? | 20:13 |
| cprov | yes, soyuz features will be exposed via the public launchpad API soon (launchpadlib) and we have plans to include PPA features very soon. | 20:15 |
| cprov | aga: QUESTION: how much buildd capacity is available? how much could one use up without getting smackedß | 20:15 |
| cprov | laga: launchpad IS team is working hard in increasing the number of available builders, https://edge.launchpad.net/+builds | 20:16 |
| cprov | laga: that certainly makes build-load less than an issue. | 20:16 |
| cprov | laga: but we have plans to establish fair limits to avoid some users to make things slower to the others. | 20:17 |
| laga | good :) | 20:18 |
| cprov | stefanlsd: QUESTION: Is there anyway to ensure the PPA's that we are using are safe? Or do we just have to trust the PPA owner? | 20:18 |
| cprov | stefanlsd: you always have to trust the owner/uploader | 20:18 |
| cprov | the PPA system guarantees the binaries you will be installed were in fact generated from the corresponding source | 20:19 |
| cprov | also, when signed, will guarantee that you will be installing exactly what you aim to. | 20:19 |
| cprov | but it can't really guarantee that the binary is not doing any malicious task in you system, the users/communities have to audit it somehow | 20:20 |
| cprov | We thought about creating a recommendation/voting system on top of the current PPAs, but that's just speculation. I'd be really interested in listen to ideas about this topic. | 20:22 |
| cprov | laga: QUESTION: do the ppas take orig.tar.gz from the main archives? | 20:22 |
| cprov | laga: yes, uploaders can easily re-use origs from the Ubuntu Primary archive, it saves a lot of bandwidth and makes package diffs clearer. | 20:23 |
| cprov | mok0: QUESTION: Is the PPA software available so I could have my own system running at home? | 20:23 |
| cprov | mok0: not yet, it is still part of Launchpad. | 20:24 |
| mok0 | :-( | 20:24 |
| cprov | mok0: it also means that when LP goes free it will be available :) | 20:24 |
| mok0 | :-) | 20:24 |
| cprov | laga: QUESTION: when will support for debian packages be available? | 20:24 |
| cprov | laga: yes, we are organising the infrastructure to start supporting it. | 20:25 |
| cprov | laga: in way we can improve the collaboration between debian and ubuntu. | 20:26 |
| mok0 | awesome | 20:26 |
| cprov | for instance, we plan to, when it's the interest of the user to have a debian PPA as a 'mirror' of the ubuntu one, in way that all package successfully built in the ubuntu PPA will be automatically pushed to the debian PPA. | 20:27 |
| cprov | what do you think about it ? | 20:27 |
| cprov | are you perplexed with this idea ? | 20:30 |
| siretart | that sounds great! | 20:30 |
| sebner | cprov: really great!" | 20:30 |
| sebner | cprov: I suppose sid chroot? | 20:30 |
| cprov | siretart: yes, the way it saves time on the developer side is nice. | 20:31 |
| cprov | sebner: yes, unstable, because that's where they can be uploaded in debian. | 20:31 |
| sebner | cprov: ah, sure ^^. Great! EST? | 20:32 |
| cprov | siretart: QUESTION: is a 'backport this package' button planned? - what's the spec name if yes? | 20:32 |
| cprov | siretart: yes, we plan to implement this and also native-debian-syncs as part of a more structure and reliable way of merging/diffing two different archives (repositories) | 20:34 |
| cprov | siretart: it would check/prepare a proper version and also compose a proper changelog for backports/syncs. | 20:36 |
| cprov | siretart: making such tasks easier and more reliable. | 20:36 |
| siretart | \o/ | 20:36 |
| sebner | siretart is now complety satisfied ^^ | 20:37 |
| * siretart cant await using it :) | 20:38 | |
| cprov | there is also another feature planned related with supporting backports in PPA that involves giving the users the ability to set the required archive dependencies for a PPA in order to build backports using what is already available in the corresponding ubuntu backports. | 20:38 |
| cprov | sebner: QUESTION: cool new features are planned but do we see them in *near* future? EST? | 20:39 |
| cprov | sebner: I do see them all done in the next 4 months, at least, signed-ppas & the debian-support | 20:40 |
| sebner | cprov: /me is happy to be a LP beta tester :P | 20:40 |
| cprov | We are also glad to have this army of very bright users working on our side. LP is only helping you to change the world! | 20:42 |
| cprov | siretart: QUESTION: are any new architectures planned for the near future? | 20:44 |
| cprov | not really, we are following XEN in this journey. | 20:44 |
| cprov | I've heard (read) some news about the SPARC support, but I'm no expert. | 20:45 |
| cprov | do you have any suggestions for improving the current documentation ? https://help.launchpad.net/Packaging/PPA | 20:49 |
| cprov | I personally miss a more hands-on packaging guide, successfull use-cases / workflows based on PPAs | 20:50 |
| cprov | the best way to improving the experience when using PPAs, IMHO, it making easier to see how the current users have solved their problems. | 20:51 |
| cprov | I've found a very interesting post indexing useful PPAs -> http://ubuntudoctor.com/content/blog/The-Personal-Package-Archives-Index | 20:52 |
| cprov | and I guess that's it for today, another very interesting round of PPA questions & answers session, I hope you liked it. | 20:54 |
| sebner | cprov: it was great. thanks very much :) | 20:55 |
| cprov | please, keep the suggestions coming, we are willing to provide the most complete and easiest service for building and distributing software for debian-like systems. | 20:56 |
| cprov | when filling bugs, don't forget: product -> soyuz and tag: ppa | 20:56 |
| cprov | I'm leaving the stage for huats & didrocks with their "Various ways to patch a package" | 20:57 |
| cprov | thank you, guys | 20:58 |
| === cprov is now known as cprov-afk | ||
| sebner | cprov-afk: : thx again and I'm looking forward to these shiny cool new features ;) | 20:58 |
| didrocks | thank you very much cprov, it seems to not be very crowded. We will wait 10 minutes :) | 20:58 |
| cprov-afk | didrocks: okay, good luck! | 20:59 |
| huats | thanks cprov-afk | 20:59 |
| didrocks | cprov-afk: thx :) | 20:59 |
| sebner | huats: didrocks : \o/ | 21:00 |
| didrocks | ok, I think this is the time :) | 21:02 |
| didrocks | huats: are you ready? | 21:02 |
| didrocks | so, waiting for huats, who is around? :) | 21:03 |
| nijaba | o/ | 21:03 |
| Kurt | o/ | 21:03 |
| huats | I am here :) | 21:04 |
| sebner | \o | 21:04 |
| didrocks | great, so, I think there is no need to use -chat for the questions | 21:04 |
| didrocks | just ask them here prefixing them with QUESTION: | 21:04 |
| didrocks | Welcome to the hands-on training session about how to patch Ubuntu source packages! | 21:04 |
| didrocks | First, we really want to thank pitti for his previous sessions on february from which this session is largerly inspired of. | 21:05 |
| === mcas is now known as mcas_away | ||
| didrocks | this session intends only to go through the different patches system encountered in various packages. It will not teach you how to create a package or what a package is composed of. For this, see dholbach's excellent session on this (https://wiki.ubuntu.com/MeetingLogs/devweek0809/Package). | 21:05 |
| didrocks | really focus on doing stuffs that we are showing you and not taking notes. This is an hands-on demo! The IRC log will be available at https://wiki.ubuntu.com/MeetingLogs/devweek0809/PackagePatches when the session will be over. | 21:05 |
| didrocks | please install few packages during the general introduction of what is a patching a source (for that, you have to have the deb-src repository activated in your source.list) | 21:05 |
| didrocks | sudo apt-get install dpatch cdbs quilt patchutils devscripts debhelper fakeroot | 21:05 |
| didrocks | mkdir patchtraining | 21:05 |
| didrocks | cd patchtraining | 21:05 |
| didrocks | apt-get source cron udev keepalived ed xterm | 21:05 |
| didrocks | wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch | 21:06 |
| didrocks | chmod 755 dsrc-new-patch | 21:06 |
| didrocks | for those who have already followed pitti's sesssion, we are taken the same examples (namely cron, udev, keepalived, ed and xterm) as they are little pacakges which illustrates each one "one way to pach a source". | 21:06 |
| didrocks | So, during the dowload time, just a quick introduction | 21:06 |
| didrocks | == Why use separate patches? == | 21:06 |
| didrocks | in earlier times, people just applied patches inline (ie. directly in the source code tree). | 21:07 |
| didrocks | however a package contains a diff.gz file, showing the differences beetween the pristine source and every modifications made by downstream, this makes it very hard to extract patches later to modify them. | 21:07 |
| didrocks | (tell me is I speed to much) | 21:07 |
| didrocks | indeed, how to distinguish the patch you wish to extract and the other modifications? How to send simply only your modification to upstream (as their development has gone further since, so every patches aren't good to be applied...)? | 21:07 |
| didrocks | 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. | 21:07 |
| didrocks | so, using separate patches is clearly a good way to ensure it will be easy for you and for other's to add/remove a patch when it will be no more usefull. | 21:08 |
| didrocks | the ideal state is a complete unmodified tarball from upstream, plus the packaging bits in debian/ and all the clean and separate patches in it. | 21:08 |
| didrocks | to sum up, that mainly means that "lsdiff -z <sourcepackage>.diff.gz" only contains "debian/" | 21:08 |
| didrocks | the first idea was to create regular patch files and store them in debian/patches/. Then, 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. | 21:08 |
| didrocks | this is way several standard patch systems were created. Those are easy enough to use and provide some tools for editing previous patch, applying one or more patch, unapplying others... well... just to play :) | 21:09 |
| didrocks | hands on when you will be here and/or if you have questions :) | 21:09 |
| sebner | \o/ | 21:09 |
| didrocks | sebner: is everything ok? | 21:09 |
| sebner | didrocks: sure ^^ | 21:10 |
| didrocks | every downloads are finished? | 21:10 |
| huats | didrocks: wait a bit more... | 21:11 |
| didrocks | ok huats ;) | 21:11 |
| didrocks | if anyone have a question, this is the right time :) | 21:11 |
| huats | questions already ? | 21:11 |
| huats | ;) | 21:12 |
| didrocks | hum, well, everything's fine, so enough speech, time to play! Are you ready to put your hands on? ^^ | 21:12 |
| didrocks | let's assume yes :D (it is late, let's say that some people will read the log :)) | 21:13 |
| chombium | \o/ | 21:13 |
| didrocks | == cron example: inline patches == | 21:13 |
| didrocks | the first package is the simplier one, with no patch system at all. A counter-example against the "old" style of packaging, that you surely not follow appart from the original maintainer use this. | 21:13 |
| didrocks | with this "system", we directly edit the code in the source tree, reposing in the fact that those content will be available in the diff.gz, but all mixed together... making this very inconvenient for submitting patches upstream. | 21:13 |
| didrocks | ... or reviewing for merges (patch 1 is fixed in the new upstream version, but not patch 2), how to easy know which files to take? | 21:14 |
| didrocks | if you do 'lsdiff -z cron*.diff.gz', you see changes which are not in debian/. So, you can see that we have such a package. | 21:14 |
| didrocks | (you can try it right now) | 21:14 |
| didrocks | you can also take a look at it to see how all patches are lumped together. Can anybody in a second told me to which files corresponds the current statement "Use latest lsb logging functions" in the changelog? | 21:14 |
| didrocks | … I am sure, you can't :) No file explicitely declared in the changelog and you will strike… | 21:15 |
| didrocks | if you have any question regarding this way of "not patching", this is the right time :) | 21:16 |
| didrocks | lsdiff if very great to determine in a diff.gz file has other directories/files than just debian/ one | 21:16 |
| huats | does anybody is following ? are we moving too fast ? please tell us right now :) | 21:16 |
| Kurt | I'm following :) | 21:17 |
| chombium | me too :) | 21:17 |
| huats | ok great ! | 21:17 |
| didrocks | yeah, two people are alive \o/ | 21:17 |
| huats | sorry didrocks but it was neede I think :) | 21:17 |
| sebner | QUESTION: what does the -z option does? *too lazy to search manpage* | 21:17 |
| huats | it is for the compression sebner | 21:17 |
| didrocks | it tells than the diff file is a gunzip one | 21:18 |
| didrocks | so, compressed, yes :) | 21:18 |
| sebner | k, thx :) | 21:18 |
| sebner | and yes I'm also here ^^ | 21:18 |
| didrocks | just look again at the diff.gz to see how packaging and code changes are wildly mixed and, let's move on the first (and the most manual) patch mechanis | 21:18 |
| didrocks | sebner: thanks ;) | 21:18 |
| didrocks | == udev: separate patches, but no standard/automated patch system == | 21:19 |
| didrocks | this is the logical evolution of the previous statement. Let's patch something by doing some diff between the previous states of the source code and our one. | 21:19 |
| didrocks | so, everything has to be done manually, making it the most complicated patch system. All others patch system relies on this one and automate it. So, you will first have to understand how it works "beyond the gears" (no no, not Google one ;)). | 21:20 |
| didrocks | due to this complexity, this manual mechanism is rarely used by maintainers, and even it can appears as being difficult for people who has never done this before, you will have to understand it to see how patch system works. | 21:20 |
| didrocks | so please, do not hesitate to ask questions. As we are the latest, we have (almost) all the night/the rest of the day, depending your time (Ok, we want to sleep also ;)). | 21:20 |
| didrocks | pitti strongly advise you to print and hang over your desk this general approach, so, I will quote him :) | 21:21 |
| didrocks | 1. copy the clean source tree to a temporary directory /tmp/old | 21:21 |
| didrocks | 2. apply all previous 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). | 21:21 |
| didrocks | 3. copy the whole source tree again: cp -a /tmp/old /tmp/new | 21:21 |
| didrocks | 4. go into /tmp/new, do your modifications | 21:21 |
| didrocks | 5. go back into /tmp and generate the patch with diff -Nurp old new > mypatchname.patch | 21:21 |
| didrocks | 6. move the newly generated patch to <original source dir>/debian/patches/mypatchname.patch | 21:22 |
| didrocks | diff -Nurp is used because, in general, we want the following diff options: | 21:22 |
| didrocks | -N -> include new files | 21:22 |
| didrocks | -u -> unified patches (context diffs are <bad/ugly/wathever word you can find> to read) | 21:22 |
| didrocks | -r -> recursive | 21:22 |
| didrocks | -p -> bonus, you can see the name of the affected C and some other language function in the patch | 21:22 |
| didrocks | anybody has a question about the principal method? | 21:23 |
| didrocks | (we will do a hands-on example now, to burn this in your mind forever :)) | 21:23 |
| chombium | lets get our hands dirty :) | 21:24 |
| didrocks | chombium: hehe, sure you will :) | 21:24 |
| didrocks | so, if there is no question, let's move on | 21:24 |
| didrocks | open a shell in you favorite console tool! | 21:24 |
| didrocks | $ cd udev-* # -117 on hardy and -124 on intrepid | 21:25 |
| didrocks | => we are now in our original source tree where we want to add a new patch | 21:25 |
| didrocks | $ cp -a . /tmp/old | 21:25 |
| didrocks | => we create a copy of the clean sources as reference tree (always use name like old, origin, pristine...). We have done with step 1 | 21:25 |
| didrocks | $ pushd /tmp/old | 21:25 |
| didrocks | does everybody know pushd? | 21:26 |
| sebner | nope | 21:26 |
| Kurt | the directory stack :) | 21:26 |
| didrocks | Kurt: yes :) | 21:26 |
| didrocks | => "pushd" is equivalent to cd, but it will use a stack for to remember the previous directory, so, that it will be easy later to go to our <patchtraining/udev-*> directory with "popd" | 21:26 |
| didrocks | sebner: is it ok? | 21:26 |
| sebner | didrocks: ah I already heard of it but forgot it ^^ /me is quite tired already ^^ | 21:27 |
| didrocks | sebner: be brave, it's time to manipulate :) | 21:28 |
| didrocks | $ debian/rules patch | 21:28 |
| didrocks | => all well-configured debian/rules file has a "patch" (or patch-stamp, apply-patch, setup, unpack...) target that able us to apply every existing patch in debian/patches/ or something similar. This is better than applying all patches one by one, in the right order with the "patch" command. You have to look in debian/rules how it is called. | 21:28 |
| sebner | ^^ | 21:28 |
| didrocks | If you just want to apply a subset of patch to modify an existing one, you will (but we will not treat this case in this example) only apply them manually (with patch command). | 21:29 |
| chombium | QUESTION: cp -a ./tmp/old returns cp: missing destination file operand after `./tmp/old' | 21:29 |
| didrocks | Step 2 is now over | 21:29 |
| didrocks | chombium: this is a space beetween . and / | 21:29 |
| didrocks | you copy the current directory . to /tmp/old | 21:29 |
| chombium | didrocks: tx | 21:29 |
| chombium | got it :( | 21:29 |
| didrocks | you're welcome :) | 21:29 |
| didrocks | has everyone applied their patch? | 21:30 |
| didrocks | just shout when it's done :) | 21:30 |
| * Ampelbein shouts | 21:30 | |
| * didrocks is afraid :) | 21:30 | |
| Kurt | done | 21:31 |
| didrocks | chombium: ok? | 21:31 |
| * sebner will read the logs tomorrow again xD /me -> bed | 21:31 | |
| chombium | o/ | 21:31 |
| huats | ok sebner bye | 21:31 |
| chombium | didrocks: yes | 21:32 |
| didrocks | sebner: good night. Sleep time has triumphed :) | 21:32 |
| didrocks | great! | 21:32 |
| sebner | huats: didrocks : great work so far. ROCK ON and I'll read the logs ;) | 21:32 |
| didrocks | let's go on | 21:32 |
| didrocks | sebner: contact us on IRC if you have any question in reading the log :) | 21:32 |
| didrocks | (huats or I) | 21:32 |
| sebner | kk, gn8 fols | 21:32 |
| didrocks | ok, so, next step is | 21:32 |
| didrocks | $ cp -a . /tmp/new; cd ../new | 21:33 |
| didrocks | chombium: be careful, there is a space again :) | 21:33 |
| didrocks | => just copy the content with applied patches to /tmp/new where we will begin to work with. This corresponds to step 3. | 21:33 |
| didrocks | so, at this time, /tmp/old and /tmp/new are identical | 21:33 |
| chombium | didrocks: :) | 21:34 |
| didrocks | both contain the patched source code | 21:34 |
| didrocks | Now, let's hack and make a new beautiful patch: | 21:34 |
| didrocks | $ sed -i 's#Linux#GNU/Linux#g' README | 21:35 |
| didrocks | RMS will enjoy, I'm pretty sure! This simply replace all Linux instance in the README file by GNU/Linux one. You can obviously hack with the tools you prefer (editors like vim/emacs or IDE like eclipse/anjuta/kdevelop). | 21:35 |
| didrocks | just do the changes you desire with the tool you want. As the idea is to keep it minimal here, sed will be ok for us :) This step 4 can length a long time before being completed. | 21:35 |
| * didrocks hopes everyone know sed :) | 21:36 | |
| didrocks | are you ok? | 21:36 |
| chombium | didrocks: depends on the bugs we need to take care of ;) | 21:36 |
| Kurt | I am | 21:36 |
| chombium | me too | 21:36 |
| didrocks | chombium: yes, of course :) | 21:36 |
| didrocks | it's time to create the patch now! For this, we will compared the old tree to the new one (all have previous patches applied, appart from your current hack and extra work). | 21:37 |
| didrocks | $ cd .. | 21:37 |
| didrocks | => for this, we prefer to go back to /tmp (the patch that we would see will state /tmp/old/README vs /tmp/new/README which is better than comparing ../old/README vs README) | 21:37 |
| didrocks | $ diff -Nurp old new > 90_happy_rms.patch | 21:37 |
| didrocks | => so there, we compare the previous source (old) to our hacked tree (new). And we put the differences in the file 90-rms.patch | 21:37 |
| didrocks | oupss, 90_happy_rms.patch | 21:38 |
| didrocks | Step 5 completed! (ignore the 'recursive directory loop' warnings) | 21:38 |
| didrocks | is your patch created? | 21:38 |
| chombium | yes | 21:39 |
| didrocks | note that it is a good idea to use number prefix for patch names as generally they will be applied in a asciibetical order. As many patches depends on others (ie. you modify a file that is already modified by a previous patch, so the context of the patch has changed), you ensure that everyone will apply that in the same logical order. Some patches will not applied in the pristine code! | 21:39 |
| didrocks | $ popd | 21:39 |
| didrocks | => as previously said, as we have stacked the previous directory, this will lead you the <patchtraining/udev-*> recorded one | 21:39 |
| didrocks | $ rm -rf /tmp/old /tmp/new | 21:39 |
| didrocks | => it's everytime a good idea to clean what has to be cleaned, as we will never use that again :) | 21:40 |
| didrocks | $ less /tmp/90_happy_rms.patch | 21:40 |
| didrocks | => have a look at your patch (you can use gedit/kate if you prefer) to see to what it looks and ensure everything seems fine. | 21:40 |
| Kurt | I notice that SELinux was replaced by SEGNU/Linux | 21:40 |
| didrocks | tell me when everything is all right. Just a few step has to be done now | 21:40 |
| didrocks | Kurt: yes, so, when you use sed, be careful with what you do :) | 21:41 |
| Kurt | didrocks: heh :) | 21:41 |
| didrocks | this is the case here, but sed was just use to make a quick hack | 21:41 |
| didrocks | used* | 21:41 |
| didrocks | $ mv /tmp/90_happy_rms.patch debian/patches | 21:41 |
| didrocks | => copy the patch to the patches directory of your current source package directory (remember, you are in <patchtraining/udev-*>) so that your debian/rules will be able to find it and apply it during the build of the package. | 21:41 |
| chombium | Kurt: the regular expression was bad | 21:41 |
| didrocks | => Step 6 done! We can take a breath, our patch is perfect ;) | 21:41 |
| didrocks | chombium: yes, I know. That was not the goal of this classroom to teach regular expression :) | 21:42 |
| didrocks | ping when you are ready! | 21:42 |
| didrocks | you can test in calling debian/rules patch and confirm that your patch apply correctly! | 21:42 |
| chombium | didrock: yes rigth. I was just explaining to Kurt | 21:42 |
| Kurt | lol yeah I was just making a remark, I realized what had happened. Sorry for the fuss :) | 21:43 |
| chombium | seems good | 21:43 |
| didrocks | Kurt: no problem :) | 21:43 |
| didrocks | Kurt: but that shows that you are following, that's good! | 21:44 |
| didrocks | are you all right? | 21:45 |
| didrocks | just 2 remaining persons apparently :) | 21:45 |
| Kurt | I am | 21:45 |
| chombium | o/ | 21:45 |
| didrocks | obviously, this is not trivial for a complete beginner, but after doing this a couple of times, you should understand exactly what is involved and how it work with every system patches. | 21:45 |
| didrocks | so, let's confess that doing this everyday is simply tiring and boring. The idea will be more to concentrate on hacking and fixing stuff than generating the patch itself. | 21:45 |
| didrocks | Pitti has created a script called "dsrc-new-patch" for automating this, and we will see later that other patch systems have something quite similar. | 21:45 |
| didrocks | $ cd ..; rm -r udev-*; dpkg-source -x udev_*.dsc; cd udev-* | 21:46 |
| didrocks | => First, let's clean our work and download again an untouched udev-* source tree. | 21:46 |
| didrocks | step 1 to 3 are completed in simply calling the script: | 21:46 |
| didrocks | $ ../dsrc-new-patch 90_happy_rms.patch | 21:46 |
| didrocks | => it drops you into a shell where you can edit the code and hack whatever you want | 21:46 |
| didrocks | $ sed -i 's#Linux#GNU/Linux#g' README | 21:47 |
| didrocks | (yeah, the same bad regexp again :)) | 21:47 |
| didrocks | => make all your modification and then, press <Control-D> or type "exit 0" to leave the subshell. | 21:47 |
| didrocks | then, step 5 & 6 are automatically completed. Nice, isn't it? You will have a debian/patches/90_happy_rms.patch which is exactly the same than the one you created before. | 21:47 |
| didrocks | Are both of you created successfully the patch? | 21:48 |
| didrocks | s/Are/does | 21:48 |
| Kurt | I got stuck at the $ ../dsrc-new-patch 90_happy_rms.patch part | 21:48 |
| chombium | yes | 21:48 |
| didrocks | Kurt: wrong paste, maybe? What is doing the script? | 21:49 |
| Kurt | $ ../dsrc-new-patch 90_happy_rms.patch | 21:49 |
| Kurt | oops | 21:49 |
| didrocks | so, when you execute it, you will see a new shell | 21:49 |
| didrocks | then, you perform your modifications | 21:49 |
| didrocks | and then "exit 0" or <control D> | 21:50 |
| didrocks | (to return to your previous shell) | 21:50 |
| didrocks | Kurt: don't hesitate to ask some more question if you still get stuck | 21:51 |
| didrocks | I think Kurt is lost in its subshell :) | 21:51 |
| Kurt | sorry, I didn't see the wget for the dsrc up there | 21:52 |
| Kurt | catching up now :) | 21:52 |
| didrocks | :) | 21:53 |
| didrocks | ok ! | 21:53 |
| didrocks | if you like the script, you can put it in your $PATH (~/bin is a good place for that). | 21:53 |
| didrocks | so, doing this by hand or automatically, always remember (as previously said) to apply the patch in the right order. | 21:53 |
| didrocks | dsrc-new-patch is a hack which mostly works for packages without a real patch system, but split-out patches | 21:53 |
| didrocks | but appart from this hack, some patch system has been invented so that hacker can be more concentrated on the code than the tools to generate the result of their work. That's the reason why they are used by 90% of the archive's sources packages. | 21:54 |
| didrocks | for the remaining one, you will have to complete the previous manual approach. | 21:54 |
| didrocks | if there is no more question (shout NOW!), let's look at the most popular ones now. | 21:54 |
| laga | didrocks: did you see my question in ubuntu-classroom-chat? | 21:54 |
| huats | laga: sure... | 21:55 |
| didrocks | the rocking huats is going to go on on the session to present you some rocking patch system | 21:55 |
| huats | he will answer there :) | 21:55 |
| huats | ok guys. | 21:55 |
| didrocks | yes :) | 21:55 |
| laga | yay | 21:55 |
| didrocks | <laga> QUESTION: not following the tutorial right now, but i wonder if you have a good way to mangle the patch level (ie file paths) in patches. that's often useful if you take patches from other sources | 21:55 |
| didrocks | laga: do you speak about the patch system? | 21:55 |
| didrocks | how to determine the patch system of a package? | 21:55 |
| huats | didrocks: switch to -chat :) | 21:56 |
| huats | First of all thanks didrocks ! That was great :) | 21:56 |
| didrocks | laga: ok, will continue on -chat :) | 21:56 |
| didrocks | thx huats ;) | 21:56 |
| huats | Right now we will focus on patching systems... | 21:56 |
| huats | of course the old way, that didrocks showed us are nice | 21:57 |
| huats | but you'll enjoy evoluates systems too ! | 21:57 |
| huats | first of all | 21:57 |
| huats | let's have a look at dpatch ! | 21:57 |
| huats | To do so, we'll use ed | 21:57 |
| huats | so if you have the sources | 21:58 |
| huats | cd ../ed-07 | 21:58 |
| huats | is it ok for everyone ? | 21:58 |
| huats | (well for both of you :)) | 21:58 |
| Kurt | yes for me | 21:58 |
| chombium | yes | 21:58 |
| huats | ok | 21:58 |
| huats | great | 21:58 |
| huats | A few words on dpatch, let me quote master pitti : | 21:58 |
| huats | "dpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch' packages which use this build-depend on 'dpatch', and debian/rules includes 'dpatch.mk' | 21:58 |
| huats | The two most important things you should be aware of: | 21:59 |
| huats | * 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. | 21:59 |
| huats | (forgetting to update 00list is a common cause of followup uploads :-) ) | 21:59 |
| huats | * 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." | 21:59 |
| nxvl | huats: slow down! | 21:59 |
| huats | nxvl: sure :) | 21:59 |
| huats | o/ nxvl | 21:59 |
| huats | dpatch comes with some interesting scripts to enables us to get info/manipulates patches. Their names are quite explanatory, by instance dpatch-list-patch will list you all existing patches in the packages. | 22:00 |
| huats | dpatch-list-patch | 22:00 |
| huats | if you type that in your current shell | 22:00 |
| huats | you'll have the whole list | 22:00 |
| huats | of patches, with their corresponding authors and descriptions | 22:01 |
| huats | But by far, you'll mostly use dpatch-edit-patch. This is the command that will enable you to create/modify a dpatch ! | 22:01 |
| huats | Let's start with editing a patch : | 22:01 |
| huats | type : | 22:01 |
| huats | dpatch-edit-patch 07_ed.1-spelling-fixes | 22:01 |
| huats | (note that 07_ed.1-spelling-fixes is a current existing patch) | 22:02 |
| huats | You are now in a new shell were the patch is already applied. You can edit the files you want. | 22:02 |
| huats | By instance: | 22:02 |
| huats | $ echo "UbuntuDevWeekAugust08" >> README | 22:02 |
| huats | Once you are OK with your results, just press Ctrl+D. | 22:03 |
| huats | Otherwise, if you are not happy with your changes, exit the shell with a non zero value, by instance exit 230. | 22:03 |
| huats | The patch will be untouched ! | 22:03 |
| huats | but in that case type exit 0 | 22:03 |
| huats | now simply look at the debian/patches/07_ed.1-spelling-fixes file | 22:03 |
| huats | at the end of the file you'll notice what e have added... | 22:04 |
| huats | is it ok for everyone ? | 22:04 |
| hggdh | cool | 22:04 |
| Kurt | yep | 22:04 |
| huats | ok | 22:04 |
| huats | chombium: too ? | 22:04 |
| chombium | yep | 22:05 |
| huats | ok great | 22:05 |
| huats | Now let's create a patch ! Here again we'll use dpatch-edit-patch. | 22:05 |
| huats | $ dpatch-edit-patch 08_developper_week_patch | 22:05 |
| huats | If you are not happy with your changes, exit the shell with a non zero value, by instance exit 230. | 22:05 |
| huats | The patch will not be created ! | 22:05 |
| huats | You are once again in a new shell. You can edit the files as you want. | 22:05 |
| huats | (it is the same process than for editing) | 22:06 |
| huats | once again | 22:06 |
| huats | do | 22:06 |
| huats | echo "UbuntuDevWeekAugust08-again" >> README | 22:06 |
| huats | and press Ctrl+D | 22:06 |
| huats | The patch has been created | 22:07 |
| huats | But so far it won't be applied automatically | 22:07 |
| huats | Does anybody can tell me why ? | 22:07 |
| hggdh | because of petential order conflict | 22:07 |
| cocooncrash | huats: It's not in 00list. | 22:07 |
| Kurt | it isn't in the 00list? | 22:07 |
| huats | hggdh: nope | 22:07 |
| huats | cocooncrash: and Kurt exactly | 22:08 |
| hggdh | what I meant isL it is not in 00list | 22:08 |
| hggdh | because of ... | 22:08 |
| huats | ok hggdh | 22:08 |
| huats | so it can be done with | 22:08 |
| huats | echo 08_developper_week_patch.dpatch >> debian/patches/00list | 22:08 |
| huats | Please have a look at the file debian/patches/08_developper_week_patch.dpatch | 22:08 |
| huats | Note that exacly like in the debian/changelog you need to put your name and email in the patch ! | 22:08 |
| huats | You also have to edit the description of the patch. It is the line that follows ## DP: | 22:08 |
| huats | So please do it. Having one of them missing is a very common cause for a sponsor to refuse your request ! | 22:08 |
| huats | Note that you can create your patch in relation with another patch. Simply add the patch you want to be applied before your on the command line. Like that: | 22:09 |
| huats | $ dpatch-edit-patch 08_developper_week_patch 07_ed.1-spelling-fixes | 22:09 |
| huats | 07_ed.1-spelling-fixes has not been chose randomly. The output of dpatch-list-patch has showed us that it was the last one to be applied. | 22:09 |
| huats | And indeed here notice that all patches are applied. How do I notice that ? | 22:10 |
| chombium | QUESTION: will the patches be sorted by the file name when adding in 00list? | 22:11 |
| huats | chombium: yes | 22:11 |
| didrocks | huats: not sure | 22:12 |
| huats | hum | 22:12 |
| huats | no | 22:12 |
| huats | they will be treated in the file order | 22:12 |
| didrocks | chombium: it's the file order | 22:12 |
| didrocks | :) | 22:12 |
| huats | sorry I missread | 22:12 |
| didrocks | just copy one question from -chat | 22:12 |
| didrocks | <laga> QUESTION: if i take a patch from another source and turn it into a dpatch, do i still need to put my name as the author? | 22:12 |
| didrocks | <huats> laga: you have too | 22:12 |
| didrocks | <huats> otherwise you'll have lintian warnings | 22:12 |
| didrocks | (for the log) | 22:12 |
| huats | hum | 22:13 |
| huats | once again I missread | 22:13 |
| huats | you have to put the author name | 22:13 |
| cocooncrash | QUESTION: Should you put your name or the original author? | 22:13 |
| huats | (not yours in that case) | 22:13 |
| didrocks | huats: yes, it's getting late, I know :) | 22:13 |
| huats | but put a name is needed... otherwise lintian will complain | 22:13 |
| nxvl | we love huats | 22:13 |
| * nxvl waves on huats | 22:14 | |
| huats | :) | 22:14 |
| huats | the answer of my question was that you'll notice : patch XXXX apply on | 22:14 |
| * didrocks is jalous :) | 22:14 | |
| huats | before getting the subshell | 22:14 |
| huats | That was pretty simple right ? | 22:14 |
| huats | any other questions with dpatch ? | 22:14 |
| huats | Oh one last word about dpatch. It is needed to modify the debian/rules file (for automatic patching and unpatching). But I won't demonstrate that now. If you want to see how to do that, have a look at the debian/rules file and search for patch :) | 22:15 |
| hggdh | QUESTION: new patch, new version number. How is it done under DPATCH? | 22:15 |
| huats | you have to choose the number | 22:15 |
| huats | yourself | 22:15 |
| huats | version number ? | 22:15 |
| hggdh | version.release.subversion etc. So no auto-increment? | 22:16 |
| cocooncrash | hggdh: Patches don't affect the package version number. That is determined by the changelog entry. | 22:16 |
| * nxvl waves on didrocks too | 22:16 | |
| huats | hggdh: cocooncrash has answered :) | 22:16 |
| hggdh | :-) | 22:16 |
| huats | hggdh: didrocks will explain that to you on -chat | 22:16 |
| didrocks | (nxvl: thanks, you rock :)) | 22:16 |
| huats | let's move | 22:17 |
| huats | since we already have lasted longer than supposed... | 22:17 |
| huats | == keepalived : cdbs with simple-patchsys == | 22:17 |
| huats | Let's move to cdbs. For this example we'll have a closer look at keepalived (once again pitti example). | 22:17 |
| huats | oups | 22:17 |
| huats | it was not pitti example | 22:17 |
| huats | :( | 22:17 |
| huats | it is getting way to late :) | 22:17 |
| huats | cd ../keepalived-1.1.15 | 22:17 |
| huats | First let's have a look at debian/rules. | 22:18 |
| huats | You'll notice that the only reference to the patching system include simple-patchsys.mk | 22:18 |
| huats | Pretty magic :) | 22:18 |
| huats | pitti has the good idea to write a script called 'cdbs-edit-patch' that works closely like dpatch-edit-patch. | 22:18 |
| huats | This script is contained in the normal cdbs package. | 22:18 |
| huats | 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. | 22:18 |
| huats | Let's add a new patch ! | 22:18 |
| huats | $ cdbs-edit-patch 05-simple-readme.patch | 22:18 |
| huats | $ echo 'This should document keepalived' > UbuntuDevWeek.README | 22:18 |
| huats | <press Control-D to leave the subshell> | 22:19 |
| huats | Here again if you are not happy with your changes, just type exit 230 in the subshell. | 22:19 |
| huats | The edition of an existing patch work exactly the same way... | 22:19 |
| huats | Questions ? | 22:19 |
| huats | (I won't be long here since it is pretty the same thing than dpatch-edit-patch) | 22:20 |
| cocooncrash | QUESTION: Are the patches still stored in debian/patches? | 22:20 |
| huats | cocooncrash: it is the debian policy yes | 22:20 |
| cocooncrash | QUESTION: Is 00list is used, or are all patches applied? | 22:20 |
| huats | 00list is for dpatch | 22:20 |
| huats | and only patch in it will be applied | 22:21 |
| huats | Is it ok for everyone ? | 22:21 |
| chombium | yep | 22:21 |
| huats | If so, I am moving on :) | 22:21 |
| huats | == xterm: quilt == | 22:22 |
| huats | The last patch system that we will detail is quilt. We will study it on xterm. | 22:22 |
| huats | It is non-trivial to set up and has a lot of advanced commands which make it very flexible, but not very easy to use. | 22:22 |
| huats | $ cd ../xterm-229 | 22:22 |
| huats | Like dpatch, it has a list of patches to apply in patches/series (to use debian/patches, packages need to add a sylink) or set $QUILT_PATCHES to debian/patches | 22:22 |
| huats | it is needed to respect the debian policy for patches... and thus to satisfy your question cocooncrash | 22:23 |
| huats | Let's have a look at debian/rules. You'll notice the line that does the trick : | 22:23 |
| huats | QUILT_PATCHES = patches/ | 22:23 |
| huats | So to work right now, let's export that right now (since we won't use debian/rules tonight) | 22:23 |
| huats | $ export QUILT_PATCHES=debian/patches | 22:23 |
| huats | Unlike 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 tree a bit like version control (svn, bzr, etc.). | 22:24 |
| huats | Now let's edit the already existing patch 901_xterm_manpage.diff: | 22:24 |
| huats | $ quilt push 901_xterm_manpage.diff | 22:24 |
| huats | This will apply all patches (inline remember) in the stack up to the given one. | 22:24 |
| huats | Now let's edit a file that is already touched by the original patch | 22:25 |
| huats | $ sed -i 's/Copyright/Copyleft/' xterm.man | 22:25 |
| huats | Let's commit the change: | 22:25 |
| huats | First updates the patch file with your recent changes | 22:25 |
| huats | $ quilt refresh 901_xterm_manpage.diff | 22:25 |
| huats | Than unapplies all patches to go back to pristine source tree | 22:25 |
| huats | $ quilt pop -a | 22:25 |
| huats | Ok, I'll stop a bit :) | 22:25 |
| huats | to let you do that :) | 22:25 |
| huats | Ping once you have finished to do that :) | 22:26 |
| didrocks | (sorry, just one this, it's quilt push -a 901_xterm_manpage.diff) | 22:26 |
| huats | oups sorry..... | 22:26 |
| didrocks | to be push every patch file depending on 901_… | 22:26 |
| huats | thanks didrocks | 22:26 |
| didrocks | well, everytime, and especially for quilt, look at the man before executing anything you are not quite sure :) | 22:27 |
| huats | So have you done it ? | 22:27 |
| Kurt | yes | 22:27 |
| huats | Look at debian/patches/901_xterm_manpage.diff to see the effect :) | 22:27 |
| huats | Does anyone can point it to me ? | 22:27 |
| huats | anyone ? | 22:28 |
| Kurt | copyrights switched to copylefts | 22:28 |
| huats | Kurt: thanks ! | 22:28 |
| huats | :) | 22:28 |
| huats | indeed :) | 22:28 |
| huats | it means that the patch has been modified ! | 22:29 |
| huats | Finally to end our patching tour : let's create our own patch | 22:29 |
| huats | $ quilt push -a | 22:29 |
| huats | This will apply all the patches (-a for all) | 22:29 |
| huats | $ quilt new UbuntuDevWeekAugust08.diff | 22:29 |
| huats | This is the creation of the patch ! | 22:29 |
| huats | $ quilt add README | 22:30 |
| huats | It is needed to tell quilt all the files that you want to be incoporated in your patch (likewise version control stuffs). | 22:30 |
| huats | $ echo "UbuntuDevWeekAugust08" >> README | 22:30 |
| huats | Some modification. | 22:30 |
| huats | $ quilt refresh | 22:30 |
| huats | Update the currently edited patch | 22:30 |
| huats | $ quilt pop -a | 22:30 |
| huats | This will finally create debian/patches/UbuntuDevWeekAugust08.diff with the changes to README | 22:30 |
| huats | And that it is :) | 22:31 |
| huats | Does anybody can tell me what we need to check ? | 22:31 |
| huats | to be sure that the patch is applied ? | 22:31 |
| huats | (hint: it is a bit like dpatch :)) | 22:31 |
| hggdh | :debian/patches/series? | 22:31 |
| huats | hggdh: exactly | 22:31 |
| hggdh | but this time it is already added in | 22:32 |
| huats | exactly | 22:32 |
| didrocks | hggdh: yeah, quilt rocks \o/ | 22:32 |
| huats | You don't edit it manually usually. | 22:32 |
| huats | That is pretty it guys ! | 22:32 |
| huats | Questions ? | 22:32 |
| Kurt | thanks for the session huats and didrocks :) It was great | 22:33 |
| hggdh | thank you | 22:33 |
| huats | Kurt: thanks to you guys | 22:33 |
| didrocks | Always remember that there is the ubuntu wiki for more details: https://wiki.ubuntu.com/PackagingGuide/PatchSystems | 22:33 |
| huats | if you have any questions please ping us on IRC :) | 22:33 |
| huats | or ping master pitti :) | 22:33 |
| didrocks | thanks Kurt & hggdh gor having followed until the end :) | 22:33 |
| didrocks | of ping nxvl, he really loves questions :) | 22:34 |
| didrocks | s/of/or | 22:34 |
| huats | thanks a lot guys | 22:34 |
| nxvl | and if pitti tells you he doesn't know, ask anyway, he knows | 22:34 |
| nxvl | that's why we love pitti | 22:34 |
| didrocks | nxvl: \o/ | 22:34 |
| huats | bye bye everyone ! | 22:34 |
| didrocks | thanks a lot to everyone! Bye! | 22:34 |
| chombium | thanks a log guys | 22:34 |
| chombium | \o/ | 22:35 |
| didrocks | thanks chombium \o/ | 22:35 |
| arkara | Hi | 23:20 |
| arkara | can anyone mentor me on packaging? | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!