=== zyga is now known as zyga-gone [06:44] exit === zyga-gone is now known as zyga === zyga is now known as zygqa === zygqa is now known as zyga [10:39] ##kernel [11:09] hi === firewave is now known as FireWaveJob [13:56] Hello everybody! If I read the clock correctly, we'll start in 5 minutes - now is a good time to tweet/dent/etc. and invite your friends to the event. :-) [14:00] Welcome everybody to day two of Ubuntu Open Week! We still have a lot of great stuff lined up for the week, have a look at the schedule at https://wiki.ubuntu.com/UbuntuOpenWeek - after my double session there'll be one session about Ubuntu Friendly and one about Brainstorm Ubuntu - awesome! [14:00] I'd like to invite you to ask as many questions as you have, this will make the session much move lively and interesting [14:00] for that, please join #ubuntu-classroom-chat and ask your questions in there === 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: Getting Started with Ubuntu Development - Part 1 - Instructors: dholbach [14:01] please prefix them with QUESTION: [14:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html following the conclusion of the session. [14:01] luckily with the help of the Ubuntu Packaging Guide team I have a lot of the content already prepared, so you will spend less time waiting for me to have typed everything [14:01] and we have more time for questions [14:02] if anything's unclear or weird or doesn't make sense, please ask :) [14:02] woo, welcome back everyone! [14:02] jcastro, want to say a few words? [14:03] hum, I guess I'll get started then :) [14:03] nope, just take it away! [14:04] ok, so in the double session today, I'd like to introduce you to the world of Ubuntu development, so explain what the big moving parts are, how we work and which other actors are involved [14:04] you won't be a pro after this, but I hope you'll at least have heard of the most important things afterwards :-) === Guest80549 is now known as jsjgruber [14:04] in the second part, I'll help you get your development environment set up and maybe we even have time to have a look at trying to fix a bug [14:05] 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. [14:05] Source packages in most cases consist of two parts: the actual source code and metadata. Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. [14:05] Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install. [14:06] 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. The resulting binary packages then are distributed to the archive and its mirrors in different countries. [14:06] he URLs in /etc/apt/sources.list point to an archive or mirror. Every day 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. [14:07] Sorry... I meant to say "The URLs in /etc/apt/sources.list ..." [14:07] So far so good? Any first questions already? [14:08] Ok, let's talk a bit about the release cycle then... please have a look at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule [14:08] it's a draft of the release schedule of the 12.04 cycle [14:09] Ubuntu’s development is very much dependent on the current stage of the release cycle. [14:09] We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. With every freeze date that is reached developers are expected to make fewer, less intrusive changes. [14:09] 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. [14:09] 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. [14:10] 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. [14:10] QUESTION Is it possible for non programmers to develop? [14:10] tcarrondo, great question - thanks [14:11] the answer is: you can easily start your journey as an Ubuntu developer without a huge background in programming, but you need a few skills still [14:12] what I personally feel is important for a new contributor to development is: having a knack for making things work again, patience, no fear of documentation, being a good team player and not being afraid of asking a few questions [14:13] it obviously helps if you have spent years programming, but it's not a strict prerequisite - through some dedication and an interest in the area, you will learn quickly enough [14:13] the great thing about Ubuntu is: the code is open, getting the code and learning from making small changes to it is quite natural [14:13] ... if you have the skills/interests I mentioned above :) [14:14] navneeth asked: dholbach: What's the difference between Feature Def. freeze and Feature freeze? [14:14] another great question, thanks navneeth [14:15] navneeth, I'll go into a bit more detail in a bit, the short answer is: the features and big changes are discussed and defined during the first phase of the development cycle (at Ubuntu Developer Summit) [14:15] so that's where a lot of people come together, discuss, make plans (at UDS) and write up specifications (after UDS) [14:16] at Feature Definition Freeze we expect the plan to be established [14:16] any more questions about the release cycle and the general introduction? [14:16] ok, let's talk about UDS and generall communication/coordination then [14:16] 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. [14:17] 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. 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. [14:17] korky2 asked: What is UDS? [14:17] korky2, it's the Ubuntu Developer Summit [14:17] This is all done in an open and transparent fashion, so even if you can not 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. [14:18] Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. That is why contributors to Ubuntu constantly stay in touch. [14:18] 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. [14:19] 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. 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. [14:19] so far so good? [14:20] let's talk about the projects around Ubuntu then [14:20] 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. These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it. [14:21] The relationship to Upstreams is critically important to Ubuntu. 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). [14:23] Obviously a lot of developers are part of more than one project. so there's Ubuntu developers, who have a deep interest in some other project and they actively participate in there, make sure that communication channels work between both of them and contribute code there. [14:23] Being an "ambassador" between projects is a great contribution to the Open Source world in its own. [14:24] 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. [14:24] 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. [14:25] What this means in practise is that Debian and Ubuntu are both distributions, both having similar, but sometimes divergent goals and release cycles, so some coordination is necessary. [14:26] If you remember the release cycle I mentioned above, you saw how 12.04 will have freeze dates a lot earlier than usual. [14:26] This is because 12.04 will be an LTS (Long Term Support) release, so developers who make a decision which code to import from Debian have to do this a lot more carefully. [14:27] ie: back off from importing a crazy new unstable piece of code and stay with the stable one, or if they decide to bring it in, then make sure it lands early in the cycle [14:27] so we have the time to test and fix or roll back if necessary [14:28] next I'd like to talk a bit about how you can get changed into Ubuntu, because that's probably what you all are most interested in :) [14:28] 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. [14:29] 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. [14:29] 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. [14:30] In practise finding the fix is probably the hardest bit in there, but the process around getting the fix reviewed and everything is quite simple - I'll sort-of-demo this in the second part. [14:30] 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. [14:30] Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream. [14:31] This was a huge amount of information now - you must have questions! Or do you all feel you know enough to get rocking and rolling already? [14:32] Ok, you look like you're all much cleverer than I was, when I started getting involved! Great! :-) [14:33] As I mentioned earlier: 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 might be interested in working on a new big feature while Ubuntu, because of the tight release schedule, might be interested in shipping a solid version with just an additional bug fix. [14:34] 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. [14:34] are most bugs located in the "upstream" package or does the packaging process induce bugs? [14:34] mblank, fantastic question [14:34] Most bugs are upstream bugs. [14:35] Which is why Launchpad has this great feature of tracking bugs in other bug trackers. [14:35] So for example I find a but in gedit, and it's bug number X in Launchpad, we identify that it's a bug in the upstream code, so we forward it with all relevant information to the gnome bugzilla, there it has bug number Y. [14:36] Launchpad can let us know when the bug status upstream changes, so for example if they need more info or when they fixed the bug. [14:36] Launchpad can also sync bug comments, so you always have all info in one place, which make collaboration a lot easier [14:37] Good examples for bugs in the packaging are: wrong or missing dependencies, missing/wrong build options or bugs in patches needed to integrate the package better [14:37] (there's very likely loads more... :-)) [14:37] jamdatadude asked: so how does one make sure to get the information proper for both ubuntu and the upstream? === AninhasK is now known as Aninhas [14:38] It depends what you mean by information: if you want to forward a bug report for example, you want to make sure that the bug is not already fixed in a newer version of the software, or that it's not because of a patch we applied [14:38] also you want to include a test-case and the exact circumstances when the bug happens [14:39] ikt asked: will there be greater intergration with lp and upstream? At the moment most bug reports go against packages listed in launchpad, but wouldn't it make more sense to have apport report the bug directly against the upstreams bug tracker? no sense in making the same bug report twice? [14:40] ikt, there are some upstream maintainers who want to know about every Ubuntu bug, they subscribe to the package in Launchpad and they deal with feedback there [14:40] for some upstreams with big projects that get lots of bug reports this option is not feasible [14:40] they rely on us to make sure that all the information is collected and that it's clearly identified that it's an issue they need to fix [14:41] also do we use the bug reports in Launchpad for our own communication [14:41] let's say there's an important crasher bug in gedit - gedit is a very important package: we can't have the text editor crash by the end of release [14:42] which is why we target the bug report to a milestone in Ubuntu, so the people who care about the desktop, also the release team know what we still need to fix [14:42] any more questions? [14:42] if not, I'll crack on and talk a little bit about Distributed Development [14:43] please have a look at http://developer.ubuntu.com/packaging/html/_images/cycle-branching.png [14:43] In this example it would make sense to ship Ubuntu 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. [14:44] You can imagine the different code branches as streams of changes, as a developer you often have to make a decision, which of these you are willing to integrate at the current time of the release cycle. [14:45] In any case you want to make sure that eventual divergences are merged back. [14:45] Not merging them means having to maintain your changes in your own branch for the time, which can become quite expensive. [14:46] To sum this up and to reiterate what I said earlier: 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. [14:47] Good places to ask your questions are ubuntu-motu-mentors@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. [14:47] This is part 1 of what I wanted to talk about - are there general question you still have? [14:49] alright - let's get cracking and let's set up our development environment together :-D [14:49] There are a number of things you need to do to get started developing for Ubuntu. This article is designed to get your computer set up so that you can start working with packages, and upload your packages to Ubuntu’s hosting platform, Launchpad. [14:49] oops, replace "this article" with "this session" :-D [14:50] over-eager copy and pasting I'd call this :) [14:50] mblank_ asked: you copy the upstream SW at some point in time and then work with this copy until the next ubuntu releas? [14:50] mblank, nice question [14:50] essentially yes [14:50] if you go back to the wiki page with the release schedule you can see Debian Import Freeze [14:51] and Feature Freeze [14:51] at DIF we basically stop the semi-automatic import of source packages from Debian [14:51] There are 10 minutes remaining in the current session. [14:51] at Feature Freeze we expect new upstream versions to just fix bugs or we ask to file a freeze exception with the release team [14:51] Armin asked: My biggest problem is where to start from, find a bug and fix it is not so easy as it sounds. Do you have any tips on this? [14:52] Armin, yes, a good question - I'll go into a bit more detail about this later on [14:52] generally it depends what you want to work on [14:52] if you are interested in a specific piece of software or a set of packages (based on their functionality or programming language), it's easy to spot these and get cracking on bugs, etc [14:53] if you don't know yet, it's a bit harder [14:53] for the beginners I'd recommend to start working on a really small, really isolate bug [14:53] such as a typo, or a bug that was tagged as 'bitesize' [14:54] so you have something easy to immediately spot, fix, build, test and get uploaded [14:54] alright, let's crack on with our development environment [14:54] We'll cover: [14:54] Installing packaging-related software. This includes: [14:55] Ubuntu-specific packaging utilities [14:55] Encryption software so your work can be verified as being done by you [14:55] Additional encryption software so you can securely transfer files [14:55] Creating and configuring your account on Launchpad [14:55] Setting up your development environment to help you do local builds of packages, interact with other developers, and propose your changes on Launchpad. [14:55] There are 5 minutes remaining in the current session. [14:56] It is 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:56] Don’t worry though, the Ubuntu development release wiki page shows a variety of ways to safely use the development release: https://wiki.ubuntu.com/UsingDevelopmentReleases [14:56] for now, if you run oneiric or some other release, that's totally fine - you can always just retrace the steps of this session if you install the "precise" development release in a vm later on [14:57] There are a number of tools that will make your life as an Ubuntu developer much easier. You will encounter these tools later in this guide. To install most of the tools you will need run this command: [14:57] sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file [14:58] If you run oneiric (11.10) (or if you have Backports enabled on a currently supported release), the following command will install the above and other tools which are quite common in Ubuntu development: [14:58] sudo apt-get install packaging-dev [14:58] This command will install the following software: [14:58] 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:58] pbuilder – a tool to do a reproducible builds of a package in a clean and isolated environment. [14:58] ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier. [14:58] 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 others work. [14:58] apt-file provides an easy way to find the binary package that contains a given file. [14:59] apt-cache (part of the apt package) provides even more information about packages on Ubuntu. [14:59] I know this will, depending on your bandwidth, take a bit of time. So let's have some questions! [15:00] cdunlap asked: When I set up my environment, do i need to add the deb-src for precise? if so, where do I find that info [15:00] cdunlap, nice one! [15:00] No, for now it's not necessary. === 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: Getting Started with Ubuntu Development - Part 2 - Instructors: dholbach [15:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html following the conclusion of the session. [15:01] but if you want to use 'precise' in a safe manner afterwards for your development, check this out and bookmark it: https://wiki.ubuntu.com/UsingDevelopmentReleases [15:01] it will show you ways to do this safely, so for example by using a virtual machine, setting up a chroot or other means [15:02] immediately upgrading to 'precise' is only for folks who have no problem with dealing daily new pain [15:02] 'precise' was just opened as a development release a day or two ago, so there's still lots of moving bits and pieces that will break :) [15:02] ok... packages installed? everybody all set? [15:03] awesome [15:03] First of all, we'll create our GPG key. [15:03] If you did that already, you can just lay back and do nothing. :-) [15:03] GPG stands for GNU Privacy Guard and it implements the OpenPGP standard which allows you to sign and encrypt messages and files. This is useful for a number of purposes. In our case it is important that you can sign files with your key so they can be identified as something that you worked on. If you upload a source package to Launchpad, it will only accept the package if it can absolutely determine who uploaded the package. [15:04] To generate a new GPG key, run: [15:04] gpg --gen-key [15:04] GPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure. [15:04] Afterward, it will ask you if you want it to expire the key at some stage. It is safe to say “0”, which means the key will never expire. The last questions will be about your name and email address. Just pick the ones you are going to use for Ubuntu development here, you can add additional email addresses later on. Adding a comment is not necessary. [15:04] Then you will have to set a passphrase, choose a safe one (a passphrase is just a password which is allowed to include spaces). [15:05] Now GPG will create a key for you, which can take a little bit of time; it needs random bytes, so if you give the system some work to do it will be just fine. Move the cursor around, type some paragraphs of random text, load some web page, etc. [15:06] Please speak up, if we're going too fast or if I don't make sense, OK? I hope you're all just quiet because you're busy setting up your key. :-) [15:06] mblank_ asked: I already have a PGP Key in Launchpad, do I need a new one for development participation? [15:06] mblank, no, if you do, and have it already in LP, you're all set [15:06] Atamisk asked: Is there a way to migrate one PGP key from system to system? [15:07] Atamisk, yes, fortunately [15:07] and as a bonus, it's very simple: just copy over the whole ~/.gnupg/ directory :) [15:07] done [15:07] you might still have to hook up your key with your email client or wherever you make use of it, but that should be it [15:08] ok, let's crack on and set up our SSH key [15:08] again: if you have an SSH key already, no need to bother, just relax and lay back :) [15:08] jamdatadude asked: Can we use Ubuntu one to sync that .gnupg directory? [15:09] jamdatadude, you can, but I personally would be a bit reluctant - please note that this directory contains also your private key, so the very bit which through the act of signing or encrypting proves to others that you are you [15:10] I'm sure the Ubuntu One engineers made the experience as safe as they could, still this is nothing I personally would give out of my hands :) [15:10] ok, SSH key [15:10] SSH stands for Secure Shell, and it is a protocol that allows you to exchange data in a secure way over a network. It is common to use SSH to access and open a shell on another computer, and to use it to securely transfer files. For our purposes, we will mainly be using SSH to securely upload source packages to Launchpad. [15:10] To generate an SSH key, enter: [15:10] ssh-keygen -t rsa [15:10] The default file name usually makes sense, so you can just leave it as it is. For security purposes, it is highly recommended that you use a passphrase. [15:10] (If your GPG key is not created yet, just open another terminal.) [15:11] hannie asked: Is an openPGP key the same as a PGP key? [15:12] gpg (GNU Privacy Guard) implements the OpenPGP standard [15:12] I suggest you have a look at http://gnupg.org/ which discusses this in detail [15:13] ok, let's crack on, because this is another piece of software which will take a bit longer to get set up [15:13] Set up pbuilder! [15:13] pbuilder allows you to build packages locally on your machine. It serves a couple of purposes: [15:13] - 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 [15:13] - There is no need to install all necessary build dependencies locally [15:13] - You can set up multiple instances for various Ubuntu and Debian releases [15:13] Setting pbuilder up is very easy, run: [15:13] pbuilder-dist create [15:14] where is for example precise, oneiric, natty, maverick, lucid 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. [15:14] Again: while this runs, just open another terminal. [15:15] The next thing we'll do is: tell a few tools a bit about who we are. [15:16] First, we'll configure Bazaar [15:16] Bazaar is the tool we use to store code changes in a logical way, to exchange proposed changes and merge them, even if development is done concurrently. It is used for the new Ubuntu Distributed Development method of working with Ubuntu packages. [15:16] To tell Bazaar who you are, simply run: [15:16] bzr whoami "Bob Dobbs " [15:16] bzr launchpad-login subgenius [15:17] You get bonus points for using your real name and not Bob Dobbs! [15:17] whoami will tell Bazaar which name and email address it should use for your commit messages. With launchpad-login you set your Launchpad ID. This way code that you publish in Launchpad will be associated with you. [15:17] Note: If you can not remember the ID, go to https://launchpad.net/~ and see where it redirects you. The part after the “~” in the URL is your Launchpad ID.) [15:18] And as a last step: [15:18] Similar to Bazaar, the Debian/Ubuntu packaging tools need to learn about you as well. Simply open your ~/.bashrc in a text editor and add something like this to the bottom of it: [15:18] export DEBFULLNAME="Bob Dobbs" [15:18] export DEBEMAIL="subgenius@example.com" [15:18] Now save the file and either restart your terminal or run: [15:19] source ~/.bashrc [15:19] (If you do not use the default shell, which is bash, please edit the configuration file for that shell accordingly.) [15:19] If something just went too quick for you: no problem, you can always go back to the log of this session and retrace your steps. [15:20] Did anybody face any problems? Or has any questions about what we just covered? [15:20] jamdatadude asked: bzr complained that I was missing an SSH key [15:20] ha! good point jamdatadude! [15:21] I guess what happened was that you created your SSH key alright (does ~/.ssh/id_rsa.pub exist?) but Launchpad did not know about it yet.... which leads us to our next step :) [15:22] You can paste your public SSH key (the public one is fine, not the secret one) into https://launchpad.net/~/+editsshkeys [15:22] Insert the contents of your public key (usually ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub) into the text box and submit. [15:23] Now rerunning the two bzr commands above should work. [15:24] Did creating your GPG key finish already? [15:24] Once this is done, you will get a message similar to this one: [15:24] pub 4096R/43CDE61D 2010-12-06 [15:24] Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D [15:24] uid Daniel Holbach [15:24] sub 4096R/51FBE68C 2010-12-06 [15:25] If you look closely, in this case 43CDE61D is the key ID. [15:25] (but you can always find out about yours, if you run gpg --fingerprint ) [15:25] Next, you need to upload the public part of your key to a keyserver so the world can identify messages and files as yours. To do so, enter: [15:26] gpg --send-keys [15:26] This will send your key to one keyserver, but a network of keyservers will automatically sync the key between themselves. Once this syncing is complete, your signed public key will be ready to verify your contributions around the world. [15:26] Once all of this is done, you can register your GPG key at https://launchpad.net/~/+editpgpkeys - you can do this later and I'll give you a link to all these instructions later on [15:26] Barzogh asked: is it possible to get a mentor that would help us to begin efficiently on software packaging ? i've already set up my environnement ( pbuilder, etc... ) [15:27] Barzogh, great question [15:27] Barzogh, we tried the concept of 1-on-1 mentoring before, but we struggled quite a bit [15:28] there was a huge mass of contributors who wanted a mentor, so we looked hard for people to mentor - a lot of people never followed up responsibly, so we didn't get much out of it, which is very unfortunate [15:28] the good news is: we have great docs (I'll give links later on) [15:28] and we have very friendly people on #ubuntu-motu who will take your questions [15:28] and there's also ubuntu-motu-mentors@lists.ubuntu.com for those of you who prefer mailing lists [15:29] also will I try to organise more packaging initiatives this cycle, so we work on packaging challenges together as a team [15:29] which will making get involved a lot easier [15:29] just follow @ubuntudev on twitter, identi.ca or facebook.com if you want to get updates [15:30] hannie asked: does it matter on which computer I use the pgp key? [15:30] hannie, no, you can re-use your gpg key on whichever computer you want [15:30] just make sure you copy over the ~/.gnupg/ directory === gnunezr is now known as Guest6735 [15:31] I know I rushed through these whole instructions a bit quickly, but I hope you generally managed to take it all in :) [15:31] More questions? [15:31] If not, I'll talk about fixing bugs in Ubuntu in the next 30 minutes [15:32] http://developer.ubuntu.com/packaging/html/_images/fixing-a-bug.png has a quick illustration of the process of fixing bugs [15:32] As you can see in the image above, there is no surprises in the process of fixing bugs in Ubuntu: you found a problem, you get the code, work on the fix, test it, push your changes to Launchpad and ask for it to be reviewed and merged. [15:32] -- Finding the problem -- [15:32] There are a lot of different ways to find things to work on. It might be a bug report you are encountering yourself (which gives you a good opportunity to test the fix), or a problem you noted elsewhere, maybe in a bug report. [15:33] Harvest is where we keep track of various TODO lists regarding Ubuntu development. It lists bugs that were fixed upstream or in Debian already, lists small bugs (we call them ‘bitesize’), and so on. Check it out and find your first bug to work on. http://harvest.ubuntu.com [15:33] -- Figuring out what to fix -- [15:33] If you don’t know the source package containing the code that has the problem, but you do know the path to the affected program on your system, you can discover the source package that you’ll need to work on. [15:33] Let’s say you’ve found a bug in Tomboy, a note taking desktop application. The Tomboy application can be started by running /usr/bin/tomboy on the command line. To find the binary package containing this application, use this command: [15:34] apt-file find /usr/bin/tomboy [15:34] This would print out: [15:34] tomboy: /usr/bin/tomboy [15:34] Note that the part preceding the colon is the binary package name. It’s often the case that the source package and binary package will have different names. This is most common when a single source package is used to build multiple different binary packages. To find the source package for a particular binary package, type: [15:34] apt-cache showsrc tomboy | grep ^Package: [15:35] Which will print out: [15:35] Package: tomboy [15:35] If you type: [15:35] apt-cache showsrc python-vigra | grep ^Package: [15:35] It will print out: [15:35] Package: libvigraimpex [15:35] The latter example is a case, where one source package builds multiple binary packages. [15:36] Can anyone think of a good reason to have one source package build multiple binary packages? [15:37] Ok, I can easily clear this up: in some cases you might want to not give the user the burden to install EVERYTHING. [15:37] Let's say you have a small tool which is 15k big, but you have 5MB of documentation - in this case you might want to split the two. [15:38] Also if there are multiple libraries or tools with lots of different dependencies, you might want to split them up properly. [15:38] -- Getting the code -- [15:39] Once you know the source package to work on, you will want to get a copy of the code on your system, so that you can debug it. In Ubuntu Distributed Development this is done by branching the source package branch corresponding to the source package. Launchpad maintains source package branches for all the packages in Ubuntu. [15:39] Once you’ve got a local branch of the source package, you can investigate the bug, create a fix, and upload your proposed fix to Launchpad, in the form of a Bazaar branch. When you are happy with your fix, you can submit a merge proposal, which asks other Ubuntu developers to review and approve your change. If they agree with your changes, an Ubuntu developer will upload the new version of the package to Ubuntu so that everyone gets t [15:39] he benefit of your excellent fix - and you get a little bit of credit. You’re now on your way to becoming an Ubuntu developer! [15:39] So far so good? [15:40] -- Work on a fix -- [15:40] There are entire books written about finding bugs, fixing them, testing them, etc. If you are completely new to programming, try to fix easy bugs such as obvious typos first. Try to keep changes as minimal as possible and document your change and assumptions clearly. [15:41] Before working on a fix yourself, make sure to investigate if nobody else has fixed it already or is currently working on a fix. Good sources to check are: [15:41] - Upstream (and Debian) bug tracker (open and closed bugs), [15:41] - Upstream revision history (or newer release) might have fixed the problem, [15:41] - bugs or package uploads of Debian or other distributions. [15:42] mblank_ asked: What process should I follow if I found out that there is an upstream fix already? [15:42] mblank, nice one! [15:43] this depends entirely on where we are in the release cycle [15:43] so let's say it's just one more week until release and you want to make sure we fix the bug before the release gets out [15:43] in this case you want to try to incorporate just the minimal patch that is required to fix the issue [15:43] the same goes for fixing bugs post-release [15:44] ie. if you want to get a fix into oneiric-updates now [15:44] we call this a SRU, a Stable Release Update [15:44] in this cases we want to make absolutely sure that this just fixes the specific issue and nothing else, so we don't bring in additional regressions, etc. [15:45] if we're early in the release cycle, you might want to include the whole new upstream release, which is then allowed to also bring in new features and the like [15:46] I'll later give a link to instructions on how to use the tools to integrate patches like that easily. I fear we won't have the time in the last 14 minutes. [15:46] More general questions? [15:47] ok, let me then just quickly cover the rough basics of using Ubuntu Distributed Development [15:47] to get the source code for package, you run [15:47] bzr branch lp:ubuntu/ (for the latest development release, 'precise' in our case) [15:47] and [15:47] bzr branch lp:ubuntu// (for any other release) [15:48] hannie asked: can I use this procedure when I find typos in GUI or documentation? [15:48] hannie, yes, the process is always the same [15:49] if you are asking about SRU fixes, typos might not qualify as super serious bug fixes, unless they seriously break things, but the process is the same, yes [15:50] so if you branched a package, you can edit and make changes to your hearts delight, Bazaar makes it easy for you to stay focused and on top of things [15:50] http://doc.bazaar.canonical.com/bzr.2.4/en/mini-tutorial/index.html is a nice tutorial, if you're not familiar with commands such as "bzr diff", "bzr add/remove", "bzr log" and the like [15:51] One thing I still want to say about documenting changes [15:51] There are 10 minutes remaining in the current session. [15:51] I mentioned earlier how important it is to communicate very clearly [15:51] You don't want anybody to second-guess why you made changes or where exactly they were [15:52] have a look at https://launchpad.net/ubuntu/+source/gedit/2.22.3-0ubuntu2 to see an example of a changelog entry [15:52] Again: It is very important to document your change sufficiently so developers who look at the code in the future won’t have to guess what your reasoning was and what your assumptions were. Every Debian and Ubuntu package source includes debian/changelog, where changes of each uploaded package are tracked. [15:53] You want to let others know: [15:53] 1. where the change was done [15:53] 2. what was changed [15:53] 3. where the discussion of the change happened [15:53] In our (very sparse) example the last point is covered by "(lp: #236953)" [15:53] which refers to Launchpad bug 236953. Bug reports or mailing list threads or specifications are usually good information to provide as a rationale for a change. As a bonus, if you use the LP: # notation for Launchpad bugs, the bug will be automatically closed when the package is uploaded to Ubuntu. [15:54] so once you're done with your changes, you can easily commit them and push them by running: [15:54] bzr commit [15:54] (which will commit the change locally) [15:54] To push it to Launchpad, as the remote branch name, you need to stick to the following nomenclature: [15:54] bzr push lp:~/ubuntu/// [15:55] So for example: [15:55] bzr push lp:~emmaadams/ubuntu/natty/specialpackage/fix-for-123456 [15:55] then you can run "bzr lp-open", which will open the corresponding page on Launchpad, where you can click on “(+) Propose for merging” link, to get the change reviewed by somebody and included in Ubuntu. [15:55] There are 5 minutes remaining in the current session. [15:56] We have 5 minutes left and I want you just do one more thing for me: [15:56] please bookmark http://developer.ubuntu.com/packaging/html/ [15:56] it's all you should need for the next time, it will help you get started [15:56] also drop by in #ubuntu-motu [15:56] and don't hesitate ask your questions on ubuntu-motu-mentors@lists.ubuntu.com [15:56] I know we had to rush through a lot of content in these 2 hours, so it was very compact. [15:57] Maybe we have 1 or 2 closing questions? [15:57] in the mean time please bookmark http://developer.ubuntu.com/packaging/html/ :-) [15:57] (and make sure you follow @ubuntudev on identica, twitter or facebook) [15:58] You are all awesome and I hope to see more of you in the 'precise' cycle! Thanks a lot everybody! :-) [15:59] Next up is: "Is your system Ubuntu Friendly? Contributing to the community hardware testing program" -- Daniel Manrique (roadmr) [15:59] roadmr, the stage is yours [16:00] Thanks! [16:00] Hello everyone! I'll be talking about Ubuntu Friendly. It'll be a rather hands-on session, with a nice website and a small application involved. [16:00] Please feel free to ask questions in #ubuntu-classroom-chat at any time. [16:00] So, is your computer Ubuntu Friendly? First, let me tell you what Ubuntu Friendly means. === 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: Is your system Ubuntu Friendly? Contributing to the community hardware testing program - Instructors: roadmr [16:01] It means that your computer runs Ubuntu well, and that your devices work as you would expect them to, without needing to configure a lot of things in a difficult way. [16:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-classroom.html following the conclusion of the session. [16:01] We don't actually say that a computer is or isn't Ubuntu Friendly; rather, each model gets assigned a rating (from 1 to 5 stars) indicating how friendly it is. [16:02] Think of it as a "friendliness meter" :) Ubuntu Friendly is still in Beta phase, but we're already producing some interesting and useful information. [16:02] It's also an area where it's very quick and easy to contribute to the Ubuntu community. I'll show you how in a short while. [16:02] So, why do you care about this, as an Ubuntu user? [16:02] So, why do you care about this, as an Ubuntu user? [16:03] sorry :) By visiting the website at http://friendly.ubuntu.com you can see friendliness ratings for systems that have been tested by other users like you. [16:03] You can use these ratings to decide which computer to buy next, ensuring that it will work well with Ubuntu. Or maybe to see what other people say about the one you currently own. [16:04] Maybe your company wants to buy computers to run Ubuntu and you'd like to recommend a model that works well. [16:04] Or maybe you have a device that's giving you trouble and you'd like to see how it's working for other users with the same model. [16:04] In any case the friendliness ratings are quite useful. [16:04] As you may know, there is a list of hardware that’s certified for Ubuntu (http://www.ubuntu.com/certification). Being on this list depends on manufacturers requesting certification for their systems. [16:05] Corporations care about certification, as they like having support from Canonical, but end-users just care about sharing information and getting a system that works. [16:05] Ubuntu Friendly wants to fulfill this need by providing data on a lot more models, thanks to contributions by users like you. [16:05] Friendliness is not calculated based on a "subjective" rating given by testers. A system testing tool is run on each system, performing a series of automated and manual tests. [16:06] This collected data is aggregated to produce both the friendliness rating, and some more detailed reports on each system. [16:06] Let's begin by looking at the existing ratings. If you could please go to http://friendly.ubuntu.com you can take a look at information on several systems. [16:07] Are you all already there? :) [16:07] The website's interface is quite simple: first you'll see a listing of systems (by make and model), their Ubuntu Friendly rating, and the number of people who have rated, or tested, each system. [16:07] At a glance you also get information on the CPU (little cog), GPU (screen icon) and wireless (WiFi icon) for each model. [16:08] If you click on a model's name (you can do it, open this: http://bit.ly/p2yhmw) you'll see detailed information about each system. [16:08] gersitar asked: this is suppose to be a q/a format session or more like a lecture? [16:09] If you have specific questions about the ratings and testing process there'll be time for that in a bit :) for now I'm showing this to people who may not have seen it before [16:10] So we're looking at a model's page for a Samsung laptop. [16:10] Here you'll get a list of all components in a system, and how many people reported each component as working correctly. [16:10] You will notice components are split into "core" and "additional" components. The "stars" for each system are calculated taking this into account. [16:11] For a system to have five stars, all components (core and additional) need to be reported as working. This is a system that works pretty much flawlessly with Ubuntu. Maximum friendliness! [16:11] A system for which all core components work, but for which none of the available additional components work well, will get only three stars. [16:11] A three-star system is considered "usable" but you may have trouble with some non-essential components. Friendly enough! [16:12] A system which reports failures on at least one core component (meaning it's going to give trouble in an essential area) will get only one star. This is a quite unfriendly system. Imagine a laptop with no working WiFi! [16:12] The split between "core" and "additional" components varies for laptops and desktop systems. The rating displayed on the website takes this into account. [16:13] The system I picked has a rating of 3.6, since all core components passed the tests it gets 3 stars, plus 0.6 for the working additional components. It’s friendly and usable enough but not all additional components will work. [16:13] The friendliness rating you see on the front page is an average of all reports. On the detailed view for a system, you can see (top right) the same rating, and a histogram of people reporting for each star rating. [16:14] Thus if you see an average rating of 3 stars with 20 reports, but 10 of those are 1-star and the other 10 are 5-star, you may wish to do some deeper research before considering this system. [16:14]