[06:58] hi [12:34] ha [12:36] Hi [12:36] dhana from? [12:36] gurulenin: india [12:37] gurulenin: u? [12:37] Tamil Nadu [12:37] gurulenin: chennai.. [12:37] Karaikudi [12:38] gurulenin: Good, class started at 8.30 indian time right [12:40] Is it? or 6.30? [12:41] gurulenin: sorry 18:30 IST === fouad_ is now known as Fo2adZz === 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 Open Week - Current Session: Ubuntu Development Team - Instructors: dholbach [13:00] WELCOME MY FRIENDS TO ANOTHER UBUNTU OPEN WEEK! :-) [13:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/10/24/%23ubuntu-classroom.html following the conclusion of the session. [13:01] Before we start here are a very few organisational things: [13:01] - logs will be available at http://irclogs.ubuntu.com/2012/10/24/%23ubuntu-classroom.html and at https://wiki.ubuntu.com/UbuntuOpenWeek later on [13:01] - https://wiki.ubuntu.com/UbuntuOpenWeek should give you some good idea what's going to happen in the next few days [13:02] - if you just joined in, please also make sure you join #ubuntu-classroom-chat which is where we all talk and where you can ask questions [13:02] - if you ask questions, please prefix them with QUESTION: so they stand out and I can pick them up more easily [13:02] thanks everyone! :=) [13:02] :-) [13:03] My name is Daniel Holbach, I've been involved with Ubuntu since 4.10 and joined Canonical about 7 years ago. The Ubuntu Community is very close to my heart and I try to help everyone get involved in Ubuntu development. [13:03] Getting Started with Ubuntu Development is what I'll talk about today and I welcome you all to ask all the questions you have. [13:03] I'll try to zip through some of the basics quickly and I hope we'll have some time later on to fix a bug together. :-) [13:04] All right... [13:04] * dholbach takes a deep breath [13:04] Let's start. :-) [13:04] Ubuntu is made up of thousands of different components, written in many different programming languages. Every component - be it a software library, a tool or a graphical application - is available as a source package. Source packages in most cases consist of two parts: the actual source code and metadata. [13:04] Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install. [13:05] Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to Launchpad’s build machines to be compiled. [13:05] The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in /etc/apt/sources.list point to an archive or mirror. [13:05] Every day (and during release times, more often) CD images are built for a selection of different Ubuntu flavours. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the CD. These CD images are then used for installation tests and provide the feedback for further release planning. [13:05] Any questions so far? [13:06] Ok, let's talk a bit about our release cycle then. [13:06] Ubuntu’s development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. [13:07] With every freeze date that is reached developers are expected to make fewer, less intrusive changes. [13:07] Feature Freeze is the first big freeze date after the first half of the cycle has passed. At this stage features must be largely implemented. [13:07] The rest of the cycle is supposed to be focused on fixing bugs. After that the user interface, then the documentation, the kernel, etc. are frozen, then the beta release is put out which receives a lot of testing. From the beta release onwards, only critical bugs get fixed and a release candidate release is made and if it does not contain any serious problems, it becomes the final release. [13:07] If you want to get an idea for how this looks visually, check out https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule - it's the release schedule for Ubuntu 12.10, which just got released last week. [13:09] The release cycle also has an impact on what we ask developers (new or old) to focus on. In the beginning we try to merge as many upstream (more about Upstreams in just a bit) changes as possible, so we can get as much testing and stabilisation as possible and just do bug fixes towards the end of the release. [13:09] MestreLion asked: does interface freeze comes *after* feature freeze? [13:10] MestreLion, good question - yes, feature freeze is mostly about getting the functionality of the feature ready - it doesn't need to be pixel-perfect and the look can still be changed based on testing [13:11] User Interface (UI) Freeze is very important because it has an impact on for example the Docs team or the press, because they take screen shots around beta time already so they have everything in place before the release [13:11] Hope that answered the question. [13:11] Thousands of source packages, billions of lines of code, hundreds of contributors require a lot of communication and planning to maintain high standards of quality. [13:12] At the beginning of each release cycle we have the Ubuntu Developer Summit where developers and contributors come together to plan the features of the next releases. [13:12] This time the Ubuntu Developer Summit (UDS) is going to be in Copenhagen, Denmark. [13:12] So if you're in the area from 29th Oct - 1st Nov, make sure you drop by. [13:12] https://uds.ubuntu.com/ has more info. [13:12] Every feature is discussed by its stakeholders and a specification is written that contains detailed information about its assumptions, implementation, the necessary changes in other places, how to test it and so on. [13:12] This is all done in an open and transparent fashion, so even if you cannot attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants and subscribe to changes of specifications, so you are always up to date. [13:13] From the site I mentioned above you can also get to the schedule of UDS and subscribe to sessions and you get notified about the outcomes, etc. [13:13] More questions? [13:14] Ok. I promised to talk a bit more about Upstream projects, let's talk about it next then. :) [13:14] Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. [13:15] That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise. For more immediate coordination, developers and contributors use Internet Relay Chat (IRC). All discussions are open and public. [13:15] IdleOne asked: Mark Shuttleworth announced recently some "secret" projects that he intends to invite trusted people to help create/test. How will those projects be discussed openly if at all at UDS? [13:16] IdleOne just added: [13:16] dholbach: if that question would be better for mark at his session I am fine with waiting for an answer :) [13:16] Yes, it's a good question for Mark, but I'll try to answer it myself as well. [13:16] There are indeed projects originating within the Design team where just a few people are involved in the beginning. [13:17] This team has had non-Canonical involvement in the past already, but there were complaints that it wasn't open enough [13:17] Mark's recent blog post tried to find a way to open the team up slowly [13:18] In a way, you give the project some time to mature, before you announce it and when you have something to show [13:18] That's my understanding of it anyway. :) [13:19] MestreLion asked: I assume the projects discussed at UDS are the ones that Ubuntu/Canonical is the upstream, like Unity, correct? [13:19] MestreLion, they will be discussed, yes - but a lot of other projects will be discussed as well [13:20] In a little bit I will talk a bit more about other Open Source projects which are integrated in Ubuntu, where Ubuntu engineers help out and collaborate and where we invite members of those projects to UDS to find out more about the next steps. [13:21] Ok, a few more words about communication in the project and with other projects: [13:21] Another important tool regarding communication is bug reports. Whenever a defect is found in a package or piece of infrastructure, a bug report is filed in Launchpad. [13:21] All information is collected in that report and its importance, status and assignee updated when necessary. This makes it an effective tool to stay on top of bugs in a package or project and organise the workload. [13:21] Most of the software available through Ubuntu is not written by Ubuntu developers themselves. Most of it is written by developers of other Open Source projects and then integrated into Ubuntu. [13:22] These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it. The relationship to Upstreams is critically important to Ubuntu. [13:22] It is not just code that Ubuntu gets from Upstreams, but it is also that Upstreams get users, bug reports and patches from Ubuntu (and other distributions). [13:23] I hope this clarifies a bit how we work together with Upstream projects and how the interaction looks like. I'll go into a bit more detail in a bit. Any more questions so far? [13:23] dholbach: you are the mentioned thousand packages source to deb process, which tool you guys using.. build process done by launchpad build machine or custom build also accepet [13:23] dhanasekaran1, good question - it's a bit hard to understand in the beginning, but it generally works like this: [13:24] You download the source of a package, make the necessary modifications, then do a local test-build (more about the tools we use later on), then you can upload it to Launchpad to get it to build there. [13:24] The short answer is: no, there are no custom builds. [13:25] We believe that exactly reproducible builds is the best for Ubuntu. Basically you upload the source, with your modifications and instructions to build it. Then the build will happen. So at every single stage in time, there's one version of a package in any release and the build results should be the same for everyone. [13:27] The most important Upstream for Ubuntu is Debian. Debian is the distribution that Ubuntu is based on and many of the design decisions regarding the packaging infrastructure are made there. [13:27] Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. In Ubuntu there are teams that have an interest in a subset of packages too, and naturally every developer has a special area of expertise, but participation (and upload rights) generally is open to everyone who demonstrates ability and willingness. [13:27] Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there. [13:28] Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream is interested in working on a new big feature while Ubuntu, because of the tight release schedule, is interested in shipping a solid version with just an additional bug fix. [13:28] That is why we make use of “Distributed Development”, where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion. [13:29] vibhav asked: Is there any team which helps coordination between Upstream and Ubuntu? [13:29] vibhav, nice one [13:29] No, there's not a dedicated team, but every team deals with their respective upstreams independently. Although the processes (for code inclusion, and forwarding of patches, etc.) are often quite similar. [13:30] So the Desktop team will for example deal with GNOME (which is the Upstream for many components of our Desktop), with X.org, with LibreOffice, the Unity team and many many others. [13:30] The Server team will be in close contact with Apache, with Postfix Upstream, OpenStack and many others. [13:31] As an individual with just an interest in one or two packages, you might be that link, that ambassador to Upstream. [13:31] smartboyhw asked: dholbach you said the most important upstream project is Debian. I thought the most important upstream project is the Linux kernel. Am I wrong? [13:31] smartboyhw, that's an interesting question :) [13:31] the Linux kernel is without doubt a very important piece of Ubuntu (and every other Linux distribution) [13:32] and it's unfair trying to pick "the most important" project [13:32] that's like picking your single best friend and making lots of other friends unhappy ;-) [13:32] but Ubuntu's case is special [13:32] we're not a regular distribution, but we're a distribution which is based on another one, Debian [13:33] if we were a "regular distribution", we would deal with thousands of Upstream projects on our own [13:33] because we are based and work closely with Debian we inherit lots of stellar work from another distribution [13:33] and also inherit a lot of their design decisions [13:34] you will very often find that packages in Ubuntu are unmodified versions of the code in Debian, because the maintainers there do a great job and/or because we work together with them [13:34] so you can see that our connection to Debian is indeed very special [13:34] vibhav asked: What does coordination between Upstream and Ubuntu involve? Is there way I can too contribute? [13:34] perfect! :) [13:35] so if we want to make sure that Ubuntu and the Upstream project get the most out of our work, we want the following: [13:35] - have the best possible experience for our users (obviously) [13:35] - the best possible version in Ubuntu (this sometimes does not necessarily need to be the newest - sometimes the most stable is preferrable :-)) === dholbach_ is now known as dholbach [13:39] sorry about that - this was the worst possible point in time to lose connection [13:39] ok, so I'm not sure how much you received what I wrote earlier [13:39] so if we want to make sure that Ubuntu and the Upstream project get the most out of our work, we want the following: [13:39] - have the best possible experience for our users (obviously) [13:39] - the best possible version in Ubuntu (this sometimes does not necessarily need to be the newest - sometimes the most stable is preferrable :-)) [13:39] - share information from our users (good bug reports with all necessary information) with upstream, so they can look into the problem [13:39] - all our patches and modifications forwarded upstream [13:39] as you can see a lot of good communication between the two projects is necessary to get together a good collaboration [13:39] sometimes this will also involve talking to maintainers from other distributions [13:40] coolbhavi asked: you mentioned that getting a change in ubuntu is not difficult. As a new user I want to contribute but m stuck at some point. How easy is it in such a situation? [13:40] very easy and very good question [13:40] there are many developers out there who just want to help you - you just need to ask [13:40] there's #ubuntu-motu on irc.freenode.net for example [13:40] and you can sign up for https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu to mail your questions there [13:41] everybody's super helpful and very friendy folks who want to help you get started [13:42] ok, let's go back to distributed development for a bit [13:42] earlier I said: For example there might be the case that a particular Upstream is interested in working on a new big feature while Ubuntu, because of the tight release schedule, is interested in shipping a solid version with just an additional bug fix [13:42] In that case it would make sense for Ubuntu to ship with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins. [13:43] But you have to consider this: whenever we take pristine upstream source and add a change of our own, we introduce a delta between the too. [13:43] Let's say you fixed a bug and we added the fix. That's great. Ubuntu users are happy because of you. [13:44] But, if the change does not go into the Upstream source we will have to maintain the delta between the two. [13:44] And over time if the code changes a lot, this might start to be a lot of work. [13:44] So collaboration is super important. [13:45] To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it. [13:45] After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu. [13:45] Sounds easy, doesn't it? :) [13:45] Any questions about any of this? [13:46] When trying to find a solution it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort. [13:46] Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream. [13:47] And now to a question I get asked all the time. "What does it take to become an Ubuntu developer?" :) === henrix is now known as henrix_ [13:47] The most important requirements for success in Ubuntu development are: having a knack for “making things work again,” not being afraid to read documentation and ask questions, being a team player and enjoying some detective work. [13:47] And as I mentioned earlier: You are not alone! Good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software. [13:48] Ok, this concludes the quick general intro I wanted to give. I'd be happy to take a few more questions before we crack on. :) [13:49] Any more general questions about Ubuntu development? Anything you always wanted to know? [13:50] satyag asked: how does Canonical engage with Foss communities in India ? [13:50] hello satyag [13:50] satyag, there are no specific community plans for specific countries [13:50] we have LoCo (local community) teams in almost every country on the world [13:51] http://loco.ubuntu.com/ might give you a good idea [13:51] and in these teams we have Canonical and non-Canonical people [13:51] who are involved locally, at events, with other projects and so on [13:52] so depending on well organised your team is and how involved they are, you should see Ubuntu people at events and elsewhere :) [13:52] alright - if there's no more question, I'd say we take a 5 minute break (I need to get a glass of water and maybe some tea) [13:53] and then we crack on with how to get actually started [13:59] alright, we're back to part 2 of "Getting Started with Ubuntu Development" [13:59] to everyone who is late: http://irclogs.ubuntu.com/2012/10/24/%23ubuntu-classroom.html will later have the full logs and we will put them up on https://wiki.ubuntu.com/UbuntuOpenWeek too [14:00] another piece of advice: make sure you're in #ubuntu-classroom-chat as well [14:00] because that's the place where we discuss everything and where you can ask questions [14:00] just make sure you prefix them with QUESTION: [14:00] so they stand out and the bot can pick them up [14:00] any more questions about what I talked about earlier? [14:01] Alright, no questions - let's get cracking then. [14:02] I'll try to cover just as much as possible to get us through a quick example and will give you links to more documentation at the end. [14:02] If I go too fast or things don't work for you, speak up. :) [14:02] Here’s what we’ll cover: [14:03] - Installing packaging-related software. This includes: Ubuntu-specific packaging utilities, Encryption software so your work can be verified as being done by you, Additional encryption software so you can securely transfer files. [14:03] - Setting up your development environment to help you do local builds of packages, interact with other developers, and propose your changes on Launchpad. [14:03] Here's the first important note: It is generally advisable to do packaging work using the current development version of Ubuntu. Doing so will allow you to test changes in the same environment where those changes will actually be applied and used. [14:04] So this would mean that you have a version of 'raring' (13.04 which will soon be opened for public participation) running somewhere. [14:04] This obviously doesn't need to be your main machine. Please don't upgrade yet. :-) [14:05] At this point you would have to be very adventurous to do that. [14:05] https://wiki.ubuntu.com/UsingDevelopmentReleases gives you some pointers how to use a virtual machine (or other safe means) to run 'raring'. [14:05] For now: if you run 'quantal' (13.04) you are fine. [14:06] You can take care of setting up a VM later on and just repeat the steps. :) [14:06] err, I just got corrected, 'quantal' is obviously 12.10 :) [14:06] got ahead of myself :) [14:07] vibhav asked: Can I contribute to technical areas of Ubuntu even without knowing any language? [14:07] vibhav, nice one :) [14:07] Obviously the more you generally know about development, the more possibilities you have to be involved. [14:08] Towards the end of the session I will show a quick example of how you can participate by fixing an obvious problem which doesn't require knowledge of any programming language. [14:08] If you are patient and take it slow, you can learn more about programming languages over time and get involved in other parts of Ubuntu as well. [14:08] bogor asked: using VM for testing in software in dev brach of the OS is good move. But how was it done in era before VM's came? [14:09] bogor, you could always run Ubuntu in a separate partition or (if available) on a test machine === dpm__ is now known as dpm [14:09] vmware tools have been available for a very long time already and were widely used before other virtualisation technologies got popular [14:10] there always were chroots as well, which provided you with a very basic separation experience [14:10] and yes, to quote somebody from #ubuntu-classroom-chat - we always had brave people as well who upgraded as soon as a new release was opened :-) [14:10] There are a number of tools that will make your life as an Ubuntu developer much easier. You will encounter these tools all the time. To install most of the tools you will need run this command: [14:11] sudo apt-get install packaging-dev [14:11] or... if you are stuck with an older release (before Ubuntu 11.10 “Oneiric Ocelot”): you can run: [14:11] sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file [14:11] This command will install the following software: [14:12] - gnupg – GNU Privacy Guard contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad. [14:12] - pbuilder – a tool to do reproducible builds of a package in a clean and isolated environment. [14:12] - ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier. [14:12] - bzr-builddeb (and bzr, a dependency) – distributed version control with Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each other’s work. [14:12] - apt-file provides an easy way to find the binary package that contains a given file. [14:12] Any questions so far? [14:13] pune asked: Ubuntu for ARM , How to contribute in embedded domain using Ubuntu ? [14:13] nice question [14:14] pune, the great thing about the Ubuntu Development Community is that all the changes go into Ubuntu itself the same way, so if you decide to work on the Desktop, the Server or a specific architecture (like ARM), the processes will all be largely the same and the changes all eventually go into the same archive [14:15] one thing which is different is that almost every team have their own team IRC channel or team mailing list [14:16] https://wiki.ubuntu.com/ARM/ and https://wiki.ubuntu.com/ARMTeam should help find some people to join the team [14:17] Let's set up pbuilder next [14:17] pbuilder allows you to build packages locally on your machine. It serves a couple of purposes: [14:17] - The build will be done in a minimal and clean environment. This helps you make sure your builds succeed in a reproducible way, but without modifying your local system [14:17] - There is no need to install all necessary build dependencies locally [14:17] - You can set up multiple instances for various Ubuntu and Debian releases [14:17] Setting pbuilder up is very easy, simply run: [14:18] pbuilder-dist create [14:18] where is for example quantal, oneiric or in the case of Debian maybe sid. This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though. [14:18] If you already have a 'raring' virtual machine or installation, 'raring' is also going to work. [14:18] For now it should be fine to use quantal as [14:19] we will use it just for illustration purposes here :) [14:19] This is going to take a while. [14:19] obounaim asked: What about cowbuilder-dist, I think it's a good alternative if you want to save some time? [14:19] obounaim, To be very honest, I have never used it. O:-) [14:20] Maybe it'd be good to bring it up in a mailing list discussion so we can include it in our documentation if it's deemed a better choice. [14:20] QUESTION : dholbach : I want to do some significant contribution in embedded domain like VLSI, I want to understand where does Ubuntu goes in terms of these ? [14:21] pune, I'm afraid I have no idea about VLSI - I'd suggest to use the links I mentioned above to get in touch with the ARM team and ask them directly. They're friendly people and have much more insight into the ARM space than I do. [14:21] MestreLion asked: can I use pbuilder for creating *any* release? for example, oneiric and quental if my system is precise? [14:21] MestreLion, yes - as long as your release knows about the other release, it will create separate pbuilder chroots, which are then used whenever you do a build. [14:22] Next we want to tell the Debian/Ubuntu packaging tools about yourself. Simply open your ~/.bashrc in a text editor and add something like this to the bottom of it: [14:22] export DEBFULLNAME="Bob Dobbs" [14:22] export DEBEMAIL="subgenius@example.com" [14:22] Now save the file and either restart your terminal or run: [14:23] source ~/.bashrc [14:23] (If you do not use the default shell, which is bash, please edit the configuration file for that shell accordingly.) [14:23] I'd recommend to not use "Bob Dobbs" but your own name and email address. :-) [14:24] I skipped a number of steps that you would normally need to do as well: creating a Launchpad account, creating an SSH key, creating a GPG key and registering them with Launchpad [14:24] but as I mentioned earlier - if we want to also work on a small example together it might get a bit much :) [14:25] Did everyone succeed installing the tools, pbuilder and saving your name? [14:25] Any questions or problems? [14:25] Or any other parts we talked about only too briefly? [14:27] vibhav asked: Why are there so many development teams? (MOTU, Core Developers, etc) [14:27] Great question. [14:27] A bit of clarification around the terms. [14:27] MOTU stands for "Masters of the Universe" and traditionally were a team of people who took care of the packages in Universe and Multiverse. [14:28] This is how the team started. The team has always taken care of a lot of other things as well. For example did many new contributors start in the team, because it seemed like a great onramp for many. [14:29] Even if there are different teams nowadays, this is something which happens naturally. If you have people who are interested in a specific thing and they have enough to talk about, they will want to have their own mailing list or irc channel, etc. [14:29] Still all these teams work very closely together, have the same set of rules and work in the same archive. [14:30] It's not a decision you need to take early on. We're all one big family. :) [14:30] The main difference I can see that it determines which kind of upload rights you have. [14:30] If you join the MOTU team, you will have upload rights to 'universe' and 'multiverse'. If you join the "Core Developers team" you will have upload rights to all of Ubuntu. [14:31] Before you get upload rights, you will work with sponsors, who will review your suggested code changes and upload them for you. [14:31] After having gone through this process for some time and after you built a bit of a reputation and trust, you can apply for upload rights. [14:32] smartboyhw asked: I am a bit confused with the relationship between the release team, the core dev team and the main dev team. dholbach can you explain more clearly?:D [14:32] I'm not aware of a 'main dev' team. [14:33] Generally everyone who work on Ubuntu is an Ubuntu developer. Some have upload rights, some don't. Some have access to more packages than others. This depends on their level of demonstrated involvement and expertise. [14:34] The release team is there to make decisions towards the end of the release. If there is a question of getting let's say a big new feature in after Feature Freeze, the release team will get involved to help make a reasonable decision. [14:34] So you have a large team of Ubuntu developers, with different interests, different team affiliations, different levels of access to packages and also you have teams which make decisions when cases are less clear-cut. [14:34] But all in all we all work on the same archive and on making Ubuntu better. [14:35] I hope this helped clarify things a bit. :) [14:36] Alright... let's get our hands dirty. And keep questions coming. [14:37] So we have this tool called lintian, which should be installed on your system now as well. [14:37] It checks our source package for a huge variety of common issues, for example typos. [14:37] lintian told me that the pygmy package has a typo in its package description [14:37] Let's check if that's true [14:37] if you run this command: [14:38] apt-cache show pygmy [14:38] it should you a lot of interesting information about the package, like dependencies, size and so on [14:38] It's what software-center does in a prettier way. ;-) [14:38] If you don't use Ubuntu in English, you can also run: [14:39] LC_ALL=C apt-cache show pygmy [14:39] in the description it shows me this line: [14:39] "Pygmy is a graphical client for MPD with a single, collapsable [...]" [14:39] so collapsable should actually be collapsible [14:39] I know it's a trivial mistake and not a big deal, still we shall use this as a small example to show how you can help out and don't need to get confused about programming languages in the beginning :) [14:40] to get the source of the package, we will run: [14:40] bzr branch ubuntu:pygmy [14:40] which will give us a Bazaar branch of the package revisions of pygmy [14:40] so using bzr you can go through the history of the package [14:41] I got an interesting comment from the ever-watchful cjwatson - give him a hug on #ubuntu-classroom-chat [14:41] dholbach: I suspect lintian is being excessively prescriptive here, as it happens; collapsable appears to be valid in at least American English [14:42] still, let's use this as an example for now - otherwise I will have to go and find a new one ;-) [14:42] (I'm not a native speaker and hope I'm excused. :)) [14:42] Next, to inspect the source and find the problem, we will run: [14:42] cd pygmy [14:42] less debian/control [14:43] we are now looking at one of the central pieces of the packaging [14:43] in the ./debian/ directory of every source package you will find information about the source itself like its license, there are instructions for how to build it and so on [14:44] a lot of the meta-data you can find in debian/control [14:44] the first stanza relates to the source, the second (and sometimes following) stanzas are all about the binary (.deb) packages we want to build [14:44] in our (simple) case it's just one [14:45] and we can see 'collapsable' in the last lines of the file [14:45] please open debian/control in your favourite editor and change it to 'collapsible' [14:45] and save the file [14:46] ok, we fixed the problem, what we need to do next is to document what we did [14:46] if you now run this command in the source tree: [14:46] dch -i [14:46] you will see that debian/changelog was opened in an editor and that a template changelog entry was added for you [14:47] if you did everything correctly it should even have your name and email address [14:47] now, in the line starting with '*' you can add a description of what you fixed [14:47] what I usually try to do is [14:47] - mention where I fixed the problem [14:47] - how I fixed it [14:48] - mention any additional information or discussion of the problem [14:48] so if you have a reference to a bug report or a mailing list discussion [14:48] you want to add it there [14:48] it's important that developers after you have a good chance to understand what you did [14:49] in our small case this looks like overkill, but you can imagine how "fixed the problem" is not enough if you want to get a thousand line change included [14:49] especially if your fix isn't quite as good as you thought :) [14:49] and if you don't do it for others, do it for yourself - if you ever touch the package again you really don't want to spend ages trying to understand what you did 2 months before :) [14:50] ok, what I'll put in there will be something along these lines: [14:50] * debian/control: changed 'collapsable' to 'collapsible'. [14:50] There are 10 minutes remaining in the current session. [14:51] we don't have a reference to a bug report, but if we did, let's say it was bug number 123456789, we'd add something like (LP: #123456789) to it - this will automatically close the bug when the change gets uploaded to the archive [14:51] once you're happy with your changelog entry, save the file [14:51] now run the following command please: [14:51] bzr bd -- -S -us -uc [14:51] this looks terribly complicated, but it's fine - trust me :) [14:52] "-us -uc" we just use because we didn't set up GPG keys in this tutorial, once you've done that you should be fine to drop it [14:53] " bzr bd -- -S" will from the current revision (including local changes) of the branch build a source package, which we can then feed to pbuilder, or upload to our personal package archive on Launchpad [14:53] or if we have upload rights, to Ubuntu [14:53] if you now run: [14:53] cd .. [14:53] and do an 'ls' [14:53] you will see the following files: [14:53] pygmy_0.48-3ubuntu3.diff.gz pygmy_0.48-3ubuntu3.dsc pygmy_0.48-3ubuntu3_source.changes pygmy_0.48.orig.tar.gz [14:54] where pygmy_0.48.orig.tar.gz is the original tarball released by the pygmy software authors [14:54] pygmy_0.48-3ubuntu3.diff.gz are the changes we (and Debian) introduced to make the package build the Debian/Ubuntu way [14:54] pygmy_0.48-3ubuntu3.dsc and pygmy_0.48-3ubuntu3_source.changes are meta data which we'll ignore for now [14:54] now, the magic moment: [14:55] pbuilder-dist build pygmy_0.48-3ubuntu3.dsc [14:55] where is the release for which you set up your pbuilder [14:55] this might take a while and should now go and build the source package for you [14:55] There are 5 minutes remaining in the current session. [14:55] ok, I've got to speed up [14:56] can you maybe open another terminal in the meantime, run 'cd pygmy' and run 'bzr diff' [14:56] then open http://paste.ubuntu.com/ in a browser and paste in the output of 'bzr diff' for us? [14:56] once you've done that, please mention the URL in #ubuntu-classroom-chat please [14:57] we have a number of developers in there who then can go and have a quick look at your change and see if it's alright [14:57] while we do this I want to thank everyone who attended the session - you all are great! [14:57] On Friday at 17:00 UTC coolbhavi will give a session about the MOTU team, so if you like Ubuntu development, make sure you turn up there as well! [14:58] Also please bookmark the following page: http://developer.ubuntu.com/packaging/html/ - it has the most important stuff you will need to get started. [14:59] And if you want to stay up-to-date on other development-related events and initiatives, please consider following @ubuntudev on Twitter, Identica, Google+ or Facebook [15:00] Thanks again everyone, next up is Amber Graner to talk about the News team! [15:00] Thanks dholbach! === 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 Open Week - Current Session: Ubuntu News Team - Instructors: akgraner [15:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/10/24/%23ubuntu-classroom.html following the conclusion of the session. [15:01] Hi everyone! I’m Amber Graner and I am one of the Editors for the Ubuntu News Team. [15:01] Thank you all so much for coming to this session. [15:02] If at any time you have questions just post them in #ubuntu-classroom-chat and I’ll get to them - thanks! [15:02] So what is the Ubuntu New Team? [15:03] s/New/News [15:03] The Ubuntu News Team consists of The Fridge and The Ubuntu Weekly Newsletter (UWN) [15:04] (which are two official news channels of the Ubuntu Porject and staffed by a team of community volunteers) [15:04] oops - project :-) [15:04] Fridge: https://wiki.ubuntu.com/Fridge/ [15:05] The Ubuntu Weekly Newsletter (UWN): https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/ [15:06] The news team with UWN captures a snapshot in time of what is happening in the world of Ubuntu. If you take a look back at the archives you can see what topics are always current and which ones are re-occurring etc. https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Archive [15:07] UWN is like the community - ever growing, changing evolving - what you see today is not the same as the what was there 5 years ago or so === Whisper is now known as WhisperOFP [15:08] If you haven't see the latest issue - Issue 288 it can be found at: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue288 [15:09] The News Team is always looking for volunteers to help put this together - this is also a good way to get started with Ubuntu Community Contribution and a way to see the bigger picture of what is happening throughout the Ubuntu Ecosystem === yofel_ is now known as yofel [15:10] IdleOne asked: Who writes the articles in UWN, can anybody submit an article? [15:11] IdleOne, great question! Thank you! Anyone can submit an article and anyone can become an editor and help write them - this goes for both UWN and the Fridge and I'll get into the details of how to do that in just a few. [15:12] Currently we are working on Issue 289, and we collect the links and put them in a Google Doc found at https://docs.google.com/a/linaro.org/document/edit?id=18ZbtFHQq6uMj7iuRLd11VH8V5Uc_FA0IfgiRUcbMbQk [15:13] If you take a look at the Googledoc - you can see that people just add links to the various sections as they find them, sometimes we have people that add to it daily or if you get busy (like me) I go through my RSS feeds about once a week to see if I see anything that needs to be added [15:13] For those who want to help collect links and add to UWN (keeping in mind that not every link that gets added makes it into the final version of UWN) we keep a list of all the sources we’ve used in the past and update these as we get new sources for news. - Those suggestions by section can be found at: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/LinkSuggestions [15:14] For those who have a few minutes here or there during the week or would like to help write summaries we have guidelines for that as well and over time you’ll get the hang of it and it’s like second nature. Style guidelines can be found at: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/StyleGuidelines [15:17] (I have to pause here to mention that when I started helping at I think issue 176, none of my summaries ever survived the first edit. Someone always corrected something in them and at times nothing of my original summary even existed, but it's how I learned and how most writers learn, through the suggestions (corrections) of their editors - so don't take it personally if something you write gets re-written or even removed from an iss [15:17] ue) [15:17] obounaim asked: What are the main resources for UWM. [15:20] obounaim, interesting question - thanks! - we always look - Ubuntu Planet, Fridge, Canonical voices, Canonical Blog, Brainstorm, Launchpad, LoCo Team News, Archives for updates and security for all current releases that haven'd reached EOL yet, announce lists, ASK Ubuntu, and more [15:21] however you can see a more indepth list of sources at: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/LinkSuggestions [15:21] and if you look there you will see how long and diverse this list is [15:22] about 2 years ago now, myself and a couple of other people went through over 150 issues to compile this list - and it's something we now do about once a year [15:23] (it might have been a little longer than that - time flies when you are having fun and the years all blur together at this point :-D) [15:23] Ok so maybe you are thinking I’d like to help but I just don’t have the time to collect links or write summaries. No worries, editing we also need another set of eyes to go through the wiki before we publish and see if we have hotlinks, spelling or grammatical errors or if someone added their personal feelings to the summary (it happens I mean we all have those topics we are excited about) - https://wiki.ubuntu.com/UbuntuWeeklyNe [15:23] wsletter/StyleGuidelines [15:24] https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/StyleGuidelines [15:25] Maybe you are looking at the current issue and you are thinking where does this information come, from what goes in each section, etc in addition to the Link Suggestions wiki you and look at the raw text of the UWN Template - https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/IssueTemplate [15:25] If you don’t know how to see the raw text - click on the more actions drop down box and you will see the option for raw text. This view gives more insight as to what goes in each section and where you pull the information from. [15:26] obounaim, this should also go along to help answer your earlier question [15:26] If those who are following along can take a minute to look at the raw text version of the template that would be great [15:27] I'll give you a minute - just let me know in -chat when you are there - thanks! [15:28] ok - so if you will look you'll see all the ## commented out sections - these comments explain what goes in each section [15:29] these are especially helpful for pulling the stats, the team updates and the Updates and Security sections [15:30] Maybe you have been learned how to do all the sections, you are comfortable that you can assist and help put the newsletter together or fill in for anyone who can't help for a week and you want to become a publishing editor [15:31] (Yes, it's often a little time consuming and takes some effort - but it is so worth it) [15:32] then you'll need to let the team know you are ready to learn how to publish and we'll help you with the scripts and walk you through the process [15:33] It used to be that one person was responsible, but now we have a whole team of people who help publish and get the news out on FB, Google+, Twitter, Forums, Fridge, Mailing Lists and more [15:33] IdleOne asked: Looks like all the news comes from online sources. What if I don't have a blog and wanted to submit an article to UWN how would I go about it? [15:35] IdleOne, we'll need to get it online somehow - this can be through a guest blog somewhere (ie I have often used my personal blog, and I know jcastro and others have as well, to get news published online) [15:35] the reason we need it to be online is because we have to have a link to point back to [15:38] This questions leads me to the Fridge as well - For a long time now we have tried to figure out how to get original news to the Fridge, in the past this has been through interviews or sources who want the Fridge to have an exclusive story, but because we are more of syndication of news that effects the whole Community it's rare the Fridge has those types of stories - but we are certainly open to suggestions on this [15:39] earlier - vibhav asked - QUESTION: How can I get my Ubuntu related blog post to the Newsletter? [15:40] adding it to the Googledoc is just one way - the other way you can submitted stories, comments, suggestions, feedback is to send an email to: https://lists.ubuntu.com/mailman/listinfo/ubuntu-news-team or drop into the #ubuntu-news IRC channel [15:41] you can submit news for both UWN and The Fridge this way [15:41] https://wiki.ubuntu.com/NewsTeam#Ubuntu_Weekly_Newsletter [15:42] Some other links you may want in addtion to the main News Team wiki are: https://wiki.ubuntu.com/Fridge/ and https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/ [15:44] Personally joining the newsteam and contributing to UWN and later the Fridge has been very rewarding to me and has helped me learn about and navigate the whole of the Ubuntu Community, so if you or someone you know would like to be part of this team feel free to let the team know or email me and I'll be happy to get you pointed in the right direction [15:45] (keep in mind it's better to use the #ubuntu-news channel and the mailing list - it might take me a day or two to respond) [15:46] If there are no other questions; then thank you so much and I look forward to seeing some new contributors to the News Team. [15:48] Ok folks - 10 minute break and then up will be the Ubuntu Flavors Teams (Kubuntu and Lubuntu) - Riddell, phillw and kanliot [15:49] vibhav asked: Can one also add posts to the Newsletter if it is being critical of Ubuntu? [15:50]