=== mruiz_away is now known as mruiz === bmk789_ is now known as bmk789 [05:10] hi === asac_ is now known as asac [15:55] * pitti waves [15:56] * InsClusoe waves back.. [15:56] * db-keen stands aghast to be in the presence of InsClusoe [15:57] db-keen: Pls don't say such things and embarass me... [15:59] * pitti rings the schoolbell [15:59] welcome! [15:59] so, who is here to learn about patching packages? [16:00] and how has the week been so far for you? [16:00] +1 [16:00] o/ [16:00] I'm no programmer, just curious [16:00] +1 === warp10 is now known as warp10_ [16:00] Haven't had much time to follow other lessons, but plan to do so today. Great sessions ahead. :) [16:00] hey hey [16:01] * warp10_ raises an hand [16:01] cool, relatively quiet === warp10_ is now known as warp10 [16:01] Welcome to the hands-on training session about how to patch Ubuntu source packages! [16:01] This assumes that you already know what a patch is and how to handle .patch files in general (i. e. for upstream authors). Also, you should have a rough idea what an Ubuntu source package is. [16:02] The purpose of this session is to teach you how to put a patch into an Ubuntu source package, since unlike rpm this is not very consistent still. [16:02] While I do some introduction, please install some packages and sources on your box which we will need for the training: [16:02] sudo apt-get install dpatch cdbs quilt patchutils devscripts debhelper fakeroot [16:02] mkdir training; cd training [16:02] apt-get source cron udev pmount ed xterm [16:02] wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch [16:02] chmod 755 dsrc-new-patch [16:02] I deliberately picked the smallest packages I could find [16:03] this can run in the background while I continue [16:03] 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:03] 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:03] ok everyone? [16:04] +1 [16:04] Let's begin with a little bit of history: [16:04] ok! [16:04] Almost set. [16:04] done [16:04] == Why use separate patches == [16:04] 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:04] 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:05] The ideal state is an unmodified tarball from upstream, plus clean and separate patches, plus the packaging bits in debian/. That means that lsdiff -z .diff.gz only contains debian/. [16:05] 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:05] (debian/rules is the central script for building a package, in case you don't know) [16:06] Thus several standard patch systems were created which are easy to deploy and provide tools for patch juggling and editing. [16:06] -- [16:06] 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:06] 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. [16:06] 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:06] is everyone fine with this approach? [16:07] k [16:07] yep! [16:07] Sure. [16:07] +1 [16:07] = cron: inline patches == [16:07] No patch system at all, nothing much to say about this. So this is an example of the "old" style of packaging, a counter-example [16:07] You directly edit the files in the source tree. [16:07] 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:08] if you do 'lsdiff -z .diff.gz' and you see changes which are not in debian/, then you probably have such a package [16:08] i. e. in this case lsdiff -z cron*.diff.gz [16:08] (you can also take a look at it to see how all patches are lumped together) [16:08] so, I think I do not need to say anything else about cron, unless someone has a question [16:09] == udev: separate patches, but no standard patch system == [16:09] This case is the most complicated one since you have to do all the hard work manually. [16:09] 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:09] 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:09] 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:10] BTW; when I'm too fast, don't hesitate to ping [16:10] 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:10] The general approach, which you can print out and hang over your desk :) is: [16:10] 1. copy the clean source tree to a temporary directory /tmp/old [16:11] 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:11] 3. copy the whole source tree again: cp -a /tmp/old /tmp/new [16:11] 4. go into /tmp/new, do your modifications [16:11] 5. go back into /tmp and generate the patch with [16:11] diff -Nurp old new > mypatchname.patch [16:11] 6. move the newly generated patch to /debian/patches/mypatchname.patch [16:12] in general we want the following diff options: [16:12] -N -> include new files [16:12] -u -> unified patches (context diffs are ugly) [16:12] -r -> recursive [16:12] -p -> bonus, you can see the name of the affected function in the patch [16:12] does anyone have a question about the principle method? [16:12] (I'll do a hands-on example now) [16:13] All good here. [16:13] here too [16:13] same here [16:13] so, open a shell, ready your fingers :) [16:13] udev example 1, let's create a new patch 92_penguins.patch: [16:13] cd udev-* # -113 on gutsy, -117 on hardy [16:13] -> now we are in our original source tree where we want to add a new patch [16:14] cp -a . /tmp/old [16:14] -> create a copy of the clean sources as reference tree [16:14] pushd /tmp/old [16:14] -> go to /tmp/old; 'pushd' to remember the previous directory, so that we can go back conveniently [16:14] debian/rules patch [16:14] -> 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:15] cp -a . /tmp/new; cd ../new [16:15] -> copies our patched reference tree to our new work directory /tmp/new where we can hack in [16:15] that's the preparatory part [16:15] let's do a braindead modification now [16:15] sed -i 's/Linux/Penguin/g' README [16:15] -> changes the README file; of course you can use your favourite editor, but I wanted to keep my examples copy&pasteable [16:15] and now we create a patch between the reference and our new tree: [16:16] cd .. [16:16] -> go back to /tmp, i. e. where our reference tree (old) and hacked tree (new) is located [16:16] diff -Nurp old new > 95_penguins.patch [16:16] -> generate the patch (Ignore the 'recursive directory loop' warnings) [16:16] popd [16:16] -> now you should be back in your original source tree (when you did the pushd) [16:16] rm -rf /tmp/old /tmp/new [16:16] -> clean up the temporary trees [16:16] mv /tmp/95_penguins.patch debian/patches [16:16] -> move the patch from /tmp to the source tree's patch directory, where it belongs. [16:16] *uff* :) [16:16] Now take a look at your shiny new debian/patches/95_penguins.patch. [16:17] and give a ping when you are ready [16:17] * warp10 is ready [16:17] ping [16:17] +1 [16:18] great, that goes very smoothly today :) [16:18] if you do 'debian/rules patch', you'll see that the patch applies cleanly [16:18] warp10, AstralJava, dargol, db-keen: caught up? [16:19] pitti: sure! [16:19] yep [16:19] yep [16:19] Yeah, sorry was AFK for a bit. [16:20] awesome [16:20] 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:20] +1 [16:20] so this procedure is the life safer if anything else fails [16:20] questions so far? [16:20] Nope. :) [16:20] (just drop them into #-chat) [16:20] 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:21] First, let's bring back udev to the previous state by removing the source tree and re-unpacking the source package: [16:21] cd .. [16:21] rm -r udev-* [16:21] dpkg-source -x udev_*.dsc [16:21] Then, using my script, above steps would reduce to: [16:21] cd udev-* [16:21] ../dsrc-new-patch 95_penguins.patch [16:22] ^ this now does all the preparation for you and drops you into a shell where you can edit the code [16:22] sed -i 's/Linux/Penguin/g' README [16:22] [16:22] that looks slightly better, doesn't it? [16:23] look at debian/patches/95_penguins.patch, it should look exactly like the one created manually [16:23] If you like the script, please put it into your ~/bin, so that it is in your $PATH [16:23] but I had to torture you with the close-to-the-metal method for the sake of understanding. [16:23] You might have noticed that we applied all previous patches before creating our's. Does someone have an idea why this is done? [16:24] some patches could depend on other patches [16:24] which means? [16:24] They need to be applied in order. [16:24] correct order, that is. [16:24] they coud only aply to the patched source [16:25] 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:25] dargol: exactly [16:25] 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:25] with that script I won't need dpatch-edit-patch anymore ;) [16:25] pochu: oh, you do [16:25] we'll get to that later [16:25] oh [16:26] dsrc-new-patch is a hack which mostly works for packages without a real patch system, but split-out patches [16:26] like udev [16:26] (which is really a bug we should fix) [16:26] but makes a nice example :-P [16:26] Since above procedure is so hideously complicated, patch systems were invented to aid you with that. [16:26] 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:26] exit [16:26] ah, found it [16:26] (sorry) [16:26] dargol: ? [16:26] ok [16:27] == pmount: cdbs with simple-patchsys == [16:27] (wrong place) [16:27] cdbs' simple-patchsys.mk module matches its name, it has no bells and whistles whatsoever. [16:27] However, it is pretty popular since it is sufficient for most tasks [16:27] and long ago I wrote a script 'cdbs-edit-patch' which most people can live with pretty well. [16:27] This script is contained in the normal cdbs package. [16:27] 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:28] (dsrc-new-patch can currently *not* edit existing patches, mind you; patches welcome :-) [16:28] but real patch systems can do that of course [16:28] cd pmount-* [16:28] everyone please look in debian/patches, debian/rules to get a feeling how it looks like [16:28] i. e. in debian/rules you simply include simple-patchsys.mk, and that'll do all the magic [16:28] and debian/patches looks pretty much like udev [16:29] so, let's mess up pmount a bit [16:29] and add a new patch [16:29] cdbs-edit-patch 07-simple-readme.patch [16:29] echo 'This should document pmount' > README [16:29] [16:29] easy, isn't it? [16:29] 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:31] Editing an already existing patch works exactly the same way. [16:31] so I won't give a demo [16:31] BTW, "cdbs-edit-patch" is slightly misleading, since it actually only applies to simple-patchsys.mk. You can also use other cdbs patch system plugins, such as dpatch or quilt. [16:31] questions? [16:32] Nothing at the moment, no. :) [16:32] (sorry, some #-chat action going on) [16:32] All good, all good. :) [16:32] == ed: dpatch == [16:32] dpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch' [16:32] packages which use this build-depend on 'dpatch', and debian/rules includes 'dpatch.mk' [16:33] The two most important things you should be aware of: [16:33] * 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:34] (forgetting to update 00list is a common cause of followup uploads :-) ) [16:34] * dpatch patches are actually scripts that are executed, not just patches fed to 'patch'. That means you can also do fancy things like calling autoconf or using sed in a dpatch if you want. [16:34] using dpatch for non-native patches is rare, and normally you do not need to worry about how a .dpatch file looks like [16:34] but I think it's important to mention it [16:35] so if you ever want to replace *all* instances of Debian with Ubuntu in all files, write a dpatch with a small shell script that uses sed [16:35] instead of doing a 300 KB static patch which won't apply to the next version anyway [16:35] The manpage is very good and has examples, too, so I will only give one example here: [16:35] This will edit an already existing patch and take care that all previous patches are applied in order: [16:35] cd /whereever/you/unpacked/the/source/ed-0.7 [16:36] (if you are still in the pmount directory: cd ../ed-0.7) [16:36] dpatch-edit-patch 05_ed.1-warning-fix [16:36] [16:36] so that's exactly like cdbs-edit-patch [16:36] ok, now we edited a patch, that's pretty easy, right? [16:37] now let's create a new one; this is different from cdbs-e-p [16:37] dpatch-edit-patch foo 07_ed.1-spelling-fixes [16:37] [16:37] echo foo.dpatch >> debian/patches/00list [16:37] ^ this is the new bit; you have to explicitly add a new patch to that 00list index file [16:38] This will create a new patch foo.dpatch relative to the already existing 07_ed.1-spelling-fixes.dpatch. [16:38] If your patch is very confined and does not depend on other patches, you can leave out the second argument. [16:38] BTW, you even have bash commandline completion for dpatch-edit-patch! [16:38] alright? [16:38] yeah [16:39] y [16:39] k [16:39] Fine here. :) [16:39] db-keen, phoenix24: ok? [16:39] Yep! [16:40] == xterm: quilt == [16:40] quilt is the other non-dumb standard patch system. Like dpatch, it has a list of patches to apply in patches/series (to use debian/patches, packages need to add a sylink). [16:41] or set $QUILT_PATCHES to debian/patches [16:41] It is non-trivial to set up and has a lot of advanced commands which make it very flexible, but not very easy to use. [16:41] nontrivial to set up for Debian source packages, that is [16:41] (it's not hard either, but more work than simple-patchsys, and even dpatch) [16:41] it's not that widespread, but common enough to handle it here, and it apparently gains more popularity [16:41] I will only show a small example here [16:42] cd /whereever/you/unpacked/the/source/xterm-229 [16:42] if you followed me exactly, that should be cd ../xterm-229 [16:42] export QUILT_PATCHES=debian/patches [16:42] This is necessary because the default patch directory for quilt is ./patches. But for Debian-style source packages we want to keep them in debian/patches, because that's the convention. [16:42] Now let's edit the already existing patch 901_xterm_manpage.diff: [16:42] quilt push 901_xterm_manpage.diff [16:43] this will apply all patches in the stack up to the given one [16:43] apply inline right in the source tree, that is [16:43] unlike quilt, cdbs-edit-pattch, and dpatch-edit-patch, quilt doesn't create temporary directories with a copy, but remembers old versions of the files and uses the normal working tree [16:43] a bit like version control (svn, bzr, etc.) [16:43] now let's edit a file that is already touched by the original patch [16:44] sed -i 's/Copyright/Copyleft/' xterm.man [16:44] let's commit the change: [16:44] quilt refresh 901_xterm_manpage.diff [16:44] ^ updates the patch file with your recent changes [16:44] quilt pop -a [16:44] ^ unapplies all patches to go back to pristine source tree [16:45] * pitti waits a bit for people to catch up and finish the example on their keyboards [16:45] ok everyone? [16:45] done [16:45] yep, done [16:45] Done. [16:45] y [16:45] look at debian/patches/901_xterm_manpage.diff to see the effect [16:45] #join ubuntu-classroom-chat [16:45] * pitti hands cprov-out a slash [16:45] sorry ... [16:46] Finally, let's add a new patch to the top of the stack: [16:46] Done1 [16:46] pitti: thanks ;) [16:46] quilt push -a [16:46] '-a' means 'all patches', thus it applies all further patches after 901_xterm_manpage.diff up to the top [16:46] quilt new muhaha.diff [16:46] register a new patch name (which we want to put on top of the patch stack) [16:46] quilt add README [16:46] you have to do that for all files you modify, so that quilt can keep track of the original version [16:46] this tells quilt to keep track of the original version of README [16:47] sed -i '1 s/^/MUHAHA/' README [16:47] modify the source [16:47] quilt refresh [16:47] update the currently edited patch [16:47] quilt pop -a [16:47] this will finally create debian/patches/muhaha.diff with the changes to README [16:47] as I already said above, quilt has a patch list, too [16:47] in debian/patches/series [16:48] which is much like debian/patches/00list for dpatch [16:48] except that you don't edit it manually usually [16:48] if you push -a, then the patch will land on top of the patch stack, and will automatically be put at the end of series [16:48] of course you can create the patch in other levels of the patch stack [16:48] sometimes, when you pull changes from upstream CVS, it's better to put them at the bottom of the stack [16:48] i. e. upstream changes shuold generally come *before* distro-specific changes [16:48] someone has an idea why this is done? [16:49] or, rather, should be done [16:50] same as before, upstream changes are only guarantied to work on original source [16:50] first that [16:50] and second, it forces you to port your local patches to the updated source [16:51] so that, when you update to a new upstream version which incorporates the patch, it's much easier [16:51] i. e. the closer to upstream a patch is, the more stable are your distro patches [16:52] ok, that was the hard bit :) [16:52] == A glimpse into the future === [16:52] As you saw, Debian source packages do not have any requirements wrt. structure, patch systems, etc. [16:52] other source package systems like SRPM are much stricter wrt that. [16:52] This of course means more flexibility, but also much more learning overhead. [16:52] As a member of the security team I can tell tales of the pain of a gazillion different source package layouts... :) [16:53] there has been an attempt to teach an official patch system to dpkg itself ("dpkg 2.0", aka. "Wig&Pen format") [16:53] but unfortunately development on it has ceased [16:53] Therefore some clever people sat together the other day to propose a new design which would both give us a new and unified source package and patch system that uses bzr (with a quilt-like workflow). [16:53] This would also integrate packages and patches much better into Launchpad and revision control in general. [16:54] Please take a look at https://wiki.ubuntu.com/NoMoreSourcePackages if you are interested in this. [16:54] -- [16:54] so, thanks a lot for your attention! [16:54] I hope it was a bit useful for you [16:54] we have five more minutes for Q+A [16:55] https://wiki.ubuntu.com/PackagingGuide/PatchSystems is some written documentation about patch systems [16:55] a nice reference about what I explained here [16:56] Can't come up with any questions really at this point, but thanks very much Martin for this session! :) Highly beneficial to over the steps in correct order and manner. :) [16:56] warp10| QUESTION: If I need to apply a patch to a brand new package, or to fix a bug, or whatever, and a patchsystem has not been deployed yet, which (or how) should I choose? [16:56] that's mostly a matter of taste [16:56] if adding a patch system is actually justified in terms of keeping the delta to Debian low, then I'd give the following guidelines: [16:57] * if the package already uses cdbs, simply include simple-patchsys.mk and add the patch [16:57] no question with this, that's unintrusive [16:57] * if the package doesn't use cdbs, and you get along with dpatch, use that [16:58] (please ask questions here now) [16:58] ETA for NoMoreSourcePackages is currently undefined [16:58] right now we try to push forward the complete bzr import of ubuntu packages [16:58] which is a first step [16:58] QUESTION: do you know where to find some good documentation regarding working with .rej files? (as we don't have time now to explain it) [16:58] I don't know docs, sorry [16:59] because at that point it's really common sense and experience [16:59] if there was a programmatic way how to resolve them, we wouldn't need them in the first place :) [16:59] cdbs-edit-patch and dpatch-edit-patch will deal with it [16:59] i. e. if a patch doesn't apply, they give you the .rej, you resolve them manually and Ctrl+D [16:59] that's what I mean, how to resolve them [17:00] make sure to delete the .rej after resolving [17:00] they deliberately don't ignore .rej files [17:00] just to make sure you don't accidentally overlooked them [17:00] ok, my time is up [17:00] thank you for the class! [17:00] thanks pitti [17:00] thanks pitti [17:00] please continue questions to me personally or in -chat [17:00] Thanks again, that was super. :) [17:00] thanks everyone! [17:01] thank you pitti, that was very interesting :) [17:01] pitti: great, thank you. [17:01] thanks pitti!! [17:01] right, about time to start PPA session ... [17:02] Who is here for the PPA session (take 2) ? (say +1) [17:02] +1 [17:02] +1 [17:02] o/ [17:02] +1 [17:02] +1 [17:02] +1 [17:03] +1 [17:03] I will sit this one out, sorry [17:03] +1 [17:03] well, I guess, we have to continue with a smaller audience that the last session ... np [17:04] so questions can be asked in #ubuntu-classroom-chat ... [17:04] In the last session, we have started with the 3W approach (WHAT - WHERE - WAIT) to teach people how to use PPAs. See the session transcription in https://wiki.ubuntu.com/MeetingLogs/devweek0802/PPAs1. [17:04] As a brief summary of the PPA cycle: [17:04] * WHAT: signed source uploads (reusing orig.tar.gz from ubuntu Primary archive); [17:04] * WHERE: tell dput to upload it to ppa.launchpad.net (override changesfile target if you want); [17:04] * WAIT: wait the source to be built (restart the cycle if you received a build-failure-notification). [17:05] I'm very happy to say that the last LP release (done on Wednesday) make the 'WAIT' stage very shorter [17:06] now a build request is queued immediately after we recognize the new source, so the only waiting involved in the PPA cycle is related to the buildfarm load [17:06] we currently have 3 i386, 3 amd64 and 3 lpia builder, which is quite enough to make everyone happy :) [17:07] sorry, 'LP release' was a confusing term [17:07] I was referring to the last Launchpad codeline release, which happened 2 days ago [17:08] a new set of features in Launchpad is released every month ... [17:09] PPAs ... Let's sort some questions, I don't believe you don' t have any ? [17:09] phoenix24: QUESTION: Could you tell a little about PPA ? [17:10] Nope, None. [17:11] you can check the transcription of the last session, but briefly it a 'parallel instance of the services used to maintain ubuntu primary archive' [17:11] it's a *public* service and anyone using Launchpad is welcome to try. [17:12] it allow any user to upload, build, publish and distribute their own packages [17:13] you just need to be familiar with debian/ubuntu development tools to build the source package you want to change, all the rest is done by Launchpad. [17:13] phoenix24: does it answer you question ? [17:13] warp10: QUESTION: Why doesn't LP provides a sparc builder too? [17:13] Yes, thanks! [17:14] warp10: the PPA builders are based in XEN VMs for proper isolation of the sources being built, and XEN doesn't support sparc officially [17:14] warp10: yet ... [17:15] warp10: QUESTION: Do PPAs build packages just like Soyuz does? I mean: If a package builds fine on a PPA, may I be 100% sure that it will build fine with buildd? [17:15] * warp10 likes the "yet ..." :-) [17:16] warp10: yes, the 'ubuntu infrastrucure' mentioned above is Soyuz. I'm glad you actually notice it :) [17:17] warp10: yes, I've read sometime ago that there were some effort on the sparc XEN port. I'm sure out IS team will be more than happy to adopt it when it gets official and stable enough. [17:17] warp10: QUESTION: can you anticipate plans for future improvements of PPA? What kind of new features are to be implemented? [17:18] warp10: yes, I can ... the current focus of our sub-team is allow quicker and simpler workflow to get work done in PPAs merged into ubuntu [17:19] warp10: for instance the REVU application (MOTU review system) which is the path to get new source officially uploaded to ubuntu [17:20] that's pretty much it, 'integration' is the word to define our goals in the next 2 or 3 months [17:21] secretlondo: QUESTION: how much space do we get for our PPA - and are there ways of increasing it? [17:22] secretlondo: by default you get 1GiB, but it can be increased by an launchpad administrator by request [17:22] secretlondo: you simply need to justify why you need more space, for instance, 'I'm playing with firefox3 and openoffice packages' :) [17:22] :) [17:23] warp10: sorry, I didn't answered you question about what are the main differences of PPA backend and Ubuntu backend [17:24] warp10: first, we automatically override all package uploaded to PPA to the main component [17:25] warp10: in the case it is being copied/synced to ubuntu primary archive it won't necessarily like in main and will be submitted to other ogre-model restricitions. [17:26] PPA builders also don't extract translations neither mangles the package information as they would do in ubuntu primary archive. [17:27] Those are the only simplifications we have in PPA that makes it slightly different than the ubuntu primary archive. [17:27] AFAICS, none of this should be a problem from the development print of view and they help users to get their job done in a quicker way. [17:28] warp10: did I addressed all the points you wanted ? [17:28] cprov-out: you absolutely did, thank you :) [17:29]