| === baggio is now known as DannyBoy | ||
| === DannyBoy is now known as Daniel | ||
| Daniel | Any MOTU available for chat? | 01:48 |
|---|---|---|
| Daniel | I'm still here | 01:58 |
| Daniel | Any MOTU available for chat? | 01:58 |
| nalioth | Daniel: have you looked in #ubuntu-motu ? | 02:07 |
| === 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 | ||
| warp10 | Hi all! | 11:46 |
| === Ketzal_out is now known as Ketzal | ||
| * popey hugs dholbach | 14:13 | |
| dholbach | hey popey | 14:14 |
| * dholbach hugs popey back :) | 14:14 | |
| === dholbach_ is now known as dholbach | ||
| KEBA | damn i want that it is 16:00 :P | 14:41 |
| dholbach | so everybody's excited already? :-) | 14:42 |
| tuxmaniac | dholbach, the excitement seems to be not there currently ;-) | 14:45 |
| dholbach | tuxmaniac: patience - wait another 75 minutes ;-)) | 14:45 |
| * tuxmaniac goes for dinner in the meantime | 14:46 | |
| quite | boink. UTC. | 14:47 |
| dholbach | hey jono - excited about UDW? :) | 15:34 |
| jono | dholbach: wooo! :) | 15:37 |
| dholbach | :-) | 15:38 |
| flicck | 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:39 | |
| dholbach | flicck: absolutely not - it's definitely worthwhile lurking in the other sessions | 15:40 |
| flicck | thank you for the welcome, will do | 15:40 |
| danbhfive | is packaging 101 coming up? | 15:45 |
| dholbach | danbhfive: it's 15:46 UTC - the schedule is up at https://wiki.ubuntu.com/UbuntuDeveloperWeek | 15:46 |
| danbhfive | kk, thanks dholbach | 15:46 |
| dholbach | date -u is your friend :-) | 15:46 |
| emgent | hello people | 15:47 |
| fftb | hi, patching packages is here? | 15:50 |
| * pitti waves | 15:51 | |
| dholbach | fftb: yes, in 9 minutes | 15:51 |
| fftb | great thx | 15:51 |
| dholbach | WELCOME EVERYBODY! | 15:51 |
| dholbach | This is the first ever Ubuntu Developer Week and I hope you're all very excited | 15:51 |
| dholbach | because I am :-) | 15:51 |
| emgent | :) | 15:51 |
| dholbach | The schedule is up at https://wiki.ubuntu.com/UbuntuDeveloperWeek | 15:51 |
| dholbach | and the rules are up athttps://wiki.ubuntu.com/UbuntuDeveloperWeek/Rules | 15:51 |
| jetsaredim | are there going to be transcripts of these sessions for people who can't make it? | 15:52 |
| dholbach | basically: please keep all chatter out of this channel, ask questions in #ubuntu-classroom-chat instead | 15:52 |
| dholbach | and make sure you prefix them with QUESTION: ... | 15:52 |
| dholbach | so they're easier to spot | 15:52 |
| dholbach | jetsaredim: yes, there are links on the schedule page already and they will be filled up with the logs afterwards | 15:52 |
| dholbach | are there any other questions before we start? | 15:53 |
| jetsaredim | dholbach: ok - sorry must've missed that | 15:53 |
| pitti | also, most of the topics should already have documentation in the wiki | 15:53 |
| dholbach | jetsaredim: no problem | 15:53 |
| dholbach | the first speaker is Martin Pitt, also known as pitti | 15:54 |
| * pitti bows | 15:54 | |
| dholbach | 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:54 |
| dholbach | 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 |
| pitti | so, who is actually here for the patching packages hands-on training session? | 15:55 |
| dholbach | be gentle with pitti, we still need him :) | 15:55 |
| pitti | heh | 15:56 |
| * jetsaredim is here to soak up as much as possible | 15:56 | |
| pitti | 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 | |
| amachu | hands on training session? | 15:56 |
| pitti | sessions start on the hour, for a little less than an hour | 15:56 |
| pitti | amachu: yes; a theoretical speech about patching wouldn't be very useful, I guess | 15:57 |
| pitti | then you can as well just RTFM :) | 15:57 |
| amachu | pitti: should help | 15:57 |
| * TuxCrafter is back in 10 min | 15:58 | |
| agoliveira | Wow... lot's of people here. Congrats dholbach! | 15:58 |
| jono | don't forget people - you can start your MOTU adventure at https://wiki.ubuntu.com/MOTU/GettingStarted | 15:58 |
| dholbach | agoliveira: yeah, everybody's excited :) | 15:58 |
| dholbach | good point, Mr. Bacon :) | 15:58 |
| * dholbach hugs jono | 15:59 | |
| agoliveira | jono: I'm still waiting for the movie :) | 15:59 |
| jono | 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 | |
| dholbach | enjoy the show! | 15:59 |
| pitti | let's start | 15:59 |
| * agoliveira gves a apple to pitti | 16:00 | |
| agoliveira | an apple | 16:00 |
| pitti | Welcome to the hands-on training session about how to patch Ubuntu source packages! | 16:00 |
| pitti | 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 |
| pitti | and want to learn how to put them into packages properly, to get them into Ubuntu | 16:00 |
| pitti | so, can you please quickly raise your hands if you are participating? | 16:00 |
| * agoliveira here | 16:00 | |
| anoath | raise | 16:01 |
| pitti | just to see how big the audience is | 16:01 |
| * jetsaredim here | 16:01 | |
| chrome___ | raise | 16:01 |
| * andy101 raises hand | 16:01 | |
| amachu | yep | 16:01 |
| * bfallik raises his | 16:01 | |
| huats | \o/ | 16:01 |
| snhome | raises hand | 16:01 |
| bananaramax | pong | 16:01 |
| pitti | great | 16:01 |
| KaiserClaudius | here | 16:01 |
| heikki | o/ | 16:01 |
| sommer | yo | 16:01 |
| pitti | wow | 16:01 |
| gkulyk | here | 16:01 |
| * Picklesworth raises his hand :) | 16:01 | |
| Lantash | yeü | 16:01 |
| wousser | yes | 16:01 |
| * pitti is impressed | 16:01 | |
| bdgraue | · | 16:01 |
| InsClusoe | / raises | 16:01 |
| fftb | here | 16:01 |
| arturodr | hi | 16:01 |
| pitti | 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 |
| fredre | here | 16:01 |
| * tseliot raises his hand | 16:01 | |
| * TrXuk here | 16:01 | |
| toert | hand | 16:01 |
| * emgent here | 16:01 | |
| pitti | OTOH, if you have deeper technical questsions, please ask in #-chat | 16:02 |
| pitti | 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 | |
| pitti | Let's begin with a little bit of history: | 16:02 |
| pitti | == Why use separate patches == | 16:02 |
| dholbach | yes, please take your questions to #ubuntu-classroom-chat and prefix them with QUESTION: | 16:02 |
| pitti | == Why use separate patches == | 16:02 |
| pitti | 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:02 |
| pitti | 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 |
| pitti | 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 <sourcepackage>.diff.gz only contains debian/. | 16:03 |
| pitti | 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:03 |
| pitti | Thus several standard patch systems were created which are easy to deploy and provide tools for patch juggling and editing. | 16:04 |
| pitti | --- | 16:04 |
| pitti | 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:04 |
| pitti | 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 |
| pitti | is everyone fine with this approach? | 16:05 |
| pitti | any questsions so far? | 16:05 |
| === Square is now known as Squares | ||
| pitti | If you want to try the stuff yourself, please do the following commands (on gutsy) as preparation: | 16:06 |
| pitti | sudo apt-get install dpatch cdbs quilt patchutils devscripts | 16:06 |
| pitti | ^ common build tools | 16:06 |
| pitti | apt-get source cron udev pmount ed xterm | 16:06 |
| pitti | ^ the example source packages I'll be explaining | 16:06 |
| pitti | wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch | 16:06 |
| pitti | (I'll talk about this later) | 16:06 |
| pitti | chmod 755 dsrc-new-patch | 16:06 |
| pitti | (make my script executable) | 16:06 |
| pitti | I deliberately picked the smallest packages I could find | 16:06 |
| * pitti waits a bit for people to do the preparations; any questions so far? | 16:07 | |
| anoath | nope | 16:07 |
| snhome | too fast | 16:07 |
| ubuntu_learner | I posted question on ubuntu-classroom-chat on previous Q. | 16:08 |
| Kaasethu | ^ common build tools | 16:08 |
| pitti | ubuntu_learner: I answered it there, did you see it? | 16:08 |
| amachu | Kaasethu: are those that pitti asked to install | 16:09 |
| pitti | ah, the ^ means "explanation for the previous line" | 16:09 |
| pitti | like an upwards arrow (sorry if that was unclear) | 16:09 |
| Kaasethu | thanks - | 16:09 |
| Kaasethu | now got it (I think) | 16:09 |
| pitti | so, I think most people should have downloaded the lot now? | 16:10 |
| pitti | == cron: inline patches == | 16:10 |
| pitti | 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 |
| pitti | if you do 'lsdiff -z <package>.diff.gz' and you see changes which are not in debian/, then you probably have such a package | 16:10 |
| pitti | i. e. that's a good counterexample for what we want to achieve with patch systems | 16:11 |
| pitti | 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 |
| pitti | (some KDE packages have autoconf stuff directly in the diff.gz, but that is ok) | 16:11 |
| pitti | so, I think I do not need to say anything else about cron, unless someone has a question | 16:11 |
| pitti | just look at the diff.gz to see how packaging and code changes are wildly mixed | 16:12 |
| pitti | == udev: separate patches, but no standard patch system == | 16:13 |
| pitti | if you look at udev's diff.gz, you see that it only has debian/, and split-out patches in debian/patches | 16:14 |
| pitti | one per logical change | 16:14 |
| pitti | 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 |
| pitti | 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:14 |
| pitti | 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 |
| pitti | 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 |
| pitti | 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:15 |
| * agoliveira rekons udev is evil | 16:16 | |
| pitti | The general approach which all patch systems follow, and which you can always do yourself, is: | 16:16 |
| pitti | agoliveira: for various reasons :-P | 16:16 |
| pitti | 1. copy the clean source tree to a temporary directory /tmp/old | 16:16 |
| agoliveira | pitti: Bingo! | 16:16 |
| pitti | 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:16 |
| pitti | 3. copy the whole source tree again: cp -a /tmp/old /tmp/new | 16:17 |
| pitti | 4. go into /tmp/new, do your modifications | 16:17 |
| pitti | 5. go back into /tmp and generate the patch with | 16:17 |
| pitti | diff -Nurp old new > mypatchname.patch | 16:17 |
| pitti | 6. move the newly generated patch to <original source dir>/debian/patches/mypatchname.patch | 16:17 |
| pitti | don't worry, I'll do an example | 16:18 |
| pitti | that's just the general recipe for printing out and hang over your bed/PC/whereever you need it :) | 16:18 |
| pitti | in general we want the following diff options: | 16:18 |
| pitti | -N -> include new files | 16:18 |
| pitti | (which is quite common) | 16:18 |
| pitti | -u -> unified patches (context diffs are ugly) | 16:18 |
| pitti | -r -> recursive | 16:19 |
| pitti | -p -> bonus, you can see the name of the affected function in the patch | 16:19 |
| pitti | does anyone have a question about the principle method? | 16:19 |
| pitti | ok, some hands-on example | 16:20 |
| pitti | open a shell, ready your fingers :) | 16:20 |
| pitti | udev example 1, let's create a new patch 92_penguins.patch: | 16:20 |
| pitti | cd /whereever/you/unpacked/the/source/udev-* # -113 on gutsy, -117 on hardy | 16:20 |
| pitti | -> now we are in our original source tree where we want to add a new patch | 16:21 |
| pitti | cp -a . /tmp/old | 16:21 |
| pitti | -> create a copy of the clean sources as reference tree | 16:21 |
| pitti | pushd /tmp/old | 16:21 |
| pitti | -> go to /tmp/old; 'pushd' to remember the previous directory, so that we can go back conveniently | 16:21 |
| pitti | debian/rules patch | 16:22 |
| pitti | -> apply all already existing patches; of course we could use the 'patch' program to do it manually, but since debian/rules already knows how to do it, let's use it. The actual name for the patch target varies, I have seen the following ones so far: patch, setup, apply-patches, unpack, patch-stamp. You have to look in debian/rules how it is called. | 16:22 |
| pitti | (I have a silly script which just attempts all of those until one succeeds :) ) | 16:22 |
| pitti | cp -a . /tmp/new; cd ../new | 16:22 |
| pitti | -> copies our patched reference tree to our new work directory /tmp/new where we can hack in | 16:23 |
| snhome | got an error with the first patch command | 16:23 |
| pitti | oh? | 16:23 |
| pitti | (darn, I tested them two hours ago on hardy) | 16:23 |
| pitti | snhome: you mean with debian/rules patch? | 16:23 |
| snhome | yes | 16:23 |
| pitti | (see -chat) | 16:24 |
| pitti | let's do a braindead modification now | 16:24 |
| pitti | sed -i 's/Linux/Penguin/g' README | 16:24 |
| pitti | -> changes the README file; of course you can use your favourite editor, but I wanted to keep my examples copy&pasteable | 16:24 |
| pitti | and now we create a patch between the reference and our new tree: | 16:24 |
| pitti | (btw, please cry out in -chat when I'm too fast) | 16:25 |
| pitti | cd .. | 16:25 |
| pitti | -> go back to /tmp, i. e. where our reference tree (old) and hacked tree (new) is located | 16:25 |
| pitti | diff -Nurp old new > 95_penguins.patch | 16:25 |
| pitti | -> generate the patch (Ignore the 'recursive directory loop' warnings) | 16:25 |
| pitti | oops | 16:26 |
| pitti | sorry, you need "apt-get install debhelper" if you get errors about dh_testdir | 16:26 |
| * pitti fixes his notes and gives you guys time to catch up | 16:27 | |
| pitti | mv /tmp/95_penguins.patch debian/patches | 16:28 |
| pitti | -> move the patch from /tmp to the source tree's patch directory, where it belongs. | 16:28 |
| pitti | *uff* :) | 16:28 |
| pitti | Now take a look at your shiny new debian/patches/95_penguins.patch. | 16:28 |
| snhome | error on the mv | 16:30 |
| ozanichkovsky | pushd | 16:30 |
| jetsaredim | you need to cd back to the udev_xxx dir | 16:30 |
| pitti | oops, sorry | 16:30 |
| pitti | you have to do "popd" before the mv | 16:30 |
| * pitti wishes there was an "erase previous line" IRC command | 16:31 | |
| pitti | so, it's "diff", "popd", "mv" | 16:32 |
| pitti | please make a noise when you are ready | 16:32 |
| jsauer | ready | 16:32 |
| fftb | noise | 16:32 |
| ozanichkovsky | ready | 16:33 |
| Lantas2 | ready | 16:33 |
| KaiserClaudius | ready | 16:33 |
| Picklesworth | peep | 16:33 |
| arturodr | ready | 16:33 |
| chrome___ | ready | 16:33 |
| pitti | awesome | 16:33 |
| fredre | ready | 16:33 |
| pitti | debian/patches/95_penguins.patch looks plausible? | 16:33 |
| pitti | 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:33 |
| pitti | if you don't have debclean, install devscripts, or do "fakeroot debian/rules clean" instead | 16:34 |
| pitti | it calls the 'clean' target, which means, clean up all built files, unapply patches, etc. | 16:35 |
| nareshov | fakeroot worked for me | 16:35 |
| pitti | if it complains about missing build dependencies, use the fakeroot command | 16:35 |
| pitti | 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 |
| pitti | so this procedure is the life safer if anything else fails | 16:36 |
| 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:37 |
| Don-1 | 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 |
| Don-1 | dh_testdir | 16:40 |
| Don-1 | make: dh_testdir: Command not found | 16:40 |
| Don-1 | make: *** [patch-stamp] Error 127 | 16:40 |
| Don-1 | 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 |
| nareshov | Need devscripts ? | 16:40 |
| dholbach | Don-1: please ask questions in #ubuntu-classroom-chat | 16:40 |
| Don-1 | Sorry. | 16:40 |
| Assid | hi | 16:40 |
| dholbach | pitti: you fell of the internet? | 16:42 |
| dholbach | minus the missing packages - how did the session go? everything seemed sensible? | 16:42 |
| snhome | I'm new at this so will need to study what we did | 16:43 |
| dholbach | maybe we can do some general Q&A while pitti recovers from whatever problem he has right now | 16:43 |
| ubuntu_learner_ | Here or at -chat? | 16:43 |
| === livewire1 is now known as livewire | ||
| dholbach | http://wiki.ubuntu.com/PackagingGuide/PatchSystems is a guide to patch systems | 16:43 |
| dholbach | just ask in #-chat and I'll carry over the questions | 16:43 |
| dholbach | <jetsaredim> so, once we patch the package, what then? | 16:44 |
| dholbach | good question | 16:44 |
| nareshov | :) | 16:44 |
| dholbach | in most cases as an Ubuntu developer you work on existing packages | 16:44 |
| pitti | argh, sorry; my interweb tube broke | 16:44 |
| pitti | what's the last line you saw from me? | 16:44 |
| nareshov | 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 |
| pitti | ugh | 16:44 |
| pitti | ok, I'll go on there | 16:45 |
| dholbach | let me just reply to jetsaredim | 16:45 |
| agoliveira | pitti: it was: "arrrghhhh....." | 16:45 |
| fftb | :) | 16:45 |
| dholbach | 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 |
| pitti | Using dsrc-new-patch, above steps would reduce to: | 16:45 |
| pitti | ../dsrc-new-patch 95_penguins.patch | 16:46 |
| pitti | (.., or wherever you downloaded the script) | 16:46 |
| jetsaredim | dholbach: what about changing the package version, etc how does that get determined | 16:46 |
| pitti | sed -i 's/Linux/Penguin/g' README | 16:46 |
| pitti | <press Control-D to leave the subshell> | 16:46 |
| pitti | 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 |
| dholbach | jetsaredim: I'll cover that in a different session :) | 16:46 |
| jetsaredim | ah | 16:46 |
| * jetsaredim returns to lurking | 16:46 | |
| pitti | but I had to torture you with the close-to-the-metal method for the sake of understanding. | 16:47 |
| pitti | You might have noticed that we applied all previous patches before creating our's. Does someone have an idea why this is done? | 16:47 |
| jetsaredim | numbering | 16:48 |
| nareshov | the patches have numbers? | 16:48 |
| pitti | well, it's related to that, yes | 16:48 |
| nareshov | sequential, dependant ? | 16:48 |
| * chrome___ thinks that the patches might depend on each other | 16:48 | |
| awalton__ | asserting patch interdependencies. | 16:48 |
| bananaramax | <pitti> 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 |
| pitti | Patches can depend on each other, | 16:48 |
| pitti | 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 |
| pitti | 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 |
| pitti | Since above procedure is so hideously complicated, patch systems were invented to aid you with that. | 16:49 |
| pitti | 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:50 |
| pitti | == pmount: cdbs with simple-patchsys == | 16:51 |
| pitti | 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 |
| pitti | Many Ubuntu packages use the cdbs build system; you can look at the "Build-Depends:" line in debian/control (it has cdbs) to check | 16:51 |
| === Heres is now known as Her0 | ||
| pitti | or look in debian/rules whether it has includes for /usr/share/cdbs | 16:52 |
| pitti | if you have that, then you can use the following script | 16:52 |
| pitti | 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:52 |
| pitti | everyone please look in debian/patches, debian/rules to get a feeling how it looks like | 16:53 |
| pitti | so, let's mess up pmount a bit | 16:53 |
| pitti | and add a new patch | 16:53 |
| pitti | cd /whereever/you/unpacked/the/source/pmount-0.9.16 | 16:53 |
| pitti | cdbs-edit-patch 07-simple-readme.patch | 16:53 |
| pitti | (drops you into a subshell for editing again, similar to dsrc-new-patch) | 16:53 |
| pitti | echo 'This should document pmount' > README | 16:53 |
| pitti | (some braindead modification) | 16:53 |
| pitti | <press Control-D to leave the subshell> | 16:53 |
| pitti | easy, isn't it? | 16:54 |
| pitti | 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 |
| pitti | Editing an already existing patch works exactly the same way. | 16:54 |
| pitti | so I won't give a demo | 16:54 |
| pitti | questions? | 16:55 |
| pitti | 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:55 |
| pitti | == ed: dpatch == | 16:56 |
| pitti | dpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch' | 16:56 |
| pitti | packages which use this build-depend on 'dpatch', and debian/rules includes 'dpatch.mk' | 16:56 |
| pitti | that script dpatch-edit-patch is actually pretty similar to the other two scripts I talked about | 16:57 |
| pitti | The two most important things you should be aware of: | 16:57 |
| pitti | * dpatch does not apply debian/patches/*, but instead applies all patches mentioned in debian/patches/00list, in the mentioned order. That means that you do not have to rely on asciibetical ordering of the patches and can easily disable patches, but you have to make sure to not forget to update 00list if you add a new patch. | 16:57 |
| pitti | (forgetting to update 00list is a common cause of followup uploads :-P ) | 16:57 |
| pitti | * dpatch patches are actually scripts that are executed, not just patches fed to 'patch'. That means you can also do fancy things like calling autoconf or using sed in a dpatch if you want. | 16:58 |
| pitti | 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 |
| pitti | but I think it's important to mention it | 16:58 |
| pitti | The manpage is very good and has examples, too | 16:58 |
| pitti | There is a wiki page https://wiki.ubuntu.com/MOTU/School/PatchingSources which has examples for the most common patch systems | 16:59 |
| pitti | and how to use them | 16:59 |
| pitti | it's a good cheatsheet when you will actually get to this | 16:59 |
| dholbach | pitti: http://wiki.ubuntu.com/PackagingGuide/PatchSystems :) | 16:59 |
| pitti | but with above tools you should be able to change the vast majority of packages | 16:59 |
| pitti | thanks for your attention! | 16:59 |
| pitti | BTW, I'll do the same session on Friday again | 17:00 |
| pitti | and hopefully catch up with the other stuff | 17:00 |
| amachu | :-) | 17:00 |
| zeeth | pitti: thank-you | 17:00 |
| arturodr | thanks pitti | 17:00 |
| chrome___ | thanks pitti | 17:00 |
| Picklesworth | Nice, pitti! Very helpful :) | 17:01 |
| jsauer | thanks pitti | 17:01 |
| fredre | than you | 17:01 |
| Picklesworth | That's one more directory starting to make sense... | 17:01 |
| dholbach | thanks a lot pitti | 17:01 |
| Lantas2 | thanks! | 17:01 |
| dholbach | 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 |
| KaiserClaudius | thanks alot | 17:01 |
| Don-1 | Thank you! | 17:01 |
| vicantre | thanks mate! It was truly helpful | 17:02 |
| dholbach | Celso and Matthew: the stage is yours | 17:02 |
| cprov | Hi all, Welcome to the Personal Package Archive (PPA) session. | 17:02 |
| dholbach | for those of you who have joined in later: please ask questions in #ubuntu-classroom-chat and prefix them with QUESTION: ... | 17:02 |
| cprov | Just for curiosity, say "me" if you are attending the PPA session. | 17:02 |
| mrevell | me | 17:02 |
| * jetsaredim me | 17:02 | |
| dholbach | me too | 17:03 |
| soneil | me | 17:03 |
| rulus | me | 17:03 |
| * tamrat me | 17:03 | |
| ubuntu_learner_ | me | 17:03 |
| awalton__ | +1 | 17:03 |
| arturodr | me | 17:03 |
| fredre | me | 17:03 |
| InsClusoe | me | 17:03 |
| jsauer | me | 17:03 |
| Don-1 | me - half of the session. | 17:03 |
| Picklesworth | me | 17:03 |
| corevette | me | 17:03 |
| holloway | me | 17:03 |
| zeeth | me | 17:03 |
| * nareshov too | 17:03 | |
| barcc | me | 17:03 |
| vicantre | me | 17:03 |
| tvelocity | me | 17:03 |
| Grazieno | me | 17:03 |
| pwnedd | me | 17:03 |
| dholbach | rock on Launchpadders! | 17:03 |
| acacs | me | 17:03 |
| snhome | me listening | 17:03 |
| cprov | wow, lot of people here | 17:03 |
| mrevell | This is great, thanks for coming everyone :) | 17:04 |
| amachu | me | 17:04 |
| cap10morgan | me | 17:04 |
| Sciri | me lurking ;) | 17:04 |
| cprov | so, as daniel said, make question on #-chat and before anything else thanks for coming. | 17:04 |
| cprov | So, first obvious question is "What is this PPA thing ?" | 17:05 |
| cprov | Launchpad provides the infrastructure to process, build and publish uploads for ubuntu primary archive. | 17:05 |
| cprov | the same set of sub-systems is available for all users via Personal Package Archives (PPA) in their own restricted archive. | 17:06 |
| === Martinp24 is now known as Martinp23 | ||
| cprov | i.e., it's possible to have a Martin Pitti archive or a Mozilla Development Archive. | 17:07 |
| cprov | does it sound like a good definition for you all ? | 17:07 |
| cprov | please say '+1' if it's fine or add your comment. | 17:08 |
| Don-1 | +1 | 17:08 |
| tamrat | +1 | 17:08 |
| cprov | 5 | 17:08 |
| cap10morgan | +1 | 17:08 |
| nareshov | +1 | 17:08 |
| arturodr | +1 | 17:08 |
| cprov | 4 | 17:08 |
| chrome___ | +1 | 17:08 |
| TuxCrafter | i have to go now | 17:08 |
| dargol | + | 17:08 |
| tvelocity | +1 | 17:08 |
| icicle | +1 | 17:08 |
| cprov | 3 | 17:08 |
| TuxCrafter | thanks for everything | 17:08 |
| dargol | +1 | 17:08 |
| jsauer | +1 | 17:08 |
| InsClusoe | +1 | 17:08 |
| cprov | 2 | 17:08 |
| p3n9 | +1 | 17:08 |
| fredre | +1 | 17:08 |
| cprov | 1 | 17:08 |
| TuxCrafter | +1 | 17:08 |
| corevette | +1 | 17:08 |
| Lantash | +1 | 17:08 |
| Grazieno | +1 | 17:08 |
| awalton__ | +1 | 17:08 |
| cprov | happy users :) | 17:09 |
| danbhfive | +1 | 17:09 |
| pwnedd | +1 | 17:09 |
| cprov | In order to use PPA we require a valid user/team in Launchpad | 17:09 |
| lengau | +1 | 17:09 |
| cprov | and a quick 'activation' procedure. | 17:09 |
| cprov | https://help.launchpad.net/PPAQuickStart/ describes the procedure in details. | 17:10 |
| cprov | you have to accept the PPA terms of use (ToU) which basically assures we are not giving you space to do illegal actions | 17:11 |
| cprov | so, it's up to the users to certify that they are coping with the restrictions imposed the source license in question. | 17:12 |
| cprov | Legal issues should be reported to a launchpad administrator and the culprit PPA will be disabled immediately. | 17:13 |
| cprov | ok, enough legal statements for today. | 17:13 |
| cprov | let's go for the hand-on training. | 17:13 |
| cprov | PPA, as you would expect, requires users to dominate the current development tools (used in ubuntu, debian and other debian-like distribution) | 17:14 |
| cprov | Let's assume that all users here are aware of https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html for packaging issues | 17:15 |
| cprov | and have a package source ready to be uploaded. | 17:16 |
| cprov | The first question is "how to build the source package for my PPA ?" | 17:16 |
| cprov | if you are using orig.tar.gz, ensure you are using the same file already uploaded in ubuntu primary archive. | 17:17 |
| cprov | This is a very good way to save bandwidth for you uploads. You don't have to re-upload orig files already published in ubuntu | 17:18 |
| cprov | so, you upload will be small and quick | 17:18 |
| cprov | `debuild -S` will do | 17:18 |
| cprov | if it's a new source, you do have to upload the orig (`debuild -S -sa`), although, you have to do it only for the first version of the source | 17:19 |
| cprov | subsequent upload can omit the orig, PPA system will retrieve it from the context archive. | 17:19 |
| cprov | all clear, guys ? you are too quiet | 17:20 |
| snhome | listening | 17:20 |
| cprov | Am I going to fast ? | 17:20 |
| holloway | it's confusing for the first time | 17:20 |
| Unksi | go on :) | 17:20 |
| tacone | speed is ok for me :) | 17:20 |
| zeeth | comfortable sir | 17:20 |
| dargol | go on | 17:20 |
| snhome | & girls :) | 17:20 |
| cprov | great, feel free to stop anytime with questions | 17:20 |
| dholbach | cprov: there were a bunch of questions on #-chat :) | 17:21 |
| cprov | err, I was expecting the bot to ask them here ... How should I proceed ? | 17:22 |
| cprov | dholbach: shall I paste the question here and answer it . | 17:22 |
| dholbach | cprov: good idea | 17:22 |
| dholbach | that way they end up in the log too | 17:23 |
| cprov | QUESTION: Is PPA specific to ubuntu or for any project hosted on launchpad.net | 17:23 |
| cprov | well, PPA can only host packages for ubuntu distribution, atm | 17:23 |
| cprov | however, any person, team can host specific packages for any project hosted or not in Launchpad | 17:24 |
| cprov | uhm, confusing answer ... IFW, project and PPAs are not exactly related. | 17:24 |
| cprov | does it answer your question ? | 17:25 |
| zeeth | how about for debian? | 17:25 |
| eddyMul | or ubuntu derivatives? | 17:25 |
| cprov | zeeth: you can cross-install ubuntu package in debian systems | 17:26 |
| zeeth | thanx | 17:26 |
| InsClusoe | Can we say that PPA is similar to Sourceforge or freshmeat? | 17:26 |
| cprov | zeeth: but, dependending on the package it might cause some pain. | 17:26 |
| cprov | InsClusoe: no, I'd compare those directly | 17:26 |
| zeeth | ummm.. | 17:26 |
| cprov | InsClusoe: can you specify how do you see such relationship ? | 17:27 |
| cprov | err, I would *not* compare | 17:27 |
| cprov | sorry. | 17:27 |
| cprov | QUESTION: If I want to build a software that is not yet ready for integration with any distro, does it qualify to be hosted? | 17:27 |
| InsClusoe | cprov: :-) I inferred from this... "any person, team can host specific packages for any project hosted or not in Launchpad" | 17:27 |
| cprov | InsClusoe: well, PPA allows users to upload *any* (respecting license issues) source package, get it built and distributable under your responsibility | 17:28 |
| InsClusoe | ok.. I think I got it... Packages refer to binary packages... That means, source and rules for making binary package... And that, most certainly, is different from hosting projects... | 17:29 |
| cprov | this statement sort of also answer the last question ... | 17:29 |
| cprov | InsClusoe: exactly, you can "package" any upstream source (hosted or not in LP) | 17:29 |
| InsClusoe | cprov: Yup.. Gotcha. Thanks. Sorry for disrupting. | 17:30 |
| cprov | QUESTION: how do I know if a file is already uploaded into ubuntu archive (e.g. gutsy has v1.0, hardy has v3.0. I want to package v2.0) | 17:30 |
| cprov | uhmm, check the launchpad interface, I guess, `apt-cache`, etc | 17:31 |
| cprov | pretty vague, I know, feel free to ask a more concrete question if you want. | 17:32 |
| cprov | QUESTION: I'd like my package(s) to be available in multiple distributions (Feisty, Gutsy, Hardy, ..). How to do this the easiest way? Is it possible without reuploading three times with only a changed distribution in the changelog? | 17:32 |
| cprov | as know, the poll-based archive topology we use in ubuntu and all PPAs doesn't allow files to be republished | 17:33 |
| cprov | so you can (and should) upload a foo-bar_1.0 source only once | 17:33 |
| cprov | in the primary archive we provide tools to /copy/ publications across suites (dapper, gutsy, hardy, etc) | 17:34 |
| cprov | this feature is not yet available for PPA (via the UI) | 17:34 |
| cprov | PPA users can use one of the alternatives: | 17:34 |
| cprov | 1) request a *copy* via launchpad-questions given the exact directives, source name and version, whether to copy binaries or not, and destination suite | 17:35 |
| cprov | 2) upload the same source using another version or version prefix (~dapper1, ~feisty1, etc) | 17:36 |
| eddyMul | 1) is launchpad-questions a mailing list? | 17:36 |
| cprov | no the launchpad question sub-system | 17:36 |
| cprov | https://answers.edge.launchpad.net/launchpad/+addquestion | 17:37 |
| eddyMul | eddyMul: got it. thanx | 17:37 |
| cprov | as you all might suspect, the alternative 2 will be faster | 17:38 |
| cprov | We plan to offer 'copy' UI for PPAs during the next month. | 17:38 |
| cprov | ok, we have discussed WHAT to upload. Now let's sort WHERE | 17:38 |
| cprov | there are two tools available to upload packages: dput and dupload | 17:39 |
| cprov | (if you are brave enough, you can use a simple ftp client, but it's boring and error prone) | 17:39 |
| cprov | let's try a dput example config. | 17:40 |
| cprov | [my-ppa]fqdn = ppa.launchpad.net method = ftp incoming = ~your-launchpad-id/ubuntu/ login = anonymous allow_unsigned_uploads = 0 | 17:40 |
| cprov | err ... | 17:40 |
| cprov | [my-ppa] | 17:41 |
| cprov | fqdn = ppa.launchpad.net | 17:41 |
| cprov | method = ftp | 17:41 |
| cprov | incoming = ~your-launchpad-id/ubuntu/ | 17:41 |
| cprov | login = anonymous | 17:41 |
| cprov | allow_unsigned_uploads = 0 | 17:41 |
| cprov | this section should be appended to you ~/dput.cf file | 17:41 |
| dholbach | ~/.dput.cf | 17:42 |
| cprov | the 'my-ppa' dput target defines the location and the path to be used in you upload | 17:42 |
| cprov | dholbach: yes, '.' , thanks | 17:42 |
| cprov | don't feel obsessed to copy this irc snipped, it's all in https://help.launchpad.net/PPAQuickStart/ | 17:43 |
| cprov | the source upload processing is done every 5 minutes, so that's the time you should wait before getting a upload notification email | 17:43 |
| cprov | it will be either an 'acceptance' or a "rejection" message | 17:44 |
| cprov | the system will list you all the problem that cause the upload to be rejected, if it was the case | 17:44 |
| cprov | once the source was accepted, you should wait up to 20 minutes to have it published in you public archive | 17:45 |
| eddyMul | cprov: "upload processing is done every 5 minutes, so [wait]": it would be great to put this info in the PPAQuickStart page ;-) | 17:45 |
| holloway | cprov, can you give some errors? like beginners doing all the time? | 17:45 |
| cprov | at this point `apt-get source <just uploaded>` should work | 17:45 |
| cprov | eddyMul: sure :) I'll add | 17:46 |
| cprov | holloway: yes, most of the users upload sources targeted to 'unstable' distribution (as they come from debian) | 17:46 |
| holloway | cprov, thx, so there are only the 4 we know from ubuntu? | 17:47 |
| cprov | this mistake can be fixed by: 1) create a proper entry in the debian/changelog setting a ubuntu suite instead of the original debian suite OR 2 ) using the changesfile override feature in upload path. | 17:47 |
| cprov | you can have a dput target that forces 'dapper' doesn't matter what is said in the changesfile | 17:48 |
| cprov | [my-ppa-force-dapper] | 17:48 |
| cprov | incoming = ~your-launchpad-id/ubuntu/dapper | 17:48 |
| cprov | (the other fields should remain the same ...) | 17:49 |
| tamrat | QUESTION: (i understand the answer may be long but well - i think it is useful): which steps/test should/can be done before uploading your package, (after testing building of course). I don't want to try to upload 10 times to get a different error every time (I'm on 2 rejected uploads now ;-) | 17:49 |
| cprov | it will upload pristine source from debian or other distribution straight to dapper in your PPA. | 17:49 |
| cprov | tamrat: it's hard to say ... you can build the source and the binaries successfully locally, but still not getting all points required to upload the source fixed | 17:50 |
| cprov | tamrat: it really depends on the error and you packaging experience, I'm afraid to say. | 17:50 |
| cprov | holloway: another very common mistake it to upload binaries to PPA | 17:51 |
| holloway | ok | 17:51 |
| cprov | holloway: only a single and signed source will be accepted. | 17:51 |
| cprov | holloway: so, ensure you build source packages with `debuild -S` | 17:52 |
| holloway | cprov, got it :) | 17:52 |
| cprov | okidoki, we know WHAT and WHERE ... let's go for the WAIT stage ;) | 17:52 |
| cprov | once the source is 'accepted' you should *wait* | 17:53 |
| cprov | up to 20 minutes to have it published in you archive (`apt-get source <just-uploaded>`) (already said) | 17:54 |
| cprov | up to 1 hours to have you build queued (access +me/+archive/+builds to track them) | 17:54 |
| dholbach | people/+me ? | 17:55 |
| cprov | dholbach: yes, '<your lp page>/+archive/+builds' | 17:55 |
| cprov | the uploader won't receive any message if everything was successfully built and the binaries got published in you archive. | 17:56 |
| cprov | we only notify the users about *failures* | 17:56 |
| cprov | the email notification will tell you where to find the information about the failure | 17:57 |
| cprov | and then it's up to you to fix it or not ;) | 17:57 |
| cprov | An important thing to not about PPA build process is that they happen in a separate environment using the same ubuntu chroots but inside a XEN machine | 17:58 |
| cprov | so, they won't affect or get affect by other jobs, since the XEN guest is resumed before starting any build | 17:59 |
| cprov | ouch ... we are running out of time ... | 17:59 |
| dholbach | there's always the second PPA session on friday, 17:00 UTC :) | 17:59 |
| dholbach | and launchpad-users@lists.canonical.com | 17:59 |
| dholbach | (if you run into problems) | 17:59 |
| dholbach | thanks a lot cprov and mrevell - are there any final questions you want to answer or final announcements? | 18:00 |
| zeeth | sure thanx | 18:00 |
| mrevell | The only announcement is, "Look out for our new release late this week!" | 18:00 |
| Unksi | cprov: thank you | 18:01 |
| dholbach | rock on... thanks cprov and thanks mrevell | 18:01 |
| mrevell | Thanks dholbach for the opportunity, thanks cprov for doing such a great job. Thanks for everyone's questions and attention. | 18:01 |
| cprov | well, considering that I couldn't explain all the facets of the PPA system ... you are more than welcome to post questions on https://wiki.ubuntu.com/MeetingLogs/devweek0802/PPAs1 | 18:01 |
| cprov | I will answer them before the next session | 18:01 |
| InsClusoe | That's great... Thanks to both of you.. | 18:01 |
| cprov | and if you still want to talk, please come to the next session :) | 18:01 |
| dholbach | oh ... and there's of course #launchpad | 18:02 |
| === lex79 is now known as lex79|Away | ||
| cprov | thank you for participating. You are all bright stars ! | 18:02 |
| dholbach | :-) | 18:02 |
| corevette | thanks cprov | 18:02 |
| dholbach | ok... let's get started with the next session | 18:02 |
| dholbach | It's Packaging 101 time! :) | 18:02 |
| dholbach | who's here for the session? | 18:02 |
| corevette | me | 18:02 |
| charliecb | me | 18:02 |
| danbhfive | +1 | 18:02 |
| jsauer | me | 18:02 |
| antcarsa | me too | 18:02 |
| zeeth | cprov: thanx | 18:02 |
| icicle | me | 18:02 |
| nijaba | o/ | 18:02 |
| InsClusoe | me | 18:02 |
| mruiz | _0/ | 18:02 |
| Unksi | o/ | 18:02 |
| Kaasethu | me | 18:03 |
| barcc | me | 18:03 |
| civija | civija++ | 18:03 |
| rulus | me too | 18:03 |
| lengau | Hi | 18:03 |
| snhome | me too | 18:03 |
| Grazieno | me | 18:03 |
| shujin | me sever | 18:03 |
| warp10 | me too! | 18:03 |
| fredre | +1 | 18:03 |
| dholbach | ROCK and ROLL! | 18:03 |
| dholbach | bring it on | 18:03 |
| vistakiller | and me :P | 18:03 |
| tamrat | \o/ | 18:03 |
| holloway | me | 18:03 |
| zeeth | me \o/ | 18:03 |
| dholbach | for those of you tuning into the Developer Week just now: please ask your questions in #ubuntu-classroom-chat and prefix them with QUESTION: so they're easier to spot | 18:03 |
| dargol | me | 18:03 |
| eddyMul | me | 18:04 |
| amachu | ாை | 18:04 |
| amachu | hi | 18:04 |
| dholbach | we don't need preparation for this session, just make sure you have a deb-src line in your /etc/apt/sources.list | 18:04 |
| dholbach | if you're using hardy, that's just "deb-src http://archive.ubuntu.com/ubuntu hardy main restricted universe multiverse" | 18:04 |
| dholbach | once you've added that, please run sudo apt-get update | 18:05 |
| dholbach | we'll take a look at a small package I made a while ago called gnome-web-photo | 18:05 |
| dholbach | (it does thumbnails of webpages, etc.) | 18:05 |
| dholbach | please run apt-get source gnome-web-photo to get the source | 18:06 |
| dholbach | the following files have been downloaded: | 18:06 |
| dholbach | gnome-web-photo_0.3-0ubuntu1.diff.gz | 18:06 |
| dholbach | gnome-web-photo_0.3-0ubuntu1.dsc | 18:06 |
| dholbach | gnome-web-photo_0.3.orig.tar.gz | 18:06 |
| dholbach | the .orig.tar.gz file is exactly what I downloaded from the upstream webpage | 18:06 |
| dholbach | the .diff.gz the compressed patch I needed to add to make it built in the ubuntu / debian world | 18:07 |
| dholbach | the .dsc is a description file that has md5sums in it and so on | 18:07 |
| dholbach | apt-get source used dpkg-source -x to extract that and give us gnome-web-photo-0.3 | 18:07 |
| dholbach | ok, let's dive into it | 18:08 |
| dholbach | cd gnome-web-photo-0.3 | 18:08 |
| dholbach | ls debian/ | 18:08 |
| dholbach | these are the files I needed to add to make it build, ie to "package it" | 18:08 |
| dholbach | let's go through them one by one and let me know if you have questions | 18:08 |
| dholbach | less debian/changelog | 18:08 |
| dholbach | debian/changelog is necessary to indicate which changes were made by whom and which version number was used | 18:09 |
| dholbach | as a package maintainer it's necessary to document explicitly what you did | 18:09 |
| dholbach | Ubuntu is a bit special in the development modell: we maintain everything as teams | 18:10 |
| dholbach | there are of course people who know a great deal about a package, but there's no BML | 18:10 |
| dholbach | (big maintainer lock) | 18:10 |
| dholbach | so you're free to participate and enhance existing packages | 18:10 |
| dholbach | if you do changes, everybody needs to know why you did them :) | 18:10 |
| dholbach | <corevette> QUESTION: is there a format for a changelog? | 18:11 |
| dholbach | first good question | 18:11 |
| dholbach | yes, the format is pretty fixed | 18:11 |
| dholbach | let's go through all the items one by one | 18:11 |
| dholbach | first up is the source package name (I'll talk a bit about source and binary packages in a bit), in our case it's "gnome-web-photo" | 18:11 |
| dholbach | next up is the version string | 18:11 |
| dholbach | in debian you'd use <upstream version>-<debian revision> | 18:12 |
| dholbach | where upstream version means the version that the software authors just released | 18:12 |
| dholbach | and debian revision just being an incremental number (in the simple cases) starting with '1' | 18:13 |
| dholbach | in Ubuntu we add "ubuntu<number>" to indicate that we're changing a debian revision of a package | 18:13 |
| dholbach | as this package is not in debian (yet), it started with 0ubuntu1 | 18:13 |
| dholbach | next up is the | 18:14 |
| dholbach | ubuntu release we're uploading to | 18:14 |
| dholbach | we can always only upload to the one that is under development right now | 18:14 |
| dholbach | in our case we could only upload to hardy, but not to gutsy or feisty | 18:14 |
| dholbach | (there is feisty-updates and feisty-security and we have an entire session just about that later this week) | 18:15 |
| dholbach | the urgency is irrelevant in the ubuntu world | 18:15 |
| dholbach | next up are all the individual changes that happened in the new revidion | 18:16 |
| dholbach | revision | 18:16 |
| dholbach | some people tend to specify changes like this: | 18:16 |
| dholbach | * <file>: <change> | 18:16 |
| dholbach | I like that too | 18:16 |
| dholbach | if you package a new upstream version it might make sense to point out what happened upstream too | 18:16 |
| dholbach | next up is your name and email address plus a date string | 18:16 |
| dholbach | it'd be terribly irksome to type this all by hand | 18:16 |
| dholbach | which is why we use a tool called dch (in the devscripts package) to generate most of it for us | 18:17 |
| dholbach | <eddyMul> QUESTION: in debian/changelog, what time should I use for the timestamp? does it matter? | 18:17 |
| dholbach | eddyMul: date -R is used by dch | 18:17 |
| dholbach | <eddyMul> QUESTION: follow up to corevette: is there an emacs mode for it? :) | 18:17 |
| dholbach | eddyMul: dch will use whatever you specified as EDITOR in your profile | 18:17 |
| dholbach | <danbhfive> QUESTION: why the zero? | 18:18 |
| dholbach | I think I answered that | 18:18 |
| dholbach | <charliecb> QUESTION: Starts the revision-number always with 1 ?(and 0 for debian if the package doesn't exists in debian) | 18:18 |
| dholbach | charliecb: if you take a debian package and alter it, you mostly just add "ubuntu1", then increment the last number | 18:18 |
| dholbach | of course there are special cases, but we'll not deal with them in this session nos | 18:18 |
| dholbach | now | 18:18 |
| dholbach | ok, everybody happy with debian/changelog? | 18:19 |
| dholbach | ok, party on | 18:19 |
| dholbach | next up is debian/compat which in our case just says "4" | 18:19 |
| dholbach | we have a set of tools in what we call debhelper suite that help with packaging a lot | 18:20 |
| dholbach | lots of tasks like installation of files, compression of changelog, etc - all the kind of tasks you use in nearly all packages - are simplified in there | 18:20 |
| dholbach | debian/compat specifies the debhelper compatibility level | 18:20 |
| dholbach | it's not really interesting, but for those of you interested in it, check out man debhelper to see what those debhelper compat levels mean | 18:21 |
| dholbach | it's usually not necessary to alter the value | 18:21 |
| dholbach | <mruiz> QUESTION: dholbach, about debian/compat how to decide the version? | 18:21 |
| === fd is now known as yafd00-00 | ||
| dholbach | mruiz: if you package a new piece of software and don't depend on any new debhelper features, just stick with 4 or 5 (which is what dh_make will use for you) | 18:22 |
| dholbach | <charliecb> QUESTION: _must_ debian/compat file exists? | 18:22 |
| dholbach | charliecb: I don't think it needs to exist, but it does for clarity in the majority of packages | 18:23 |
| dholbach | <corevette> QUESTION: how do you use debhelper; tutorial online? | 18:23 |
| dholbach | corevette: good question | 18:23 |
| dholbach | http://wiki.ubuntu.com/PackagingGuide is THE page you want to check out | 18:23 |
| dholbach | it has lots of tutorials, including how to package use debhelper | 18:24 |
| dholbach | ok let's move on - debian/control is much more exciting | 18:24 |
| dholbach | the first thing you'll notice: it's separate in two stanzas | 18:24 |
| dholbach | <eddyMul> QUESTION: is it worth the time and effort to "bump up" a package's debhelper compat? (which probably incurs some changes in packaging code...) | 18:24 |
| dholbach | eddyMul: not really, only if you *REALLY* depend on a new debhelper features | 18:24 |
| dholbach | in all other cases it's just an upload that has no user impact | 18:25 |
| dholbach | coming back to debian/control | 18:25 |
| dholbach | the first stanza is about the source | 18:25 |
| dholbach | and all the following ones (in our case it's just one) are about the binary package | 18:25 |
| dholbach | packages | 18:25 |
| dholbach | the source needs to be in a section, so that's specified | 18:25 |
| dholbach | a priority is set and a maintainer too | 18:26 |
| dholbach | the Maintainer field is quite interesting in the case of Ubuntu | 18:26 |
| dholbach | I mentioned before that we maintain packages in teams, but in addition to that our friends at Debian decided that we should change the Maintainer field in cases where we alter packages we inherit from debian | 18:26 |
| dholbach | https://wiki.ubuntu.com/DebianMaintainerField describes the whole process, the general idea is: Debian maintainers received emails of Ubuntu users who wanted to reach the "maintainer" | 18:27 |
| dholbach | which did not always work out well | 18:27 |
| dholbach | so what we do is, we store the original maintainer, but change the maintainer field to our team mailing lists | 18:27 |
| dholbach | next up is "Build-Depends" | 18:28 |
| dholbach | and that's one of the most critical values in the whole file | 18:28 |
| dholbach | it lists all the packages that need to be installed in order to build the package in a minimal environment | 18:28 |
| dholbach | if you listened to the PPA session before you might have gathered that the source is built in chroots (minimal environments) where just build-essential (which includes gcc, make, etc) and the Build-Depends are installed | 18:29 |
| dholbach | so there's a distinction between Depends (binary packages) and Build-Depends (source packages) | 18:29 |
| dholbach | <tamrat> QUESTION: where can i find information about building different binary packages from one source package (eg creating shared libraries, -dev and the package from the same source) | 18:29 |
| dholbach | tamrat: that's exactly in debian/control | 18:29 |
| dholbach | I'll just finish up the source stanza in debian/control, then come to the binary packages | 18:29 |
| dholbach | <InsClusoe> QUESTION: Why do you say minimal environment? | 18:30 |
| dholbach | InsClusoe: you upload the source package (.dsc .orig.tar.gz .diff.gz) to the build daemon, which will take it and put it into a minimal environment, just containing a VERY FEW packages | 18:30 |
| dholbach | then install the Build-Depends | 18:30 |
| dholbach | so you can't expect that libsomething6-dev is installed | 18:30 |
| dholbach | you need to specify it | 18:30 |
| dholbach | <dargol> QUESTION: how do I guess build depends for a given source? | 18:31 |
| dholbach | dargol: that's an excellent question and what I wanted to show next | 18:31 |
| dholbach | of course you could just try and fail over and over again | 18:31 |
| dholbach | for that you'd use a pbuilder (http://wiki.ubuntu.com/PbuilderHowto) which generates that chroot for you | 18:31 |
| dholbach | and watch the build fail over and over again until you get the build-depends right :) | 18:32 |
| dholbach | but it's cleverer to check out a few files like ./configure.ac which specifies upstream build requirements | 18:32 |
| dholbach | in our case the package is written in C++ and uses autotools, so you'll find a configure.ac there | 18:32 |
| dholbach | stuff like: | 18:33 |
| dholbach | GLIB_REQUIRED=2.6.0 | 18:33 |
| dholbach | GTK_REQUIRED=2.6.3 | 18:33 |
| dholbach | LIBXML_REQUIRED=2.6.12 | 18:33 |
| dholbach | is usually a very good indicator of what you need to build it | 18:33 |
| dholbach | always make sure you mention the -dev packages in the Build-Depends which contain header files necessary to compile and link the software correctly | 18:33 |
| dholbach | next up is Standards-Version: 3.7.2 | 18:33 |
| dholbach | which just declares that this source package complies with version 3.7.2 of the debian policy | 18:34 |
| dholbach | <charliecb> QUESTION: this package depends on debhelper. depends *every* package on debhelper? | 18:34 |
| dholbach | charliecb: no, but the vast majority - there are people who choose not to use debhelper but do a lot of stuff manually | 18:34 |
| dholbach | <eddyMul> QUESTION: how do we decide which ./configure options to --enable and which ones we can do --without? | 18:34 |
| dholbach | eddyMul: that's a maintainer question | 18:34 |
| dholbach | eddyMul: you maintain the package and make it available for millions of users | 18:35 |
| dholbach | it's your (and your team's) call | 18:35 |
| dholbach | so if the frobnicator feature is brand-new and you're about to release an LTS, you probably don't want to --enable-frobnicator | 18:35 |
| dholbach | ok, let's move on to binary packages | 18:36 |
| dholbach | binary packages is the stuff that users like my mom install, they don't care about the source :) | 18:36 |
| dholbach | if you have a HUGE package, you might want to consider splitting it up | 18:36 |
| dholbach | if you run apt-cache showsrc mono | grep Binary | head -n 1 you will notice that mono makes heavy use of splitting | 18:37 |
| amachu | :) | 18:37 |
| dholbach | <eddyMul> QUESTION: ./configure: is there a document about Debian/Ubuntu's default --prefix, etc | 18:37 |
| dholbach | eddyMul: I need to pass this question on, best to ask in #ubuntu-motu, sorry | 18:38 |
| dholbach | ok, in our case we just have one binary package, it's called gnome-web-photo too | 18:38 |
| dholbach | Architecture: is an interesting field | 18:38 |
| dholbach | in our case it is "any" which means: build this package on any architecture there is | 18:38 |
| dholbach | this means: we upload the source of gnome-web-photo | 18:39 |
| dholbach | and it will be built on all buildds: i386, amd64, powerpc, hppa, lpia, etc etc | 18:39 |
| dholbach | this is necessary because we compile code that is architecture dependent | 18:39 |
| dholbach | that's the case for C, C++ and so on | 18:39 |
| dholbach | if you just upload a package that contains artwork, you don't need to bother, set Architecture: all to indicate: it's the same for all architectures | 18:40 |
| dholbach | that also includes python and perl scripts, etc | 18:40 |
| dholbach | <eddyMul> QUESTION: just to confirm, any != all ? | 18:40 |
| dholbach | eddyMul: yes | 18:40 |
| dholbach | any = build this for any architecture there is | 18:41 |
| dholbach | all = it's the same for all archs | 18:41 |
| dholbach | <charliecb> QUESTION: for example, package cdbs has architecture is i386. what if i tell that package gnome-web-photo that architecture is any? is this possible? | 18:41 |
| dholbach | charliecb: I think I need to correct you | 18:41 |
| dholbach | daniel@lovegood:~$ apt-cache showsrc cdbs | grep Arch | 18:41 |
| dholbach | Architecture: all | 18:41 |
| dholbach | daniel@lovegood:~$ | 18:41 |
| charliecb | no, its just an example. | 18:42 |
| dholbach | cdbs is written in shell scripts, so there's no need to build it on different architectures | 18:42 |
| dholbach | charliecb: then please rephrase your question - I might have misunderstood | 18:42 |
| charliecb | go on. i'll ask later. | 18:43 |
| dholbach | ok thanks | 18:43 |
| dholbach | of course you can have a list of archs the package builds on | 18:43 |
| dholbach | so if your package is known to just build on i386 and amd64 (and not on powerpc, etc) | 18:43 |
| dholbach | you just write Architecture: amd64 i386 | 18:44 |
| dholbach | coming to the next line: Depends | 18:44 |
| dholbach | this is really interesting and important to get right | 18:44 |
| dholbach | in our case it first looks a bit weird: Depends: ${shlibs:Depends}, ${misc:Depends} | 18:44 |
| dholbach | it's not something like: | 18:44 |
| dholbach | Depends: libatk1.0-0 (>= 1.13.1), libc6 (>= 2.5-0ubuntu1), libcairo2 (>= 1.3.12), libfontconfig1 (>= 2.4.0), libgcc1 (>= 1:4.1.1-21ubuntu1), libgconf2-4 (>= 2.13.5), libglib2.0-0 (>= 2.12.9), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.10.3), libjpeg62, liborbit2 (>= 1:2.14.1), libpango1.0-0 (>= 1.15.5), libpng12-0 (>= 1.2.13-4), libstdc++6 (>= 4.1.1-21ubuntu1), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxfixes3 (>= 1:4.0.1), l | 18:45 |
| dholbach | ibxi6, libxinerama1, libxml2 (>= 2.6.27), libxrandr2, libxrender1, gconf2 (>= 2.12.1-4ubuntu1) | 18:45 |
| dholbach | we might have expected | 18:45 |
| dholbach | the reason for that is simple | 18:45 |
| dholbach | ${shlibs:Depends} is a variable that gets expanded during the build process | 18:45 |
| dholbach | expanded to all the packages that contain the libraries the binaries in our package are linked to | 18:45 |
| dholbach | so the file /usr/bin/gnome-web-photo that is in our package is linked to all the libraries contained in the packages above | 18:46 |
| dholbach | ${misc:Depends} gets expanded to miscellaneous tools the package might need | 18:46 |
| dholbach | for example dh_gconf (in the debhelper) package added gconf2 (>= 2.12.1-4ubuntu1) | 18:46 |
| dholbach | <nijaba QUESTION: so for scipts, we need to be explicit? | 18:46 |
| dholbach | <nijaba> QUESTION: so for scipts, we need to be explicit? | 18:46 |
| nxvl_work | dholbach: i will handle the questions, just ask for next one | 18:47 |
| dholbach | nijaba: yes, if your script calls say "wget" or "firefox" you need to depends on that manually | 18:47 |
| dholbach | the rest of debian/control is just description | 18:47 |
| dholbach | a short one in the Description: line | 18:48 |
| dholbach | and the long one below | 18:48 |
| dholbach | <eddyMul> QUESTION: are ${shlibs:Depends} somehow taking values from Build-Depends? | 18:48 |
| dholbach | eddyMul: library packages ship .shlibs files (which are generated automatically), which are used to determine which library corresponds to which library package with which version | 18:49 |
| dholbach | on friday we'll have a session about library packaging which talk about that in more detail | 18:49 |
| dholbach | ok, party on | 18:49 |
| dholbach | debian/copyright | 18:49 |
| dholbach | is one of the files most easy to get wrong | 18:49 |
| dholbach | debian/copyright contains information about: | 18:50 |
| dholbach | - who did the packaging | 18:50 |
| dholbach | - who has copyrights | 18:50 |
| dholbach | - who is the author | 18:50 |
| dholbach | - under which license the source is licensed | 18:50 |
| dholbach | it's absolutely important to get that right, else Ubuntu and Canonical get in deep trouble :) | 18:50 |
| dholbach | so if you decide to package something new, you need to make sure you observe all copyrights and check all the source files | 18:51 |
| dholbach | else the archive admins won't accept your package | 18:51 |
| nxvl_work | <eddyMul> QUESTION: how can I find out what's in ${shlibs:Depends}? is it somehow inferred from Build-Depends? or is `ld*` doing some magic? | 18:51 |
| dholbach | eddyMul: ld* is used, then the *.shlibs files of the used packages are looked at, but that goes too far in this sessioon | 18:52 |
| dholbach | nxvl_work: next | 18:52 |
| nxvl_work | <snhome> QUESTION no author in this one, assumed to be copyright holder? | 18:52 |
| dholbach | snhome: if you run ls src/* | xargs head | less you will see that there are a bunch of copyright notices | 18:53 |
| dholbach | and yes... it is necessary to check all the files beforehand | 18:53 |
| dholbach | it's a tedious job, but just imagine the case where you were wrong and something we were not allowed to redistribute ends up on the CDs :) | 18:53 |
| dholbach | it's easy to remove software out of the archive, try that with 345743456765434567 million CDs that were sent out :) | 18:54 |
| amachu | mmm | 18:54 |
| dholbach | ompaul just pointed out that I should refer to http://wiki.ubuntu.com/PackagingGuide | 18:54 |
| dholbach | it has a long chapter just about copyright stuff | 18:55 |
| dholbach | nxvl_work: next | 18:55 |
| nxvl_work | <snhome> QUESTION you said this file contained who did package, has copyright, author but this one has no author. I did not understand your answer | 18:55 |
| dholbach | snhome: you are right, I was lazy and the archive admins are stricter nowadays | 18:55 |
| dholbach | Copyright Holder: | 18:55 |
| dholbach | Christian Persch <chpe@gnome.org> | 18:55 |
| dholbach | is all I wrote | 18:55 |
| nxvl_work | dholbach: you are evil! | 18:56 |
| nxvl_work | :D | 18:56 |
| dholbach | I would have to specify Upstream Author: and Copyright Holder: separately | 18:56 |
| * dholbach hugs nxvl_work | 18:56 | |
| dholbach | and mention the year of the copyright, etc, etc | 18:56 |
| * nxvl_work hugs dholbach back | 18:56 | |
| dholbach | there are probably better examples | 18:56 |
| dholbach | let's come to the core part of the package: debian/rules | 18:56 |
| dholbach | in our case it's tiny, because I decided to use CDBS | 18:56 |
| dholbach | CDBS is a set of makefile snippets that internally call all the debhelper tools for us | 18:57 |
| dholbach | CDBS has its downsides: there is a lack of documentation (https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml is good though) and it's not easy to look behind the scenes | 18:57 |
| dholbach | and it's certainly not so great for understanding what happens and how things work | 18:58 |
| dholbach | but as we're at the end of the session, it fit quite well :) | 18:58 |
| dholbach | <eddyMul> QUESTION: debian/rules: is it worth the time/effort to port stuff to cdbs? (I like cdbs. I hope all packages use it) :) | 18:58 |
| dholbach | eddyMul: that's a good question | 18:58 |
| dholbach | my answer is: no | 18:58 |
| dholbach | first of all: it's of little use to the user, it doesn't really change much and the effort of "porting" to it can be quite big | 18:59 |
| dholbach | second: we always need to merge the diff between ubuntu and debian packages | 18:59 |
| dholbach | if it's a package you're deeply interested and consider maintaining and think that whatever the debian packages uses is too gruesome, you might do it | 18:59 |
| dholbach | but normally, no :) | 18:59 |
| dholbach | the session is over - there will be lots of other sessions where you can ask your questions :) | 19:00 |
| dholbach | just a few links: | 19:00 |
| dholbach | get started: https://wiki.ubuntu.com/MOTU/GettingStarted | 19:00 |
| === dojo is now known as zubat | ||
| nxvl_work | dholbach: thanks for your talk! | 19:00 |
| * nxvl_work waves on dholbach | 19:00 | |
| dholbach | Blog about Ubuntu Developer Week and your MOTU journey: Add your weblog to http://ubuntuweblogs.org by following these instructions: http://ubuntuweblogs.org/submit.html | 19:00 |
| dholbach | thank nxvl_work | 19:00 |
| charliecb | thx | 19:00 |
| Unksi | thankies dholbach :) | 19:00 |
| nxvl_work | \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ | 19:00 |
| dholbach | you guys ROCK! :) | 19:01 |
| Kaasethu | thanks - got to know new things | 19:01 |
| shujin | Thanks | 19:01 |
| bananaramax | great session - thanks a lot | 19:01 |
| dargol | dholbach: thanks a lot! | 19:01 |
| amachu | thank you, dholbach | 19:01 |
| Jithu2k1 | :-D | 19:01 |
| nijaba | thank dholbach | 19:01 |
| holloway | thanks dholbach | 19:01 |
| jsauer | thanks dholbach | 19:01 |
| fredre | thank you | 19:01 |
| Lantash | thanks a lot! great session | 19:01 |
| zubat | thanks | 19:01 |
| dholbach | next up are our Packaging Kings: James Westby & Nicolas Valcárcel | 19:01 |
| dholbach | who will talk to you about Ubuntu and Debian collaboration | 19:01 |
| james_w | \o/ | 19:01 |
| dholbach | thanks a lot everybody | 19:01 |
| * dholbach hugs james_w and nxvl_work | 19:01 | |
| james_w | thanks Daniel. | 19:01 |
| nxvl_work | heh, 10 lines of hugs and love, that's why i love ubuntu | 19:02 |
| dholbach | the stage is yours :) | 19:02 |
| james_w | Firstly I'd like to apologise to Nicolas, as my oversight meant that he wasn't listed as co-presenter of this talk. Sorry Nicolas. | 19:02 |
| nxvl_work | james_w: don't worry, i add myself :D now i'm in there | 19:03 |
| james_w | We are going to talk today a little about collaboration between Debian and Ubuntu, and how you can make the process smoother. | 19:03 |
| james_w | Firstly I want to say a little about what the relationship between Debian and Ubuntu is. | 19:03 |
| james_w | Debian is the base upon which Ubuntu is built. | 19:04 |
| james_w | Almost all packages in Ubuntu come from Debian, and most are used unchanged. | 19:04 |
| james_w | This means that Ubuntu owes a lot to Debian and should endeavour to maintain a good relationship with them. | 19:04 |
| james_w | There are however several differences in the way that Debian and Ubuntu are organised, and in the decisions that they have made on some issues that you need to understand in order to work with them most effectively. | 19:05 |
| james_w | The biggest difference is that in Debian all packages have a maintainer, which may be a team, who controls the package. | 19:05 |
| james_w | (Please feel free to ask any questions that you have as we go). | 19:05 |
| james_w | They generally make all the decisions about the package, and are normally the only ones to perform uploads of that package. | 19:06 |
| snhome | here or in #-chat? | 19:06 |
| nxvl_work | snhome: -chat | 19:06 |
| james_w | There are some moves away from this, but it remains the status quo. | 19:06 |
| james_w | This is different to Ubuntu where in general a package doesn't have a maintainer as such, it is just looked after by all contributors. | 19:07 |
| james_w | This difference has effects on both Ubuntu and Debian. | 19:07 |
| james_w | For Ubuntu it means that generally a contributor isn't intimately familiar with a package, and doesn't know the Debian maintainer's opinion on things. | 19:07 |
| james_w | For Debian maintainers it means that they generally don't know who to contact if they wish to discuss a package in Ubuntu. | 19:08 |
| james_w | The differences in some policy decisions can also make it difficult for a Ubuntu contributor to know whether what they are doing also applies to Debian as well. | 19:08 |
| james_w | This can be especially true for bugs, where differing versions of packages, or different dependencies in the chain can hide or expose bugs. | 19:08 |
| edosar | but how many of debian mainteiners are ubuntu packages ? | 19:09 |
| nxvl_work | edosar: ask you question on #ubuntu-classroom-chat please | 19:09 |
| === smarter_ is now known as smarter | ||
| james_w | edosar: I don't understand your question I'm afraid, if you could re-ask it in #ubuntu-classroom-chat that would be great. | 19:10 |
| james_w | It can be helpful to not consider Debian as a "whole," but more as a group of people who each work in their own little area. | 19:11 |
| james_w | You will find that if you contact most of them with a bug report, a patch, or a question they will be very friendly and helpful. | 19:11 |
| === RainC1 is now known as RainCT | ||
| james_w | There are a few people that this wouldn't really apply to, but they are definitely in the minority. | 19:11 |
| james_w | You will probably find if you contact those ones in a friendly manner about a specific issue then they will probably still help you, but it can be a scary thing to do. | 19:12 |
| james_w | What I am trying to tell you here is not to let the actions of a noisy few spoil your opinions of the whole community. | 19:12 |
| james_w | In order to understand the best ways to share work between Ubuntu and Debian we need to understand how packages flow between them. | 19:12 |
| james_w | Ubuntu takes all source packages from Debian that aren't on a blacklist and automatically "syncs" them in to Ubuntu. | 19:13 |
| james_w | This means that the source package is taken unmodified and just rebuilt in the latest development version of Ubuntu. | 19:13 |
| james_w | There are certain things that may be done while building which mean that you may get different binary packages, but they do not alter the functionality, for instance https://wiki.ubuntu.com/DebianMaintainerField. | 19:13 |
| james_w | This process stops at "DebianImportFreeze". | 19:13 |
| james_w | In order to sync a packageafter that stage you must file a sync request, following the process at https://wiki.ubuntu.com/SyncRequestProcess. | 19:14 |
| james_w | Where Ubuntu has to make changes to the package a new upload is done. | 19:14 |
| james_w | This upload has a version number containing "ubuntu", which ensures that the package won't be synced without manual action, so that the changes are not lost. | 19:15 |
| james_w | When this has been done in the past and a new upload is made to Debian, the package will be eligible for "merging". | 19:15 |
| james_w | This means taking the two versions of the package and reconciling the changes so that you get the new changes from Debian, but also keep the Ubuntu changes. See https://wiki.ubuntu.com/UbuntuDevelopment/Merging for more information. | 19:15 |
| james_w | Sometimes when you go to merge a package you will find that the new Debian version includes all the changes that were made in Ubuntu. | 19:15 |
| james_w | In that case you perform a sync, meaning that again Ubuntu is using Debian's package for that software. | 19:16 |
| james_w | And we all cheer, as that is Free Software in action (and we have less work to do). | 19:16 |
| james_w | So, what are the ways in which we can share work with Debian? | 19:16 |
| james_w | There are a whole bunch of ways, for instance you can share patches, work together to package new upstream versions, or coordinate transitions or security fixes. | 19:17 |
| james_w | You can even become maintainer or co-maintainer of a package in Debian so that the package can always be used unmodified in both with less work. | 19:17 |
| james_w | When you are about to make some changes in Ubuntu you can look to see whether these apply to Debian as well, and if they do contact the Debian maintainers and propose that you work together on the issue, or just send them the result of your work. | 19:18 |
| james_w | It's always a good practice to coordinate your changes with the Debian maintainer, so you can check if they differ from her plans, or she is already working on the problem. | 19:19 |
| james_w | We want to avoid cases where incompatible changes are made in the two distributions, as that creates a massive headache for the future. | 19:19 |
| james_w | Now, we'll show you a couple of places you can use to find information about packages in Debian. | 19:20 |
| james_w | There are several places from which you can find information about packages in Debian. Knowing where to look to find something out can be quite an art in itself. | 19:20 |
| james_w | Luckily there is one place that tries to gather as much of this information as possible. That place is the Package Tracking System, known as the PTS. | 19:20 |
| james_w | The PTS lives at http://packages.qa.debian.org/. You can quickly go to the page for a package using http://packages.qa.debian.org/package. | 19:21 |
| james_w | Note that it works using the source package name, but if you enter a binary package name you get a helpful redirect page. | 19:21 |
| james_w | Let's take a look at a typical page: http://packages.qa.debian.org/gnupg. | 19:21 |
| james_w | Starting from the top left you can see information about the source package, such as versions, and the priority. | 19:21 |
| james_w | You also have links to the components of the source package, so using "dget" you can quickly download the current Debian source package. | 19:21 |
| james_w | In the right hand pane, you have some links to bug reports for the source package. | 19:22 |
| james_w | These include the bug reports on all of the binary packages, but can also reports on the source package itself, so I usually use these so that I don't miss them (though they are rare). | 19:22 |
| james_w | Below that you can subscribe to the PTS. This means that if you are really interested in a package you can get emails when things happen with the package. | 19:22 |
| james_w | If you select advanced mode from the drop down menu you can select what sort of information you would like to receive. | 19:23 |
| james_w | There are loads more links on these pages, I would encourage you to spend some time clicking around in the PTS later, and just see where you end up. | 19:23 |
| james_w | It can be hard to remember where to find a bit of information, but most is available somewhere in one of these links. | 19:24 |
| james_w | The other important source of information is the Bug Tracking System, known as the BTS. | 19:24 |
| nxvl_work | <Kaasethu> QUESTION: //You can quickly go to the page for a package using http://packages.qa.debian.org/package.// -->goes to 404 error | 19:24 |
| james_w | If you go to http://bugs.debian.org/src:gnupg you can see the page for the gnupg source package. | 19:24 |
| james_w | Kaasethu: that link does as there is no package called "package", try http://packages.qa.debian.org/gnupg instead. | 19:26 |
| james_w | Back to the BTS: on the above page you can see an overview of the bugs, with them divided in to sections. You can click on a bug report to get more information. | 19:26 |
| james_w | Email is used to communicate with and control the BTS. | 19:27 |
| james_w | You can find information on doing this at http://www.debian.org/Bugs/. | 19:27 |
| james_w | You can also use "reportbug -B Debian" and the "bts" tool to generate the emails. | 19:27 |
| james_w | Some tasks can be a little confusing. If you get stuck try asking in #ubuntu-motu, someone will probably be able to help. | 19:28 |
| james_w | So, as eddyMul wanted, we'll now talk about sending patches to Debian. | 19:28 |
| james_w | I chose this topic for several reasons. | 19:28 |
| james_w | Firstly, it is often requested that Ubuntu forwards more of its patches to Debian. | 19:28 |
| james_w | Secondly, it is quite an easy thing to do. | 19:28 |
| james_w | Thirdly, if Ubuntu pushes all its patches for a package back to Debian then the package can just be synced in future, reducing the amount of work it takes to maintain them. | 19:29 |
| james_w | so, everybody wins. | 19:29 |
| james_w | In order to submit a patch to Debian you should first create a standalone patch that fixes a specific issue. | 19:29 |
| james_w | You should then check the BTS to see if a bug has been filed about the issue. | 19:29 |
| james_w | If it has then you can email the bug report and attach the patch, sending a control command to tag the bug "patch" ("bts tag #12345 patch"). | 19:29 |
| james_w | The patch can either be a simple patch that they can apply to the unpacked source package. | 19:30 |
| james_w | Or, you can create a second source package and use "debdiff" to get the changes, and then filter out anything you don't want to send (perhaps with filterdiff). | 19:30 |
| james_w | (debdiff uses interdiff internally, so you can also use that tool directly). | 19:31 |
| james_w | In ubuntu-dev-tools there is a command to do exactly that: submittodebian. | 19:31 |
| james_w | If you run that then it will generate the debdiff, allow you to edit out parts that you don't want, and then file it as a bug in the BTS. | 19:32 |
| james_w | It uses reportbug for the last part, so you can attach the patch to an existing bug as well. | 19:32 |
| james_w | eddyMul> QUESTION: " you can email the bug report and attach the patch": how do I email the bug report? do I email the maintainer? (I thought I should be commenting on a bugzilla entry, or something like that....) | 19:34 |
| nxvl_work | james_w: would you answer this one? | 19:34 |
| james_w | you email the bug itself. You can either compose a mail to 12345@bugs.debian.org to send a message to bug #12345, or you can use "reportbug -B Debian" | 19:35 |
| nxvl_work | BTS it's not like LP | 19:35 |
| nxvl_work | on LP we just add a comment and attach our patches in there | 19:35 |
| nxvl_work | on BTS all the changes are handled by mail | 19:35 |
| nxvl_work | you report bugs by mail, change the status by mail, add comments by mail | 19:36 |
| nxvl_work | the only way to interact with BTS is by mails | 19:36 |
| james_w | I tend to do these steps by hand as I am familiar with the BTS, but if you are not reportbug should be very useful. | 19:36 |
| james_w | You can see one of the mails that I sent at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451683. | 19:36 |
| james_w | One thing that we would like you to do when filing bugs in Debian, with or without a patch, is to set a "usertag" on them. | 19:36 |
| nxvl_work | you can find more information about this on http://www.debian.org/Bugs/ | 19:36 |
| james_w | This allows the bugs to be tracked as one, so that it can be seen where Ubuntu is contributing back. | 19:37 |
| james_w | You can find out how to do this at https://wiki.ubuntu.com/Bugs/Debian/Usertagging. | 19:37 |
| james_w | I would like to point you to one last thing that will make all of this easier in an environment where we have multiple people working the packages. | 19:37 |
| james_w | That is the proposal described at https://lists.ubuntu.com/archives/ubuntu-devel/2007-November/024743.html. | 19:38 |
| james_w | If you could all start using this technique when creating patches it will make it easier to understand what patches are meant for upstream. | 19:38 |
| james_w | My closing comment would be that there are many people involved in Ubuntu development that are knowledgeable about Debian, so if you need to know where to find something, or would like advice about whether a change is applicable to Debian then you should just ask. | 19:38 |
| james_w | Now, nxvl_work is going to take over for the rest of the session. | 19:39 |
| nxvl_work | james_w: thanks | 19:39 |
| nxvl_work | Ok | 19:39 |
| nxvl_work | I will talk a little about the best practices on Debian sharing | 19:39 |
| nxvl_work | Sometime we want to help, but we do to exact oposite | 19:40 |
| nxvl_work | so, please keep in mind some of the things i'm going to tell you | 19:40 |
| nxvl_work | There are many ways that you can work together with Debian. | 19:40 |
| nxvl_work | For instance you can share patches, work together to package new upstream versions, | 19:41 |
| nxvl_work | coordinate transitions, security fixes. You can even become maintainer | 19:41 |
| nxvl_work | or co-maintainer of a package in Debian so that the package can always | 19:41 |
| nxvl_work | be used unmodified in both with less work. | 19:41 |
| nxvl_work | ok, that part is not as simple as it look you need to be careful on what you are doing | 19:42 |
| nxvl_work | Many of the bugs on ubuntu are present on debian | 19:42 |
| nxvl_work | but it's important to keep in mind and be VERY careful is that no every bug on ubuntu | 19:43 |
| nxvl_work | applies to debian, there are software error which are not reproducible on debian | 19:43 |
| nxvl_work | so if you will ping the maintainer or report back to debian | 19:43 |
| nxvl_work | you must be sure it applies, so you don't make the Debian maintainer work and test looking for a bug that doesn't exist. | 19:43 |
| nxvl_work | Also if you are going to send your work to them you must keep in mind that he is also a volunteer as you are | 19:44 |
| nxvl_work | they can add your changes if they think it will help them | 19:44 |
| nxvl_work | but maybe they don't want to apply them | 19:45 |
| nxvl_work | also they don't want to read long diff files with lots of changes | 19:45 |
| nxvl_work | it's better to send them small and separate patches with your | 19:45 |
| nxvl_work | changes so they can use the ones they find usefull and discards the ones | 19:45 |
| nxvl_work | who doesn't | 19:45 |
| nxvl_work | Ok, but, what if i'm a triager? | 19:45 |
| nxvl_work | You can test if the bugs are also present on debian and report them back using BTS, being carefaul on the points talked earlier | 19:46 |
| nxvl_work | also, LP and bts have a "link" option so you can have on the Bug report at LP the link to the debian bug report | 19:46 |
| james_w | <tacone> QUESTION: how are we going to know that a bug exists or not in Debian ? | 19:46 |
| nxvl_work | so it's easier to keep track of what's going on with the debian bug | 19:46 |
| nxvl_work | tacone: easy, try to reproduce it on Debian :D | 19:47 |
| nxvl_work | tacone: i have always a Virtual machine running debian for test purposes | 19:47 |
| nxvl_work | also you can have a chroot environment | 19:47 |
| nxvl_work | ok, back to the LP and BTS syncroniztion | 19:48 |
| james_w | there are some packaging bugs that can be checked just by doing things like looking at the dependencies in Debian, but most do need an environment to test. | 19:48 |
| james_w | Also, you could ask someone with a Debian system to test. | 19:48 |
| nxvl_work | this way it's easier to keep track of what's going on with the debian bug | 19:48 |
| nxvl_work | also bts has an option like this that you can use with the command (mail command) 'forwarded $bug $upstream_url' | 19:49 |
| nxvl_work | so you can have it backwards, so please use the tools to have a better comunication and avoid the packagers to duplicate efforts on patching. | 19:49 |
| nxvl_work | And always keep it mind that Debian makes things LOTS easier to us | 19:49 |
| nxvl_work | so we need to try to do our best to make things LOTS of easier for them also | 19:50 |
| nxvl_work | :D | 19:50 |
| james_w | <eddyMul> QUESTION: does ubuntu track debian unstable? testing? | 19:50 |
| nxvl_work | ok, now with the questions | 19:50 |
| nxvl_work | eddyMul: track as in syncs from? | 19:50 |
| eddyMul | eddyMul: yes | 19:50 |
| nxvl_work | unstable | 19:50 |
| nxvl_work | always unstable | 19:51 |
| nxvl_work | <snhome> QUESTION What am I missing in explanation? If Ubuntu and Debian are so similar why have Ubuntu? | 19:51 |
| james_w | though it is possible to sync from elsewhere, e.g. experimental | 19:51 |
| nxvl_work | snhome: that's a common but hard question | 19:51 |
| nxvl_work | eddyMul: oh yes i forgot, somethimes we sync directly from upstream | 19:51 |
| nxvl_work | eddyMul: but commonly from sid (unstable) | 19:51 |
| nxvl_work | snhome: ok, on your question | 19:51 |
| nxvl_work | snhome: there are some differences between Ubuntu and Debian, and they go on their policies | 19:52 |
| nxvl_work | for example, ubuntu install some restricted driver out of the box, debian would NEVER do it | 19:53 |
| james_w | Ubuntu changed some things that would have been very difficult or impossible to do in Debian. | 19:54 |
| james_w | Also, Ubuntu has a smaller focus in terms of things like supported architectures, meaning it can focus more energy in to the areas it does concentrate on. | 19:54 |
| nxvl_work | so Ubuntu and Debian are similar in some ways, but VERY different on others | 19:55 |
| james_w | any last questions, we have a couple of minutes left. | 19:55 |
| nxvl_work | mathiaz: around? | 19:56 |
| seajazz | thanx | 19:56 |
| snhome | thanks | 19:56 |
| james_w | thanks all. | 19:56 |
| james_w | and thanks nxvl. | 19:57 |
| shujin | thanks guys! | 19:57 |
| james_w | Rave safe kids. | 19:57 |
| arturodr | thanks | 19:57 |
| * nxvl_work HUGS james_w | 19:57 | |
| nxvl_work | oh yes | 19:57 |
| Unksi | thank you :) | 19:58 |
| nxvl_work | another difference is that on Ubuntu we like to HUG each other a LOT! | 19:58 |
| nxvl_work | :D | 19:58 |
| nxvl_work | so, i think mathiaz is not here yet | 19:58 |
| nxvl_work | but the next talk would be on Server Team | 19:58 |
| * mathiaz looks around | 19:58 | |
| InsClusoe | Thanks.. | 19:58 |
| snhome | nxvl: consider yourself hugged :) | 19:58 |
| nxvl_work | mathiaz will explain you what is the work we are doing on the Server side of Ubuntu, what are our goals, an how to start working with us | 19:59 |
| nxvl_work | it will be a really nice talk | 19:59 |
| mathiaz | nxvl_work: great introduction ! Thanks. | 19:59 |
| nxvl_work | here he is! | 19:59 |
| mathiaz | so how is still around ? | 19:59 |
| nxvl_work | lets wave on mathiaz | 19:59 |
| * shujin waves | 20:00 | |
| * nijaba waves at mathiaz | 20:00 | |
| * jetsaredim waves | 20:00 | |
| * sommer wavings | 20:00 | |
| * cap10morgan waves too | 20:00 | |
| nxvl_work | \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ | 20:00 |
| * Unksi waves | 20:00 | |
| * Koon waves too | 20:00 | |
| * Gnine waves from ubucopter | 20:00 | |
| holloway | \m/ | 20:00 |
| === InsClusoe is now known as waves | ||
| mathiaz | after a couple of rather technical session about development, I'd like to take some time to present the Ubuntu Server Team. | 20:00 |
| === waves is now known as InsClusoe | ||
| * eddyMul waves | 20:00 | |
| mathiaz | who we are, what we're doing, and how you can get involved with the Server Team. | 20:01 |
| nxvl_work | mathiaz: did you want me to handle the cuestions? | 20:01 |
| nxvl_work | questions* | 20:01 |
| mathiaz | nxvl_work: if you could relay the questions from u-c-c it would be appreciated | 20:01 |
| nxvl_work | ok | 20:01 |
| nxvl_work | just ask if you want one | 20:01 |
| mathiaz | nxvl_work: thanks. :) | 20:01 |
| mathiaz | So who is the server team ? | 20:02 |
| mathiaz | you can find most of the information on our wiki pages : https://wiki.ubuntu.com/ServerTeam | 20:02 |
| nxvl_work | if i apear to be dead im on bathroom, just be patient | 20:02 |
| mathiaz | I've been part of the server team for almost a year now | 20:03 |
| mathiaz | and most of the people I've seen getting onboard share a common interest in server related software. | 20:03 |
| mathiaz | As a consequences we also tend to be interested in setups and configuration found in corporate enviornments, such as directory services (ldap and AD domain), web services or network authentication. | 20:04 |
| mathiaz | Let me introduce some key people to the server Team (by alphabetical order): | 20:05 |
| mathiaz | Adam Sommer, aka sommer | 20:05 |
| mathiaz | He is our documentation guru. | 20:05 |
| mathiaz | He's taken the task to review | 20:05 |
| mathiaz | and update the Server Guide for Hardy. | 20:05 |
| mathiaz | Thus he is also involved with the Documentation team. | 20:06 |
| mathiaz | Ante Karamatić - another long time contributor to the server team, ivoks. | 20:06 |
| mathiaz | Member of the MOTU team, he did some work on the apache package and the bacula package. | 20:07 |
| mathiaz | Chuck Short - zul - he maintains xen. | 20:07 |
| mathiaz | Kees Cook and Jamie Strandbodge are our security gurus. | 20:08 |
| mathiaz | They are the ones that keep your system safe at night ;) | 20:08 |
| mathiaz | They've started the Security Team recently: https://wiki.ubuntu.com/SecurityTeam | 20:08 |
| mathiaz | Michael Behrens - faulkes- | 20:08 |
| mathiaz | A recent contributor coming from the forums. | 20:09 |
| mathiaz | He's taken the role of the Forum Ambassador. | 20:09 |
| mathiaz | He's been lurking in the forums for quite some time and works on providing feedback from the Server forum. | 20:09 |
| mathiaz | Mathias Gug - mathiaz. Well that's me. | 20:10 |
| mathiaz | I've been doing some work on AppArmor and trying to get the Ubuntu Server Team up and running. | 20:10 |
| mathiaz | Neal McBurnett - long time contributor and interested in documentation and virtualization (such as Ubuntu JeOS). | 20:11 |
| mathiaz | Rick Clark - dendrobates. He is the techinical manager of the Server Team at Canonical. | 20:11 |
| mathiaz | Scott Kitterman - mainly interested by mail services. | 20:12 |
| mathiaz | if you're interested in | 20:12 |
| mathiaz | postfix or clamav he is the man to talk to | 20:12 |
| mathiaz | He is also an active member of the MOTU team and became a core-dev recently. | 20:12 |
| mathiaz | Soren Hansen - soren - our virtualization specialist. | 20:12 |
| mathiaz | He brought cool virtualization technology in Ubuntu for Hardy. | 20:13 |
| mathiaz | He is gonna run a session on this topic tomorrow IIRC. | 20:13 |
| mathiaz | So - these are some key people from the team and I've forgotten many others. | 20:14 |
| nxvl_work | mathiaz: tomorrow at 17 UTC | 20:14 |
| mathiaz | As you can see the group has a broad range of interests. | 20:14 |
| mathiaz | And most of use are actively involved in other teams of the Ubuntu project. | 20:15 |
| mathiaz | This is one of the caracteristic of the Server Team: we all share a common interest in server technologies, but have differents skills. | 20:15 |
| mathiaz | Being part of the team often means representing the Server Team in other areas of the Ubuntu project. | 20:16 |
| mathiaz | Being a contributor to the server team can be taken under different roles: | 20:16 |
| mathiaz | The helper answers questions on the ubuntu-server mailing list and the #ubuntu-server irc channel. | 20:16 |
| mathiaz | This is usually the first step and easiest one to take to start contributing to the server team. | 20:17 |
| mathiaz | Triagers digg into bugs the ubuntu-server LP team is subscribed to. | 20:17 |
| mathiaz | Out LP team is a bug contact for a list packages, such as samba, openldap, mysql or apache2. | 20:18 |
| mathiaz | The current list of packages can be found here: https://bugs.launchpad.net/~ubuntu-server/+packagebugs | 20:18 |
| mathiaz | The list will be expanded soon as soon as we've setup a dedicated mailing list for ubuntu-server bugs. | 20:19 |
| mathiaz | Usually we decide to target our efforts for bug triagging to one or two package for a week and discuss the outcome of our triagging effort during our weekly meeting. | 20:19 |
| mathiaz | The focus for this week is openldap. | 20:19 |
| mathiaz | Version 2.4 has been uploaded a couple of weeks ago and bugs have been filled as people start testing this new major version of openldap. | 20:20 |
| mathiaz | So if you have some experience in directory services, you can help us right now. | 20:20 |
| mathiaz | This is a great way to start with the LP bug tracker and doesn't require any knowledge of programming languages. | 20:20 |
| mathiaz | We're working closely with the BugSquad team - triaggers participate on the bugsquad mailint lists. | 20:21 |
| mathiaz | And once in a while with have the honor of having our own HugDay where the whole bug triagger community helps us. https://wiki.ubuntu.com/BugSquad/ | 20:21 |
| mathiaz | Once bugs have been triagged, it's time to fix them. | 20:22 |
| mathiaz | This is when the packagers | 20:22 |
| mathiaz | come into the game. | 20:22 |
| mathiaz | This role requires an interest in packaging. | 20:22 |
| mathiaz | We maintain a list of bugs that are easy too fix: https://bugs.launchpad.net/~ubuntu-server/+mentoring | 20:22 |
| mathiaz | These fixes can make their way easily into the ubuntu repositories via the sponsorship process | 20:23 |
| mathiaz | https://wiki.ubuntu.com/SponsorshipProcess | 20:23 |
| 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. | 20:24 |
| mathiaz | https://wiki.ubuntu.com/MOTU | 20:24 |
| mathiaz | Another role that kicks in on a regular schedule are the testers. | 20:24 |
| mathiaz | New features and new packages needs to be tested before released for wide spread consumption. | 20:25 |
| mathiaz | Thus we organize test plans. | 20:25 |
| mathiaz | For example, likewise-open has been uploaded to universe. | 20:26 |
| mathiaz | It provides AD directory integration. However there are lot's of different AD setups. | 20:26 |
| mathiaz | So we'll setup a test plan to keep track of the results. | 20:26 |
| mathiaz | If you have access to an AD domain, installing ubuntu and testing you can join the domain with likewise-open is an easy way to contribute to the Server Team right now. | 20:27 |
| mathiaz | Testing plans are coordinated with the Ubuntu QA Team - https://wiki.ubuntu.com/QATeam | 20:27 |
| mathiaz | Testers are taking an important role when we're about to ship a new milestone or release. | 20:27 |
| mathiaz | We're responsible for ensuring that the ubuntu-server isos are working correctly, which involves performing a dozen of tests for three isos. | 20:28 |
| mathiaz | We use the isotesting tracker from the QA team to track the results. The more testers we have, the less tests each of us has to do and results are posted faster. | 20:29 |
| mathiaz | Server hardware support is another area where testing is important. | 20:29 |
| 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 sucessfully installed or failed is an easy way to contribute to the server team. | 20:29 |
| mathiaz | An additional process to the testing of a feature is documenting it. | 20:31 |
| mathiaz | That's the role of the Documentors. | 20:31 |
| 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. | 20:31 |
| mathiaz | Recurring themes are identified and turned into documentation. | 20:32 |
| mathiaz | A wiki page in the community section of help.ubuntu.com is first created. | 20:32 |
| mathiaz | Once the quality has improved, a new section is added to the server guide. | 20:32 |
| mathiaz | All this work is undertaken by the Documentors of the Server Team. | 20:32 |
| mathiaz | Collaboration with the Documentation team is done on a daily basis to achieve consistency with other help ressources. | 20:32 |
| mathiaz | Adam Sommer started to update and review the Server guide for Hardy. | 20:33 |
| mathiaz | The document is maintained in a bzr tree - helping adam will introduce you to docbook and distributed version control with bazaar. | 20:33 |
| mathiaz | There is also the option to go over server related wiki pages on the community help pages. | 20:33 |
| mathiaz | A good starting point is the Server page that has pointer to lots of howtos. | 20:34 |
| mathiaz | https://help.ubuntu.com/community/Servers | 20:34 |
| mathiaz | And the last role in the Server Team are the Developers. | 20:35 |
| mathiaz | they develop new features, usually specified during the Ubuntu Developer Summit that takes place at the begining of each release cycle. | 20:35 |
| mathiaz | Tracked by a blueprint we have around 3 months to get a new feature into ubuntu. | 20:35 |
| mathiaz | For hardy, virtualization, iscsi and windows integration have been some of the features integrated. | 20:36 |
| mathiaz | Now that Feature Freeze is in place, we've moved our focus to testing and bug fixing. | 20:36 |
| mathiaz | Thus the developers won't be very active until we release hardy at the end of april. | 20:36 |
| mathiaz | As you can see, contributing to the Server Team can be undertaken in more than one way. | 20:36 |
| mathiaz | It usually involves a lot of interaction with other teams from the Ubuntu project. | 20:37 |
| mathiaz | It's also a good way to show your contribution to Ubuntu and thus helps getting Ubuntu membership. | 20:37 |
| mathiaz | The GettingInvolved page gives an overview of the roles I've talked about above. | 20:37 |
| mathiaz | https://wiki.ubuntu.com/ServerTeam/GettingInvolved | 20:37 |
| mathiaz | So - how do we work ? | 20:38 |
| mathiaz | We track our progress on the Roadmap and meet once a week to discuss outstanding issues. | 20:38 |
| mathiaz | https://wiki.ubuntu.com/ServerTeam/Roadmap | 20:38 |
| mathiaz | We use the ubuntu-server mailing and #ubuntu-server to coordinate our activities, discuss policy change in the team. | 20:39 |
| mathiaz | Joining the ubuntu-server team on LP is simple as subscribing to the ubuntu-server mailing list and applying for membership on LP. | 20:39 |
| mathiaz | The ubuntu-server team is one of the easiest way to start getting involved in Ubuntu development. | 20:40 |
| mathiaz | So If you already know which role you'd like to contribute as, you can find a list of tasks in the Roadmap. | 20:41 |
| mathiaz | Don't hesitate to ask one of the team members involved in your area of interest. | 20:41 |
| mathiaz | Refer to the key people I've listed above. | 20:42 |
| mathiaz | Most of the information related to the ServerTeam can be found in the ServerTeam wiki pages: https://wiki.ubuntu.com/ServerTeam | 20:42 |
| mathiaz | If you're overwhelmed by all the available information and you're lost, come talk to me - mathiaz on irc or mathiaz@ubuntu.com. | 20:43 |
| mathiaz | I'll help getting started. | 20:43 |
| nxvl_work | mathiaz: ready for questions? | 20:43 |
| mathiaz | Well - that's all that I wanted to say about the server team. | 20:44 |
| mathiaz | nxvl_work: yes - please go ahead. | 20:44 |
| nxvl_work | <eddyMul> QUESTION: can you talk a bit about canonical "Landscape"? | 20:44 |
| mathiaz | eddyMul: This is a product in beta mode developed by a team within canonical. | 20:44 |
| mathiaz | eddyMul: I'm not actively involved in the project so I don't really know much about it. | 20:45 |
| mathiaz | eddyMul: you can contact nijaba - he should be able to give more information. | 20:45 |
| mathiaz | nxvl_work: next | 20:46 |
| nxvl_work | <Unksi> QUESTION: Any estimates how many servers run Ubuntu, as Ubuntu is quite new player in the server market (Compared to Debian, Red Hat and other big distros on the server field) | 20:46 |
| nxvl_work | <Unksi> QUESTION: What are the main differences with Ubuntu Server edition and Debian? What makes it worth to run Ubuntu instead Debian, except the "Ubuntu Spirit"? | 20:46 |
| nxvl_work | this 2 ones are basically related | 20:47 |
| mathiaz | Unksi: I don't have an estimate. We've seen a rising number of ubuntu server adoption. | 20:47 |
| Unksi | ok | 20:47 |
| mathiaz | Unksi: we're based on Debian, which is a very strong technical platform. | 20:48 |
| mathiaz | Unksi: within the server team, we're working well with Debian and most of our changes are merged by in Debian. | 20:49 |
| mathiaz | Unksi: Ubuntu provides guaranted security updates, even thought Debian is doing an excellent work on this front. | 20:50 |
| mathiaz | Unksi: Ubuntu, via Canonical, is also more easily approachable by companies. | 20:50 |
| mathiaz | Unksi: there is a partner's program available and propritary software can be integrated in Ubuntu via this channel. | 20:51 |
| mathiaz | Unksi: as for rates of adoption, there is the Alfresco borometer that gives some numbers about the adoption of ubuntu in that community. | 20:53 |
| mathiaz | Unksi: http://www.alfresco.com/community/barometer/ | 20:53 |
| mathiaz | nxvl_work: next. | 20:53 |
| Unksi | ok, thank you | 20:53 |
| nxvl_work | <pwnguin> QUESTION: Is server edition appropriate for beowulf clusters? | 20:53 |
| mathiaz | pwnguin: certainly. One great asset of ubuntu server is that the basic install is small. | 20:54 |
| mathiaz | pwnguin: so customizing it for your specific cluster needs is easier. | 20:55 |
| mathiaz | pwnguin: there is also the preseeding mechanism available for mass intallation. | 20:55 |
| mathiaz | nxvl_work: next | 20:56 |
| nxvl_work | <shujin> QUESTION: Is there anyone looking into the Ubuntu Home Server idea? | 20:56 |
| mathiaz | shujin: it depends what you mean by Ubuntu Home Server. I assume you refer to using a web interface to manage your box. | 20:57 |
| mathiaz | shujin: there is work done to integrate ebox. | 20:57 |
| mathiaz | nxvl_work: next. | 20:57 |
| nxvl_work | <eddyMul> QUESTION: can you talk more about isotesting tracker? | 20:57 |
| mathiaz | eddyMul: the isotesting tracker is a website used by the QA team and the release when we're about to publish a new iso. | 20:58 |
| mathiaz | eddyMul: http://iso.qa.ubuntu.com/ | 20:59 |
| mathiaz | eddyMul: it's also used by other teams such as the mozilla team to keep track of testing for new builds. | 20:59 |
| mathiaz | eddyMul: basically, it's a list of tests and sucess/failure results. | 20:59 |
| mathiaz | nxvl_work: next. | 21:00 |
| eddyMul | mathiaz: interesting. will dig into this a bit more.... | 21:00 |
| nxvl_work | <cap10morgan> QUESTION: Are there plans to do other works-out-of-the-box style setups w/ the server installer like the LAMP installation option? (I'm thinking things like NT domain / AD controller, assuming Samba et. al. are up to the task) | 21:00 |
| mathiaz | cap10morgan: this a work in progress. | 21:00 |
| mathiaz | cap10morgan: we've already added 5-6 tasks during gutsy: samba server, postgresql server, mail server to name a few. | 21:01 |
| mathiaz | cap10morgan: hopefully we'll be able to join a domain soon at install time. | 21:01 |
| mathiaz | cap10morgan: now that likewise-open has been published in universe, it needs more testing. | 21:02 |
| cap10morgan | soon as in hardy or hardy+1? | 21:02 |
| mathiaz | cap10morgan: and once it's move to main, we can integrate into the installer. | 21:02 |
| mathiaz | cap10morgan: it depends how well the testing goes. | 21:02 |
| cap10morgan | ok | 21:02 |
| mathiaz | cap10morgan: if we have a lot of tests and we're confident that likewise-open is stable, then we can try to move it to main for hardy and get it into the installer. | 21:03 |
| mathiaz | cap10morgan: however we're already past FeatureFreeze - so things are more complicated. | 21:03 |
| cap10morgan | so what you're saying is, i should help test likewise-open :) | 21:03 |
| mathiaz | cap10morgan: yes. | 21:03 |
| mathiaz | and other too :) | 21:03 |
| mathiaz | nxvl_work: next | 21:04 |
| nxvl_work | <crevette> QUESTION: Don't you feel this is an hard task, to have only 6 months cycle to provide a server distribution; aimed on reliability; when others (debian, RH) take several years without releasing a version | 21:04 |
| mathiaz | crevette: that's why we've introduced the concept of LTS releases. | 21:04 |
| mathiaz | crevette: companies are looking for a fixed schedule so that they can plan their upgrade. | 21:05 |
| mathiaz | crevette: in the case of debian, it's hard to know when the actual release will be done. | 21:05 |
| mathiaz | crevette: in the case of RH, they've introduced new features in their service packs (or whatever it's called) | 21:06 |
| mathiaz | crevette: As we're preparing for an LTS release, we've also been more conservative in the changes we've implemented for this release. | 21:07 |
| mathiaz | nxvl_work: next. | 21:07 |
| nxvl_work | <mzungu> QUESTION: Will hardy be a direct upgrade for a server currently running dapper, or does it have to go through edgy->feisty->gutsy? | 21:07 |
| mathiaz | mzungu: dapper->hardy will be supported | 21:08 |
| mathiaz | nxvl_work: next | 21:08 |
| nxvl_work | <eddyMul> QUESTION: how different is Ubuntu JeOS default install from Ubuntu Server Edition's default install? | 21:08 |
| mathiaz | eddyMul: the main difference is in the kernel flavour installed. | 21:08 |
| mathiaz | eddyMul: JeOS installs a the -virtual flavour, which is a kernel that hasn't all the drivers available. | 21:09 |
| eddyMul | is JeOS optimized for Xen? KVM? | 21:09 |
| mathiaz | eddyMul: the installed system is also smaller - only the -base seed is installed IIRC | 21:09 |
| mathiaz | eddyMul: Not that I remember of. | 21:10 |
| mathiaz | eddyMul: I think it has the open-vm-tools available. | 21:10 |
| sergevn | mathiaz: So JeOS is meant for inside an virtual machine, not as host OS? | 21:10 |
| mathiaz | sergevn: yes - JeOS is tuned to run a guest. | 21:10 |
| mathiaz | sergevn: hardy server will have great support for virtualization as a host. | 21:11 |
| eddyMul | thanx, mathiaz & sergevn | 21:11 |
| mathiaz | nxvl_work: next ? | 21:11 |
| nxvl_work | <leonel> QUESTION: Can it be added a LAPD ( Linux Apache PostgreSQL Django ) to tasksel like theres a LAMP ? | 21:11 |
| nxvl_work | one more left and we are done | 21:11 |
| mathiaz | leonel: I'm not sure it's such a common scenario. We don't want to have a list of hundreds of profile available during installation. | 21:12 |
| mathiaz | nxvl_work: next | 21:13 |
| nxvl_work | <shujin> QUESTION: This may be off topic, but any reason eBox was chosen over Webmin? | 21:13 |
| nxvl_work | las one! | 21:13 |
| nxvl_work | last* | 21:13 |
| mathiaz | !webmin | shujin | 21:13 |
| ubotu | shujin: webmin is no longer supported in Debian and Ubuntu. It is not compatible with the way that Ubuntu packages handle configuration files, and is likely to cause unexpected issues with your system. See !ebox instead. | 21:13 |
| eddyMul | mathiaz, ubotu: nice! :) | 21:14 |
| nxvl_work | thats why i love ubotu | 21:14 |
| shujin | ouch, I have a 15 servers running webmin | 21:14 |
| mathiaz | Well - I think that's all for today. | 21:14 |
| shujin | thanks mathiaz! | 21:14 |
| mathiaz | Thanks for attending this session about ubuntu server team | 21:14 |
| eddyMul | thanx, mathiaz | 21:15 |
| Unksi | mathiaz: thank you :) | 21:15 |
| mathiaz | it's also the last session of the first day of the Ubuntu Developer week. | 21:15 |
| eddyMul | and nxvl_work, too | 21:15 |
| * nxvl_work waves | 21:15 | |
| mathiaz | There is more to come during the whole week. | 21:15 |
| nxvl_work | and dances \o> <o> \o/ <o/ \o> | 21:16 |
| mzungu | thanks mathiaz | 21:16 |
| sergevn | mathiaz: Where can I find more info about the Ubuntu Week? | 21:16 |
| holloway | mathiaz, thank you for the view about your team :) | 21:16 |
| arturodr | thanks | 21:16 |
| mathiaz | soren will talk about virtualization tomorrow and dholbach about MOTU. | 21:16 |
| mathiaz | More information: https://wiki.ubuntu.com/UbuntuDeveloperWeek | 21:16 |
| mathiaz | sergevn: ^^ | 21:16 |
| InsClusoe | Thanks to all of you Ubuntu folks... | 21:17 |
| mathiaz | Thanks all - and I hope to see you soon onboard the Ubuntu Development team ! :) | 21:17 |
| InsClusoe | It has been an evening well-spent. | 21:17 |
| nxvl_work | btw | 21:18 |
| nxvl_work | join the 5-A-Day cause | 21:18 |
| sergevn | InsClusoe: Indeed, didnt knew about this untill I got the invite trough #ubuntu-server ^^ | 21:18 |
| nxvl_work | http://nvalcarcel.aureal.com.pe/?p=171 | 21:18 |
| InsClusoe | Sergevn: Don't worry... The first two sessions are repeated on Friday as well. So you haven't missed a lot. | 21:19 |
| holloway | and also there are the logs :) | 21:19 |
| soneil | how are these weeks usually announced? I caught it by chance on the planet this morning, else I'd have no idea | 21:20 |
| InsClusoe | soneil: This is the first such week, I believe. | 21:20 |
| soneil | ah, ok. just wondering if there's a list I should have been paying more attention to | 21:21 |
| InsClusoe | nxvl_work: I am willing to join 5-A-Day. | 21:21 |
| nxvl_work | InsClusoe: is not hard, just take a look and triage them | 21:21 |
| InsClusoe | Hmm... I will try from this week with an initial target of 5-A-Week. | 21:23 |
| InsClusoe | soneil: I saw it first on Ubuntuforums' Packaging and Compiling Programs message board first. | 21:23 |
| nxvl_work | InsClusoe: triage is just ask for help, reproduce bugs and confirm them | 21:24 |
| nxvl_work | InsClusoe: so you can start with that, just takes 5 minutes each bug | 21:24 |
| InsClusoe | nxvl_work: ok.. I can definitely do that everyday then. Guess I can take help on #ubuntu-devel or #ubuntu-motu whenever needed. | 21:25 |
| InsClusoe | See you all tomorrow. Have a nice day/evening/night wherever you are. | 21:28 |
| nxvl_work | InsClusoe: yep, just ask on #ubuntu-bugs or #ubuntu-motu | 21:29 |
| holloway | cya InsClusoe :) | 21:29 |
| Xk2c | bye | 21:37 |
| sergevn | Tomorrows session(s) are also in #ubuntu-classroom? | 21:58 |
| lamalex | aren't there sessions today? | 21:58 |
| mathiaz | sergevn: yes - they're also here. | 21:59 |
| mathiaz | lamalex: today's session have already finished. | 21:59 |
| mathiaz | lamalex: https://wiki.ubuntu.com/UbuntuDeveloperWeek | 21:59 |
| mathiaz | lamalex: ^^ has the schedule | 21:59 |
| lamalex | hm I thought I saw packaging was at 1700 | 22:00 |
| mathiaz | lamalex: 1700 UTC | 22:01 |
| lamalex | :P I just did my math wrong | 22:01 |
| lamalex | bummer, I can't make any of these | 22:02 |
| sergevn | are there also logs available for these sessions? | 22:04 |
| antcarsa | sure, https://wiki.ubuntu.com/MeetingLogs/devweek0802/PPAs1 | 22:05 |
| sergevn | antcarsa: thx :) | 22:07 |
| rzr | hi | 22:20 |
| === catsk1n is now known as jimqode | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!