=== BobJonkman is now known as BobJonkman_AFK === BobJonkman_AFK is now known as BobJonkman === MickE is now known as Guest34399 === nigel is now known as nigelb === yofel_ is now known as yofel === raju1 is now known as raju === coalwater_ is now known as coalwater === [1]damageboy is now known as damageboy === raju1 is now known as raju === Pendulum_ is now known as Pendulum [11:05] hi to everyone [11:07] hello thanos713_ [11:08] When the next classrooom is going to be held? [11:08] class* [11:20] Can anyone help me with apt-cacher-ng setup? [12:55] karthick87: Support in #ubuntu, as per /topic [15:50] HELLO EVERYBODY! Welcome to Day 3 of Ubuntu Developer Week! [15:50] We still have 10 minutes left until we start, but I just wanted to bring up a few organisational bits and pieces first: [15:51] - If you can't make it to a session or missed one, logs to the sessions that already happened are linked from https://wiki.ubuntu.com/UbuntuDeveloperWeek [15:51] - If you want to chat or ask questions, please make sure you also join #ubuntu-classroom-chat [15:51] - If you ask questions, please prefix them with QUESTION: [15:52] ie: QUESTION: dpm, How hard was it to learn German? [15:52] - if you are on twitter/identi.ca or facebook, follow @ubuntudev to get the latest development updates :) [15:52] (answer: difficult if you start learning in the Swabian dialect) [15:52] ha! :) [15:53] that's it from me [15:53] you still hvae 7 minutes until David "dpm" Planella will kick off today and talk about Launchpad Translations Sharing! [15:53] Have a great day! === Andre_Go` is now known as Andre_Gondim === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Getting Translations Quicker into Launchpad: Upstream Imports Sharing - Instructors: dpm [16:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/13/%23ubuntu-classroom.html following the conclusion of the session. [16:02] hey everyone! [16:03] welcome all to the 3rd day of Ubuntu Developer Week [16:03] and welcome to this UDW talk about one of the coolest features of Launchpad Translations: upstream imports sharing [16:03] My name is David Planella, and I work on the Community team at Canonical as the Ubuntu Translations Coordinator [16:04] As part of my job, I get the pleasure of working with the awesome Ubuntu translation teams and with the equally awesome Launchpad developers [16:04] I also use Launchpad for translating Ubuntu on a regular basis, as part of my volunteer contribution to the project, [16:04] which is why I'm excited about this feature and I'd like to share it with you guys [16:05] So, without further ado, let's roll! [16:05] oh, btw, I've set aside some time for questions at the end, but feel free to ask anything during the talk. [16:05] just remember to prepend your questions with QUESTION: and ask them on the #ubuntu-classroom-chat channel [16:06] So... [16:06] [16:06] What is message sharing [16:06] ----------------------- [16:06] [16:06] Before we delve into details, let's start with some basics: what's all this about? [16:07] In short, message sharing is a unique feature in Launchpad with which translations for identical messages are essentially linked into one single message [16:07] This means that as a translator, you just need to translate that message once and your translations will appear automatically in all other places where that message appears. [16:08] The only requirements are that those messages are contained within a template with the same name and are part of different series of a distribution or project in Launchpad. [16:08] This may sound a bit abstract, so let's have a look at an example: [16:08] Let's say you're translating Unity in Ubuntu Oneiric: [16:08] https://translations.launchpad.net/ubuntu/oneiric/+source/unity/+pots/unity/ [16:09] (you translate it from that URL in Launchpad) [16:09] And you translate the message "Quit" into your language [16:09] Instantly your translation will propagate to the Unity translation in _Natty_ (and all other releases): [16:10] So it will appear translated here: [16:10] https://translations.launchpad.net/ubuntu/natty/+source/unity/+pots/unity/ [16:10] without you having had to actually translate it there [16:10] So basically Launchpad is doing the work for you! :-) [16:11] It also works when you want to do corrections: [16:12] Let's say you are not happy with the translation of "Quit" in Unity, and you change it in the Natty series in Launchpad [16:12] So you go to: https://translations.launchpad.net/ubuntu/natty/+source/unity/+pots/unity/ [16:12] and change it === tavish_ is now known as tavish [16:13] actually, I could point you to the actual message: [16:13] https://translations.launchpad.net/ubuntu/natty/+source/unity/+pots/unity/ca/2/+translate [16:13] anyway, so you fix the "Quit" translation [16:13] perhaps there was a typo, perhaps you were not happy with the current translation, etc. [16:15] That change will also be propagated to all other Ubuntu series, so that you don't have to manually fix each one of them [16:15] Isn't that cool? [16:15] And as you see, it works both ways: from older series to new ones, and viceversa. The order does not really matter at all. [16:15] we've got a question: [16:15] shnatsel|busy asked: If there was a change in terminology between the series, e.g. I translated "torrent" with one word, then the app changed (some strings changed, some strings added) and now I use a different word, is there a way to prevent the new terminology partly leaking to the older series and making a terrible mess there? [16:16] that's a good point [16:16] however, with the current implementation this will not happen [16:16] message sharing works only with identical messages [16:17] this means that if in the first series the original string was "torrent", [16:17] and in the next series the original string was "torrent new", [16:18] there won't be any message sharing at all, avoiding inadvertently translating strings you don't want to be translated automatically [16:19] gpc asked: So, "torrent" and "torrent." are not the same string? [16:20] that's correct, even with such a small change as this, they're not considered the same string [16:20] they need to be identical [16:20] so rather than a fuzzy match, message sharing works only on identical matches [16:21] fuzzy matching would need further development in Launchpad [16:21] If you're interested on how difficult it would be to implement it, or even in implement it yourself, [16:21] I'd recommend asking on the #launchpad channel [16:21] that's where the Launchpad developers hang out [16:22] and they're always happy to help [16:22] Anyway, let'w move on... [16:22] So far we've only talked about distributions, and in particular Ubuntu. But this equally works within series of projects in Launchpad [16:22] But more on that later on... [16:22] You'll find out more about sharing here as well: [16:22] http://blog.launchpad.net/translations/sharing-translations [16:22] http://danilo.segan.org/blog/launchpad/automatic-translations-sharing [16:23] [16:23] Benefits of messsage sharing [16:23] ---------------------------- [16:23] Continuing with the basics: what good is this for? [16:24] In terms of Launchpad itself, it makes it much more effective to store the data: rather than storing many translations for a same message, only one needs to be stored. [16:24] But most importantly: [16:24] For project maintainers: when they upload a template to a new release series and it gets imported, will instantly get all existing translations from previous releases shared with the new series and translators won’t have to re-do their work. They won’t have to worry about uploading correct versions of translated PO files, and can just care about POT files instead. [16:25] For translators: they no longer have to worry about back-porting translation fixes to older releases anymore, and they can simply translate the latest release: translations will automatically propagate to older releases. Also, this works both ways, so if you are translating a current stable release, newer development release will get those updates too! [16:26] Any other questions so far? [16:27] Ok, let's continue then [16:27] [16:27] What's new in message sharing [16:27] ----------------------------- [16:27] Until recently, message sharing had only worked within the limits of a distribution or of a project. [16:28] That is, messages could be shared amongst all the series in a distribution or amongst all series of a project. [16:28] As cool as it already was, that was it: data could not flow across projects and distributions, and each one of these Launchpad entities behaved like isolated islands with regards to message sharing. [16:29] But before going forward, let me recap quickly on some other basic concepts in Launchpad. When we're talking about message sharing, we're interested mostly in two types of Launchpad entities [16:30] * Projects: these are standalone projects whose translations are exposed in Launchpad. If these projects are packaged in a distribution, we often refer to the actual project at a location such as https://launchpad.net/some-project as to the upstream project. An example is the Chromium project at https://translations.launchpad.net/chromium-browser/. Upstream projects can host their translations in Launchpad or externally. In the latter case, translat [16:30] ions can still be imported into Launchpad, but more on that later on [16:31] * Distributions: these are collections of source packages, each one of which is also exposed for translation. The most obvious example is Ubuntu. Here's an example of the Natty series of the Ubuntu distribution: https://translations.launchpad.net/ubuntu/natty [16:32] So the news, and the main subject of this talk, is that from now on translations can be shared, given the right permissions, across projects and distributions. [16:32] Again, let's take an example: [16:32] • The Synaptic project is translatable in Launchpad: https://translations.launchpad.net/synaptic [16:33] • At the same time, the Ubuntu distribution has got a Synaptic package which is translatable in Launchpad: https://translations.staging.launchpad.net/ubuntu/natty/+source/synaptic/ [16:33] • Now, given that the upstream maintainer has enabled sharing and has set the right permissions, now translators can translate Synaptic in Ubuntu and their translations will seamlessly flow into the upstream project! [16:33] • This works again both ways: if one translates Synaptic in the upstream project, translations will appear in the Ubuntu distribution [16:34] So no more backporting translations or exporting them and committing them back and forth. [16:35] ashams asked: So why there is a separate set of Templates for each release of Ubuntu, i.e. (in Natty: https://translations.launchpad.net/ubuntu/natty/+source/unity/+pots/unity/) in Oneric: https://translations.launchpad.net/ubuntu/oneiric/+source/unity/+pots/unity/) [16:36] This is due to the fact that for each series of Ubuntu you not only get new applications with new templates (or some go away), but also you get different messages in the templates [16:36] This is how releases of projects work, it hasn't got anything to do with message sharing [16:37] i.e. we need different sets of templates for each series, otherwise if we had one single set, it will overwrite the old ones on each release [16:38] Anyway, combine the previous example with automatic translation imports and exports, and project maintainers get a fully automated translation workflow, which is really really awesome :-) [16:38] More on automatic imports/exports: [16:38] https://help.launchpad.net/Translations/YourProject/ImportingTranslations [16:38] http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch [16:39] So far we've covered projects hosted in Launchpad - what happens with projects hosted externally? [16:39] If translations of a given project are hosted externally, you won't get the benefit of full integration into Launchpad, but you'll still get some important advantages: [16:40] • Translations will need to be imported from a mirror branch into a Launchpad upstream project [16:40] • They will then be regularly imported to Launchpad Translations [16:40] • From there, they will flow quickly, and on a regular basis, into the Ubuntu distribution [16:40] • Up until here, the end result is the same as for upstream projects hosting translations in Launchpad [16:40] • However, translations will only flow in the direction upstream -> Ubuntu, as we don't have a way to automatically send translations to the external project yet [16:41] • The big benefit here is that translations will be imported reliably and quickly on a regular basis [16:42] For an overview on message sharing across projects and distributions, check out this UDS presentation by Henning Eggers, one of the Launchpad developers who implemented this feature, and myself: [16:42] http://ubuntuone.com/p/skw/ [16:43] [16:43] How to enable message sharing [16:43] ----------------------------- [16:43] The cool thing to know is that within a project or a distribution message sharing is already enabled [16:44] There are no steps that the project maintainers need to follow: every new series will automatically share messages with all the others [16:45] However, if you want to share messages between an upstream project and a distribution (e.g. Ubuntu), there are a set of steps that need to be performed first: [16:45] * Enable translations in the upstream project, setting the right permissions and translations group [16:46] * If the project you want to enable sharing for is hosting translations externally, you'll need to request a bzr import, so that translations can get imported from an external branch [16:47] * Finally, you'll need to link the upstream project to the corresponding source package in Launchpad [16:47] Right now just a few projects and source packages are linked this way, but this cycle we're planning a community effort to enable sharing for all supported packages. [16:48] I've prepared a table with an overview of the supported packages here: [16:48] https://wiki.ubuntu.com/Translations/Projects/LaunchpadUpstreamImports [16:48] And will soon announce how the community can help in enabling these for sharing. [16:48] Stay tuned to the Ubuntu translators list for more info: [16:49] https://wiki.ubuntu.com/Translations/Contact/#Mailing_lists [16:49] Ok, I think that's all I had on content, so let's go for questions! [16:49] [16:49] Q & A [16:49] ----- [16:50] yurchor asked: Why does translation sharing behaves strange (diffs are really weird)? Ex.: https://translations.launchpad.net/ubuntu/natty/+source/avogadro/+pots/libavogadro/uk/+translate?show=new_suggestions [16:51] There are 10 minutes remaining in the current session. [16:51] I think that particular case is a project in which there was some data that needed migration (i.e. Ubuntu translations exported and uploaded in the upstream package) and that did not happen. [16:51] I'd suggest pointing this out in the #launchpad channel, where the Launchpad devs can have a look at it in more detail [16:52] yurchor asked: What if the project does not have repository with translations (like Fedora's libvirt, etc. on Transifex, translations are generated at package creation)? What will be imported from upstream? [16:53] I'm not familiar with how translations are stored in Fedora's libvirt. The only layout that's supported for external repositories is PO files stored in an external version control system that can be imported as a bzr branch (e.g. git, mercurial, svn, etc) [16:54] QUESTION: For example, I'm translating a BitTorrent client. I had a translation of the term "torrent" that I used in all strings that contain it. Then a new major release arrived that has some strings added, some strings removed and some strings (like "New torrent") intact. For the new version, I find a better translation of the term "torrent", and change it in all those strings in the newer series. But then the new translation of "New torrent", wit [16:54] h the new term to describe "torrent" will leak to the older series, while some other strings in there still use the old term. How can I prevent it? [16:55] oh, I understand what you mean now [16:55] There are 5 minutes remaining in the current session. [16:56] Unfortunately, there is no way to detect this in Launchpad, as there is no way to link the "New torrent" to the "torrent" messages [16:56] In this particular case, one thing you can do is to export the translation as a PO file, and replace all the "New torrent" translations with the new term [16:57] and then reupload in Launchpad [16:57] One thing I forgot to mention, and it might be useful if you want to keep the old terminology in older series, [16:57] is that you can explicitly choose individual messages to diverge [16:58] so you can call "torrent" as "a" in a series and "b" in another series, bypassing message sharing [16:59] Ok, I think there is not much time for more questions, so we can probably wrap it up here [16:59] If you've got other questions, feel free to ask me on the #ubuntu-translators channel on Freenode [16:59] So thank you everyone for listening and for participating with your questions [17:00] I hope you enjoyed the talk and see you soon! === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Debugging the Kernel - Instructors: jjohansen [17:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/13/%23ubuntu-classroom.html following the conclusion of the session. [17:01] Hi, before we start I figured I would introduce myself, I am John Johansen an Ubuntu contributor and member of the Kernel team [17:01] Feel free to ask questions through out in he #ubuntu-classroom-chat channel, and remember to prepend QUESTION: to your question [17:01] So lets get started [17:01] ------------------------------------------ [17:01] Debugging Kernels is a vast topic, and there is lots of documentation out there. Since we only have an hour I thought I would cover a few thing specific to the Ubuntu kernel. So perhaps the topic really should have been changed to debugging the Ubuntu kernel. I am not going to walk through a live example as we don't have time for multiple kernel builds, installing and testing, working with the kernel takes time. [17:02] First up is the all important documentation link https://wiki.ubuntu.com/Kernel [17:02] It has a lot of useful information buried in its links. [17:02] it takes a while to read through but its really worth doing if you are interested in the kernel [17:02] The Ubuntu kernels are available from git://kernel.ubuntu.com/ubuntu/ubuntu-.git [17:02] ie. for natty you would do [17:02] git clone git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git [17:03] https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide [17:03] gives the full details if you need more [17:03] The Ubuntu kernel uses debian packaging and fakeroot to build, so you will need to pull in some dependencies [17:03] sudo apt-get build-dep linux-image-$(uname -r) [17:04] once you have the kernel you can change directory into the tree and build it [17:04] fakeroot debian/rules clean [17:04] fakeroot debian/rules binary-headers binary-generic [17:04] Note, a couple of things, 1. the clean must be done before your first attempt at building, its sets up some of the environment. 2 we are building the one kernel flavour in the above example, and the end result should be some debs. [17:04] also if you ever see me use fdr its an alias I set up for fakeroot debian/rules, so I can get a way with doing [17:04] fdr clean [17:04] it saves on typing, I'll try not to slip up but just incase ... [17:04] Everyone good so far? [17:05] Alright onto bisecting [17:05] We need to cover a little more information about how the Ubuntu kernel is put together. Each release of the Ubuntu linux kernel is based on some version of the upstream kernel. The Ubuntu kernel carries a set of patches on top of the upstream linux kernel. The patches really can be broken down into 3 catagories, packaging/build and configs, features/drivers that are not upstream (see the ubuntu directory for most of t [17:05] During the development cycle, the Ubuntu kernel is rebased on top of the current linux kernel, as the linux kernel is updated so is the development Ubuntu kernel; it occasionally gets rebased on top of newly imported linux kernels. This means a couple of things patches that have been merged upstream get dropped, and that the Ubuntu patches stay at the top of the stack. [17:06] During the development cycle we hit a point called kernel freeze, where we stop rebasing on upstream, and from this point forward only bug fixes are taken with commits going on top. [17:06] So why mention all of this? Because it greatly affects how we can do kernel bisecting. If a regression occurs after a kernel is released (say the natty kernel), and there is a known good natty kernel, then bisecting is relatively easy. We can just checkout the natty kernel and start a git bisect between the released kernel tags. [17:06] However bisecting between development releases or different released versions (say maverick and natty) of the kernel becomes much more difficult. This is because there is no continuity because of the rebasing, so bisect doesn't work correctly, and if you are lucky and have continuity the bisecting may remove the packaging patches. [17:07] So how do you bisect bugs in the Ubuntu kernel then? We use the upstream kernel of course :) [17:07] There are two ways to do this, the standard upstream build route and using a trick to get debian packages. [17:07] The upstream route is good if you are just doing local builds and not distributing the kernels [17:08] but if you want other people to install your kernels you are probably best of using the debian packaging route [17:08] So the trick to get debian packaging is pretty simple [17:09] you checkout the upstream kernel [17:09] checkout an Ubuntu kernel [17:09] identify a good and bad upstream kernel [17:10] you can do this by using the ubuntu mainline kernel builds available from the kernel team ppa [17:11] http://kernel.ubuntu.com/~kernel-ppa/mainline/ [17:11] that saves you from having to build kernel [17:12] now copy the debian/ and debian.master/ directories from the ubuntu kernel into the upstream kernel [17:12] you do not want to commit these [17:12] as that will just make them disappear with the bisect [17:12] you can the change directory into the upstream kernel [17:12] edit debian.master/changelog, the top of the file should be something like [17:12] linux (2.6.38-10.44) natty-proposed; urgency=low [17:14] you want to change the version to something that will have meaning to you [17:14] and that can be easily replaced by newer kernels [17:14] you use a debian packaging trick to do this [17:15] change 2.6.38-10.44 to something like 2.6.38-10.44~jjLP645123.1 [17:16] the jj indicates me, then the launchpad bug number and I like to use a .X to indicate how far into the bisect [17:16] you can use what ever make sense to you [17:17] the important part is the ~ which allows kernels with higher version numbers to install over the bisect kernel without breaking things [17:18] if you are going to upload the kernel to a ppa you will also want to update the release info [17:18] ie. natty-proposed in this example [17:19] if you are using the current dev kernel it will say UNRELEASED and you need to specify a release pocket [17:19] ie. natty, maverick, ... === Cas071 is now known as Cas [17:19] however ppa builds are slow and I just about never use them, at least not for regular bug testing === Cas is now known as Cas07 [17:20] now you can build the kernel [17:20] fakeroot debian/rules clean [17:20] fakeroot debian/rules binary-headers binary-generic [17:21] this will churn through and should build some .debs that can be installed using [17:21] dpkg -i [17:21] now on to doing the actual bisect [17:23] so bisecting is basically a binary search, start with a known good point and bad, cut the commits in half, build a kernel test if its good, rinse lather, and repeat [17:23] git bisect is just a tool to help you do this [17:24] it is smarter than just doing the cut in half, it actually takes merges and other things into account [17:24] the one important thing to note, for these bisects is if you look at the git log etc, you may find yourself in kernel versions outside of your bisect range [17:25] this is because of how merges are handled, don't worry about it, git bisect will handle it for you [17:25] so the basics of git bisect are [17:26] git bisect start [17:26] where bad is the bad kernel and good is the good kernel [17:26] the problem is how do you know which kernel versions to use [17:27] if you are using the upstream kernels for a bisect then the ubuntu version tags are not available to you [17:27] you need to use either a commit sha, or tag in the upstream tree [17:29] sorry lost my internet there for a minute [17:31] if you used the mainline kernel builds to find a good and bad point then you can just use the kernel tags for those, ie. v2.6.36 [17:31] if you used and ubuntu kernel then you can find a mapping of kernel versions here [17:32] http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html [17:32] alright so I was asked what the debian.master directory is about [17:32] in the Ubuntu kernel we have two directories to handle the debian packaging [17:32] debian and debian.master/ [17:33] this allows abstracting out parts of the packaging [17:34] when you setup a build, the parts of debian.master/ are copied into debian/ and that is used [17:35] the difference between the two isn't terribly important for most people, think of debian as the working directory for the packaging, and master as the reference [17:36] when I had you edit debian.master/changelog above I could have changed things around and had you edit debian/changelog [17:36] however [17:36] fakeroot debian/rules clean [17:36] will endup copying debian.master/changelog into debian/ [17:37] thus if you change debian/change log you have to do a full edit on it every time you do a clean [17:37] so if you are editing debian/ you do [17:37] fdr clean [17:37] edit debian/changelog [17:38] which is the reversion of doing it to debian.master/changelog [17:38] edit debian.master/changelog [17:38] fdr clean [17:38] for me editing debian.master/changelog keeps me from making a mistake and building a kernel with out my edits to the kernel version [17:40] hopefully that is enough info on the debian/ and debian.master/ for now [17:40] and we will jump back to bisecting for a little longer [17:41] so assuming you have your kernel version for good and bad you start, your bisection [17:41] git will put you on a commit roughly in the middle [17:41] then you can do [17:41] fdr clean [17:42] fakeroot debian/rules binary-headers binary-generic [17:42] sorry caught myself using fdr [17:42] this will build your kernel you can install and test [17:43] and then you can input your info into git bisect [17:43] ie. [17:43] git bisect good [17:43] or [17:43] git bisect bad [17:43] the import thing to remember is to not, commit any of your changes to git [17:44] I tend to edit the debian.master/changelog and update the .# at the end of my version string every iteration of the bisection [17:44] you don't have to do this [17:45] you can get away with just rebuilding, straight or if you want doing a partial build [17:46] the partial build is a nice trick if you don't have a monster build machine but it doesn't save you anything early on in the bisect, when git is jumping lots of commits and lots of files are getting updated [17:46] the trick to doing a partial build in the Ubuntu build system is removing the stamp file [17:47] when the kernel is built there are some stamp files generated and placed in [17:47] debian/stamps/ [17:47] there is one for prepare and one for the actual build [17:48] if you build a kernel, and the build stamp file is around, starting a new build will just use the build that already exists and package it into a .deb [17:48] you don't want to do this [17:49] so after you have stepped you git bisect (git bisect good/bad) [17:49] you [17:49] rm debian/stamps/stamp-build-generic [17:50] this will cause the build system to try building the kernel again, and make will use its timestamp dependencies to determine what needs to get rebuilt [17:51] There are 10 minutes remaining in the current session. [17:51] if the bisect is only stepping within a driver or subsystem this can save you a log of time on your builds, however if the bisect updates lots of files (moves lots of commits) or updates some common includes, you are going to end up doing a full kernel build [17:52] so now for the other tack, what do you do if you don't want to mess with the .deb build and just want to build the kernel old fashioned way [17:52] well you build as you are familiar with. [17:52] make [17:52] make install [17:52] make modules_install [17:53] then you need to create a ramdisk, and update grub === AndroUser is now known as daemonTutorials [17:54] sudo update-initramfs -c k [17:54] will create the ram disk you need if you don't want to mess with the kernel version [17:54] sudo update-initramfs -c -k all [17:54] then you can do [17:55] sudo update-grub [17:55] and you are done [17:55] so QUESTION: After rm debian/stamps/stamp-build-generic do you still do a fakeroot debian/rules clean when doing the incremental build? [17:55] the answer is no [17:55] There are 5 minutes remaining in the current session. [17:56] doing a clean will remove all the stamp files, and remove your .o files which will cause a full build to happen [17:57] so with only a couple minutes left I am not going to jump into a new topic but will mention something I neglected about about the Ubuntu debian builds [17:58] our build system has some extra checks for expected abi, configs, and modules [17:58] when building against an upstream kernel you will want to turn these off [17:58] you can do this by setting some variables on the command line [17:58] fakeroot debian/rules binary-headers binary-generic [17:58] becomes [17:59] skipabi=true skipconfig=true skipmodule=true fakeroot debian/rules binary-headers binary-generic [17:59] this can also be used when tuning your own configs etc/ [18:00] I think I will stop there [18:00] thanks for attending, drop by #ubuntu-kernel if you have any questions === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: dotdee - break a flat file into dynamically assembled snippets - Instructors: kirkland [18:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/13/%23ubuntu-classroom.html following the conclusion of the session. [18:01] howdy all [18:02] this session is on dotdee [18:02] there will be a live streamed demo at: http://bit.ly/uclass [18:02] i invite you to join me there [18:02] the username and password is guest/guest [18:03] for those interested, this is a tool called ajaxterm [18:03] which embeds a terminal in a web browser [18:03] i've set up a byobu/screen session for the guest user (which is readonly for all of you) [18:03] I'll drive the demo [18:04] and annotate it here [18:04] alternatively, you can ssh guest@ec2-50-19-128-105.compute-1.amazonaws.com [18:04] with password guest [18:05] okay, on to dotdee :-) [18:05] if you've ever configured a Linux/UNIX system, you're probably familiar with the /etc directory [18:05] and inside of /etc, there are many directories that end in a ".d" [18:05] watch the terminal while I find a few in /etc [18:06] there's a bunch! [18:06] this is a very user friendly way of offering configuration to users [18:06] usually, files in a .d directory are concatenated, or executed sequentially [18:07] it give users quite a bit of flexibility for editing or adding configurations [18:07] to some software or service [18:07] it also helps developers and packagers of software [18:07] as it often allows them to drop snippets of configuration into place [18:07] but not every configuration file is setup in this way [18:08] in fact, most of them are really quite "flat" [18:08] a few months ago, I found myself repeatedly needing to converted some flat configuration files [18:08] to .d style ones [18:09] this was for software I was working with, as a developer/packager [18:09] but not software that I had written myself [18:09] ideally, I would just ask the upstream developers to change their flat .conf file [18:09] to a .d directory [18:09] and they would magically do it [18:09] and test it [18:09] and release it [18:09] immediately :-) [18:10] that rarely happens though :-P [18:10] so I wrote a little tool that would generically to that for me! [18:10] and that tool is called "dotdee" [18:10] so let's take a look! [18:10] over in the terminal, i'm going to install dotdee, which is already in Ubuntu oneiric [18:10] sudo apt-get install dotdee [18:11] for older ubuntu distros, you can 'sudo apt-add-repository ppa:dotdee/ppa' [18:11] and update, and install it there too [18:11] cool, so now i have a /usr/sbin/dotdee executable [18:11] let's take a flat file, and turn it into a dotdee directory! [18:12] I'm going to use /etc/hosts as my example [18:12] first, I need to "setup" the file [18:12] i can first verify that /etc/hosts is in fact a flat file, [18:12] -rw-r--r-- 1 root root 296 2011-07-13 12:14 /etc/hosts [18:13] I'm going to set it up like this: [18:13] sudo dotdee --setup /etc/hosts [18:13] INFO: [/etc/hosts] updated by dotdee [18:13] cool! [18:13] now let's look at what dotdee did.... [18:13] $ ll /etc/hosts [18:13] lrwxrwxrwx 1 root root 27 2011-07-13 18:13 /etc/hosts -> /etc/alternatives/etc:hosts [18:13] so /etc/hosts is now a symlink [18:13] pointing to an alternatives link [18:14] $ ll /etc/alternatives/etc:hosts [18:14] lrwxrwxrwx 1 root root 22 2011-07-13 18:13 /etc/alternatives/etc:hosts -> /etc/dotdee//etc/hosts [18:14] which is pointing to a flat file in /etc/dotdee [18:14] $ ll /etc/dotdee//etc/hosts [18:14] -r--r--r-- 1 root root 296 2011-07-13 18:13 /etc/dotdee//etc/hosts [18:14] if I look at the contents of that file, I see exactly what I had before [18:15] but let's go to that directory, /etc/dotdee [18:15] inside of /etc/dotdee, there is a file structure that mirrors the same file structure on the system [18:15] importantly, we now have a .d directory [18:15] that refers exclusively to our newly managed file === daker is now known as daker_ [18:16] namely, /etc/dotdee/etc/hosts.d [18:16] in that directory, all we have is a file called 50-original [18:16] which is the original contents of our /etc/hosts [18:16] but let's say we want to "append" a host to that fie [18:16] file [18:16] let's create a new file in this directory [18:16]