=== cyril is now known as Steap === ono is now known as Guest54949 === jmarsden_ is now known as jmarsden === achiang` is now known as achiang === msnsachin12 is now known as msnsachin === deegee_ is now known as plustwo [11:18] [11:19] q [12:14] Hello Guys !' [12:15] will something happen ? [12:15] or else i am off ! [12:18] thetechfreak, see the timetable [12:19] thetechfreak: http://people.ubuntu.com/~nhandler/classroom.html [12:20] AbhijiT: anything started ? [12:21] no [12:21] Hmmm.. I'll return in an hour.Have some work [12:21] Bye [12:21] BTW who's going to conduct it ? [12:22] any head or something like that ?? [12:35] hey people [12:35] I'm new here [12:35] Good evening to everyone [12:41] ?? [13:14] QUESTION [13:20] hi [13:22] Nitesh, hi! === peri4n is now known as perian [13:57] can anyone tell me where to find new bugs to triage.i wish to start bug triaging but always find already triaged bugs [14:00] Fvic: All the untiaged bugs can be found through this link . https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&field.status%3Alist=New&field.importance%3Alist=Undecided&assignee_option=none&field.assignee=&field.owner=&field.component=1&field.component=2&field.component-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_no_package.used=&search=Search [14:00] untriaged* [14:06] hello everybody.. :) [14:06] hi! [14:07] wolfpack, sir i was trying to triage one of the bug from your link.can you please help in that.Further i can proceed myself.i dont know how to comment to that bug. [14:08] techbreak, hi [14:08] Fvic, so how long to start the developers week ? [14:09] techbreak, i am abeginner in it [14:09] techbreak: 2 hours, I guess. Start time is 16:00 UTC [14:10] techbreak, 16.00 utc [14:10] Fvic, tumbleweed how much time lag or lead UTC with greenwich time. I am in India :/ [14:10] techbreak, 21.30 india [14:11] Fvic, thanks :) [14:11] can anyone help in bug triaging,i am new to this domaini.??plz [14:18] Fvic, this may help: https://wiki.ubuntu.com/Bugs/HowToTriage === yofel_ is now known as yofel [14:53] test [15:03] what does apport-collect do? [15:04] Fvic: https://wiki.ubuntu.com/Apport#Tools [15:06] I thought this channel was used only for tuition ubuntu classroom... [15:07] rhohit, _ [15:11] is ubuntu dev week about to start in less than an hour? [15:11] fisch246, yeah indeed :) [15:11] good i read the schedule right :) [15:12] fisch246, :) [15:14] techbreak hello [15:14] rhohit, :) gotcha [15:14] rhohit, welcome :) === marc is now known as Guest88175 [15:27] I guess I'm late. Everything is over :( [15:28] nilesh, did not start yet [15:28] joaopinto: running late? [15:29] no, it's still Seg Fev 28 15:28:49 UTC 2011, isn't it scheduled for 16h ? [15:29] yes it is [15:29] so it's on time :) [15:29] hmm, I guess I didn't read the time properly on the fb event [15:29] anyways [15:30] nilesh, date -u, it's at UTC 5pm [15:30] but i think that the ubuntu-classroom-chat is for discussion [15:30] this one is for the teacher [15:30] yep [15:31] * hemanth this room will be muted as the class starts [15:31] * nilesh has a bad luck. has to get up early tomorrow, so can't be at 11 pm IST here :( [15:32] nilesh, you will always have the logs to read :) [15:41] hey guys. am i right in saying the session is going to start in about 20 minutes? or is my understanding of UTC way off? [15:41] is anyone allowed too watch/participate? [15:41] Will123456, yes, 20 minutes [15:41] gartral, yes, everyone can watch [15:41] Will123456: you're right, but you should joing #ubuntu-classroom-chat to talk about it :p [15:41] Will123456, yes , the session will start in 20 min [15:42] cyril: just noticed that - sorry. :P teach me to type before thinking. thanks everyone. [15:52] will te session be involving video? [15:52] saket: no, text only [15:52] dholbach, hmm, okay [15:52] saket: but you can sign up here for a development videocast I do: http://www.ustream.tv/channel/ubuntu-development-with-daniel-holbach [15:53] dholbach, okay [15:54] so how more minutes to go ? [15:54] techbreak, 5 [15:55] Hello [15:55] dholbach, :) [15:55] you shouldn't talk here... go to #ubuntu-classroom-chat [15:55] awsominator, join #ubuntu-classroom-chat [15:56] I would like to know, do I need something specific to Ubuntu/Linux for this session ? Or can I just follow from Windows ? [15:56] you can follow [15:58] if you use irssi, you might want to: /ignore -channels #ubuntu-classroom * JOINS PARTS QUITS NICKS [16:00] doesn't work in pidgin steinex [16:00] steinex: I was jsut owndering how to do that, the command didn't work though [16:00] it just works in the irc-client irssi [16:00] Ah yeah got it [16:00] i don't know for other clients, sorry [16:00] thanks [16:00] HELLO MY FRIENDS!!! [16:00] hello dholbach [16:00] hi [16:00] howdy [16:00] It's Ubuntu Developer Week and it's starting RIGHT NOW! [16:00] hi [16:00] Start [16:01] dholbach, :) start [16:01] hello! [16:01] ok, so first things first [16:01] hello! [16:01] can all kinds of chat and questions please please please (with sugar on top) go to #ubuntu-classroom-chat please? [16:01] if you haven't joined that channel yet, can you please do that now? [16:01] hello ! [16:02] to review the schedule and get more information about the sessions, check out https://wiki.ubuntu.com/UbuntuDeveloperWeek [16:02] that's the only page you need to bookmark for now :) [16:03] excellent, let's get started [16:03] if you have any kinds of questions, please ask in #ubuntu-classroom-chat === hakimsheriff_ is now known as hakimsheriff [16:03] and please make sure you prefix it with QUESTION: [16:03] ie: "QUESTION: What is your dog's name?" [16:03] etc [16:03] it makes it easier to figure out what exactly the question is :) [16:04] first of all I'd like to thank all speakers - we have a pretty divserse schedule and it's going to be an awesome week [16:04] Logs for this session will be available at http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html following the conclusion of the session. [16:04] my name is Daniel Holbach, I live in Berlin and have been part of the Ubuntu Community for ~6 years [16:04] my primary interest is and always was the developer community [16:05] so it's my honour today to talk about "getting started with Ubuntu Development" and you'll be stuck with me for the next 2 hours :) [16:05] in the first hour I'd like to give you a very broad overview of Ubuntu development, Ubuntu's infrastructure, give you an idea of our processes, how we interact with other projects, etc. [16:06] I won't answer all the questions you have, but I hope I can give you an idea how all the bits and pieces fit together [16:06] in the second hour I'll help you get your development environment set up [16:06] so for the rest of the week you should be all set up and ready to go [16:06] do we have any first questions already? [16:06] (if not, I'd say we get cracking now :-D) [16:07] <20QAAV4RZ> QUESTION: I'm a total newbie with lernid - do I need to hear something or is all done via chats? [16:07] 20QAAV4RZ, yes, it will be done all via chat - some of the sessions will be more tutorial style, so you might have to do a few things in the terminal [16:08] ok, let's get cracking :) [16:08] as you all know Ubuntu is made of thousands of packages [16:08] libraries, tools, apps, games, etc [16:08] they're written in many different languages, and they're all available as source packages [16:09] a source package typically consists of the actual source code and some meta-data [16:09] every single change that gets made (be it just a small fix or a new version, etc.) requires an upload to the build machines (part of Launchpad), where the source package gets transformed into binary packages (.deb packages) === 20QAAV4RZ is now known as hugohirsch [16:10] QUESTION: i am using pidgin..not lernid..is it okay?? [16:10] susenj, yes, totally [16:10] QUESTION: will multiple shells be covered? [16:10] gartral, it shouldn't really matter which shell you're using [16:10] how to see video? [16:11] ok, once the .deb files (binary packages) are available, they are pushed to various mirrors [16:11] and they're also used to build CDs of all kinds of Ubuntu flavours (Ubuntu server, Kubuntu, Ubuntu Desktop, etc.) [16:12] so no matter if you use Kubuntu or Ubuntu or Xubuntu or anything else... all the changes are uploaded to the same build machines and are part of the same archive [16:12] QUESTION: Do I need to be on Ubuntu for this session ? [16:12] Kroosec, no, not necessarily - later on for the tutorials probably [16:12] QUESTION: was session started ? [16:12] raju, yes - if you missed the start there will be logs on https://wiki.ubuntu.com/UbuntuDeveloperWeek later on [16:13] the CDs are mostly built every single day, so that's what we use for installation tests, etc. [16:13] QUESTION: WIll there be a formal QnA later on? I want to ask questions but not interrrupt you [16:13] manish raju: you dont put that [16:14] middle: please just ask - I'll decide myself when I take a small break to answer a couple of questions :) [16:14] ok, so much for the Ubuntu archive, packages and how they're built [16:14] let me talk a bit about the Ubuntu release cycle [16:15] what Ubuntu developers focus on heavily depends on the release schedule [16:16] as you know Ubuntu is released every 6 months, and to able to deliver on the exact date, we need to stick to the dates in the schedule [16:16] if you want to see the schedule for the current development release, check out https://wiki.ubuntu.com/NattyReleaseSchedule [16:17] if you don't have problems with seeing colours, you see that there's green at the start and red at the end [16:17] "green" does NOT mean: "it's all working, it's all great" [16:17] it rather means "everything goes, you can upload whatever changes you want/need" :) [16:18] towards the end of the release cycle we introduce more and more freeze dates, where the changes are becoming less and less intrusive [16:18] but let's go back to the beginning [16:18] first the toolchain (the most basic build-relevant packages) are set up, then we work on merging changes that have happened in Debian (and other software projects) since we got out the last release [16:19] then there's Ubuntu Developer Summit (UDS), which I'll talk about a bit later - for now it should be enough to say that it's where the features of the release are defined and agreed on === tarun is now known as Guest97414 === Guest97414 is now known as c2tarun [16:20] Debian Import Freeze is the first freeze date that appears in the list - it's where we stop to automatically "sync" source packages from Debian [16:20] this is done as a measure to start to stabilise the code in Ubuntu, but can be overriden in warranted cases [16:21] next up is Feature Freeze, where we expect big parts of features to be landed [16:21] if they still have bugs, that's fine, but if they're not there in rudimentary form, then that's a problem and we might consider to postpone them to the next release [16:22] Feature Freeze is also the date where try to slow down introducing new versions of packages (again: in order to stabilise, and yes there might be warranted cases where we want to override) [16:22] from Feature Freeze on, we introduce more and more other freezes, UI, Docs, Kernel, etc etc [16:23] this is done, so that we focus on show stopper bugs and don't introduce any big changes any more and bring Ubuntu in a releasable form :) [16:23] April 28th is the date we're aiming for this release and I'm quite sure that that's where we'll get the release out :) [16:24] Question: How long someone can be a MOTU? 6 month from first upload or depends on how much uploaded or depends from recommendations? [16:24] udienz, to become an Ubuntu developer I'd prefer not to give and concrete number of weeks/months === MickStep is now known as QUESTION === RobertM is now known as Guest98250 [16:24] I personally feel that if you gained the trust of other developers you've worked with (more on the topic later on), you're ready [16:25] ok, so much for the release schedule for now :) [16:26] but I guess you got a better idea now why it makes more sense to upload a rewrite of a piece of software EARLY in the cycle, and not 5 days before release :) [16:26] etc :) [16:27] and you can also imagine now that with thousands of packages, millions of lines of code, hundreds of project and hundreds of developers communication/coordination is very important [16:27] QUESTION: How would developer's code get into the main ubuntu code? Which tools are used for development and commits, how these commits are tested by others for authentication? [16:27] monish001, I'll get to that in a bit [16:28] QUESTION (later): I find a bug in a gnome package, checked out the sources, discovered that the bugfix merely is a 'remove commented out line in sources' - how do I get this into Ubuntu? [16:28] hugohirsch: I'll get to that in a few minutes as well :) [16:28] I touched on UDS (Ubuntu Developer Summit) a bit earlier on already [16:29] it's where hundreds of people get together in one location and for one week discuss all kinds of problems they want to solve in the next cycle [16:29] the great thing is, if you can't be there physically, you can attend remote (talk on IRC and listen in via audiocast) [16:30] the outcomes of the sessions are written up as specifications, so all the ideas, assumptions, rationale and action plan is recorded publicly and others can involved helping to solve those problems [16:31] while this works well for "big picture" things, there are loads of day-to-day decisions that are made on mailing lists (ubuntu-devel@lists.u.c for example) or on IRC channels, such as #ubuntu-devel [16:31] of course if there's a specific software project that interests you that is outside of Ubuntu, you might want to be on the project's mailing list and IRC channel as well [16:32] another important medium for discussion and coordination is bug reports [16:32] you can find all of Ubuntu's bugs at https://bugs.launchpad.net/ubuntu === pixelmeister_ is now known as rechengehirn [16:33] it makes it much easier to stay on top of what needs to be fixed if you're subscribed to a specific package's bugs, talk to its authors, etc [16:34] we also make deliberate use of bug statuses, tags and assignee fields to track what's in progress and who's working on it [16:34] QUESTION: What's the 'process' model of Canonical/Ubuntu? Scrum? XP? How are you guys managed/tracked? [16:35] hugohirsch, first you need to distinguish between Canonical and Ubuntu - Canonical's engineers are part of the Ubuntu community as is everyone else [16:35] there are a lot of software projects that originate in the Ubuntu world and they make use of whatever release management they like best [16:36] there is the Kanban approach in Launchpad for example, there is others that "release when it's ready" [16:36] there's others who have regular meetings, etc. - there's a huge variety [16:36] I mentioned it before already... we rely on a lot of other software projects [16:37] not all the code that is shipped in Ubuntu is written by Ubuntu developers [16:37] projects that release code which we integrate into Ubuntu are called "upstream projects" or short "upstreams" [16:37] it's critically important to us to have a great relationship to all of these [16:38] we need to talk about timeframe of releases, pass on information about bug reports, pass on code changes, etc [16:38] one of the most important Upstream projects for us is Debian (luckily, there'll be dedicated session about Debian later in the week) [16:38] Debian is a distribution itself and we inherit a lot of changes immediately from Debian [16:39] also were most of the technical decisions made in (or in conjuction with) Debian too [16:40] so there's package maintainers or package maintenance teams in Debian, with whom it's very interesting to have a conversation if you plan changes or want to coordinate work [16:40] (as I said earlier: there'll be a session about that later in the week - YES!) [16:40] QUESTION: on Which Irc channel can I get help on develoment related question/problems? [16:40] wolfpack, #ubuntu-motu on irc.freenode.net should be a good start [16:41] ok... some of you wanted to know earlier already... how do I get my changes into Ubuntu [16:41] so let's talk about that now [16:41] it's not daunting at all and it's very rewarding - not only because you learn something new every single time (at least I did), but also because you fix problems for millions of users out there [16:42] because new contributors can't immediately upload to the build machines themselves (we use GPG to track who uploaded changes, etc.), they need somebody who reviews their changes first and uploads for them [16:43] and that's a great way to learn, as you interact with loads of different people and they all might teach you something new [16:43] and also you make loads of great friends [16:44] barry will later on talk about Ubuntu Distributed Development, so explaining the exact process of how to branch a source package, how to submit changes, etc. [16:44] so I won't steal his thunder by going into technical details :) [16:45] basically: you get the source, you make your changes, you test build the code, test it, push it for review, get it reviewed and uploaded - BUG FIXED :) [16:45] QUESTION: Do I need to choose a reviewer or is a reviewer assigned via Launchpad automatically? [16:45] hugohirsch, you don't have to choose === dholbach_ is now known as dholbach === rahadian is now known as razorBAT [16:47] sorry [16:47] fell out of the internet for a second :) [16:48] hugohirsch, naturally if somebody has their special area of expertise with some package, you might talk to them over and over again :) [16:48] QUESTION: What languages are used for Ubuntu Development? [16:48] mauriciocinelli, all kinds: C, C++, Python, Perl, Java, Mono, Vala, etc etc etc. [16:48] the good thing is: you don't need to know "all of them" to get started [16:49] you can easily lay back, take it easy, fix a few simple and obvious bugs first and take it from there [16:49] and as I said a couple of times already: you learn more and more over time [16:49] QUESTION: how to customize the bootloader? [16:50] abcd87, I'm afraid I don't know - if you elaborate on your question, you might find somebody who's cleverer than me in #ubuntu-devel :) [16:50] I really like mauriciocinelli's question, so I'll talk about that a little bit more [16:51] if you ask me it's not so much about knowing n+1 programming languages already [16:51] it's about having a knack for making things work again [16:51] it's about doing some detective work [16:51] it's about being a team player [16:51] it's about not being afraid of reading documentation [16:51] it's about not being afraid of asking a few (seemingly) stupid questions [16:52] if you answered "Yes" more often than "no" to the points above, you should fit right in [16:53] detective work also involves talking to upstreams and people from other distributions, coordinating with them - sometimes a fix for a specific issue might be available already and you just need to get it into Ubuntu as well [16:53] QUESTION: Are you considering using Go (Google's language) at one point since it's designed for OS/service development [16:53] MeanEYE, I don't know how many packages already make use of it === bobthebob is now known as bobthebob1234 [16:54] but I'm sure it will get considered if there's demand for it [16:54] Ok... with that I suggest we take a 5 minute break before I help you get started and get your development environment set up [16:54] so get yourself a coffee or tea or glass of water and I'll see you in 5 minutes === abc_ is now known as Guest32570 [17:00] ok... we're back for part 2 of "getting started with ubuntu development" [17:01] for those of you who came late... don't worry - we'll put up logs of all sessions up at https://wiki.ubuntu.com/UbuntuDeveloperWeek later [17:01] also, if you want to chat, ask questions and all the rest of it, please head to #ubuntu-classroom-chat [17:01] and prefix questions with QUESTION [17:01] QUESTION: What about for people that don't know any programming language? How can they help with development process? Translations, reporting bugs, testing the code, discussing in the brainstorm. Is there more? Any web page? [17:02] jack002, you can do all of what you mentioned, but you can also try to fix small and obvious bugs - don't hesitate :) [17:02] QUESTION: What do yo uthink hte best route froa student currently studying A-levels woulkd be to get intot eh wolrd of open source software development? [17:03] middle: yes, I think it's a great choice to get involved in Ubuntu development - you'll learn loads because you basically touch all parts of an operating system - it's a fun experience and will help you figure out what you really enjoy doing [17:03] QUESTION: James Gosling resigns from sun/oracle and now oracle wont provide support for J2SE n J2M. will this affect ubuntu packaging in java? [17:03] *J2ME [17:04] darkdevil56, I'm not a Java hacker, so I don't know - I personally haven't heard of any big concerns in the open source community yet though [17:04] QUESTION: will ubuntu/canonical be taking part in the Google Summer of Code this year? [17:04] qayshp, Ubuntu will definitely apply as a mentoring organisation - the decision will be with Google though :) [17:05] alrightie [17:05] that's all the outstanding questions from part 1 as far as I could see [17:05] in part 2 I'll help you get your ubuntu development environment set up === QUESTION is now known as MickStep [17:06] you will need reasonably fast internet for this, so if things take longer for you, don't despair - take it easy and just open a second terminal and continue with other steps in the meantime [17:07] also there might be some steps involved that you already did on your own some time ago - feel free to skip those [17:07] (ie: you set up a GPG key already - you don't need two :-)) [17:07] alrightie [17:07] let's get cracking :-D [17:07] in a terminal, please run this command [17:07] sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb [17:08] while it runs and installs a few packages, I'll talk a bit more about what we're doing here [17:08] once we're done with this session, [17:08] - you have all the tools to do Ubuntu development installed on your machine [17:08] - your local developer tools know about you, which simplifies work a lot [17:08] - you can do local builds of packages [17:09] - you can interact with other developers and propose your changes on Launchpad to get merged [17:09] - you can upload packages to Launchpad, so they are hosted in your Personal Package Archive (PPA) [17:09] another word of advise: if you do Ubuntu development, it's incredibly helpful to run the current development release [17:10] we all know that from time to time the current development release is quite broken, so it's obvious that you might not want to run it as your one and only Ubuntu system [17:10] https://wiki.ubuntu.com/UsingDevelopmentReleases explains how you can easily and safely use the development release [17:10] (you don't need to do that now) [17:11] QUESTION: If I have a private GPG-key and one for ubuntu development. What do you recommend? Work as a separate user with the ubuntu-GPG-key or is there an easy way to switch between keys when working on ubuntu-stuff on the console ? [17:11] hugohirsch, you can easily specify whichever one you want to use [17:11] QUESTION: did you mean to say PGP, instead of GPG? [17:11] fisch246, I meant to say GPG (GNU Privacy Guard), which implements the OpenPGP standard [17:12] QUESTION: During install it asks general type of mail configuration? [17:12] mauriciocinelli, sorry about that - you can also run the install command with "--no-install-recommends" if you want to avoid the mail configuration [17:12] QUESTION: how is the gpgkey introduced in the mended package [17:12] stefwal82, I don't understand the question [17:13] QUESTION: what's postfix config? [17:13] darkdevil56, you can also run the install command with "--no-install-recommends" if you want to avoid the mail configuration [17:13] ok.. let's see what kind of packages we're installing right now....... [17:13] there's: [17:13] - gnupg which you will need to create a GPG key with which you will sign files you want to upload to Launchpad [17:14] - pbuilder which is a great tool to do a reproducible build of a package in a clean and isolated environment [17:14] - ubuntu-dev-tools (and devscripts, a direct dependency) which provide you with a collection of tools that make a lot of packaging tasks a lot easier [17:14] - and there's bzr-builddeb (and bzr, a dependency) which will get you set up for working in the distributed development environment, that makes it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each others work [17:16] A few people seem to have problems downloading packages - if you hit any problems, please head to #ubuntu-classroom-chat - there's people who are going to help you out. [17:16] ok... let's talk about gpg (GnuPG) first [17:16] it is important that you can sign files with your key, so they can be identified as something that you worked on [17:17] if you upload a source package to Launchpad, it will only accept the package if it can tell who uploaded the package [17:17] If you don't have a GPG key yet, please run this command in a terminal: [17:17] gpg --key-gen [17:17] GnuPG will first ask you which kind of key you want to generate. Choosing the default (RSA and DSA) is fine. [17:17] Next it will ask you about the keysize. The default (currently 2048) is fine, but 4096 is more secure. [17:18] Afterwards 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. [17:18] 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. [17:18] QUESTION: gpg --key-gen [17:18] middle: sorry, my mistake [17:18] it's: [17:19] gpg --gen-key [17:20] once you're done with the questions it asked, there'll be also one about a "comment" [17:20] Adding a comment is not necessary. [17:20] Then you will have to set a passphrase. Choose a safe one. [17:20] Now GnuPG will create a key for you, which can take a little bit of time, as it needs random bytes, so if you give the system some work to do it will be just fine. [17:21] just keep it sitting there and do its work - if it takes very long, open another terminal :) [17:22] the next step will be to generate a SSH key [17:22] SSH is a network protocol that allows you to exchange data in a secure way over the network. In a lot of cases you will use it to access and open a shell on another machine. It is also very useful to transfer files in a secure way. [17:22] if you don't have an SSH key yet, just run [17:22] ssh-keygen -t rsa [17:22] The default filename makes sense, you can just leave it as it is. Also you can choose to use a passphrase or not. [17:23] We will use the SSH key to securely push code changes to Launchpad. === msnsachin12 is now known as msnsachin [17:23] next we'll set up pbuilder [17:23] pbuilder allows you to build packages locally on your machine. It serves a couple of purposes: [17:24] - the build will be done in a minimal and clean environment, where you can see if it succeeds in a reproducible way (with no modifications of the local system [17:24] - there is no need to install all necessary build-dependencies locally [17:24] - you can set up multiple instances for various Ubuntu and Debian releases [17:24] QUESTION: why should communications be secured with RSA instead of AES? [17:25] gartral|watcher, I'm afraid I don't know the answer to that question - it's what we use... you might get a more elaborate answer on #ubuntu-devel though :) [17:25] QUESTION: Does pushing code neccesary nedds ssh connection? As I am working university network proxy and can make connection through http only. [17:25] wolfpack, that might be a problem then - the nice people in #launchpad might give you an alternative option [17:26] QUESTION: I already have ssh keys set up (I created them for use with github). Do I need to regenerate ? [17:26] abhinav51, no, not necessary [17:26] Setting pbuilder up is very easy. Edit ~/.pbuilderrc and add the following line to it: [17:26] COMPONENTS="main universe multiverse restricted" [17:26] and save the file [17:27] This will ensure that build-dependencies are satisfied using all components. [17:27] then run: [17:27] pbuilder-dist natty create [17:27] This will take a while as it will download all the necessary packages for a “minimal installation”. These will be cached though. [17:28] the great thing about pbuilder-dist is, that you can also set up build environments for other Ubuntu (or Debian) releases [17:28] (just replace "natty" with whatever else you need) [17:28] QUESTION: more of an extension of the previous question, but, will launchpad accept keys larger than 2048 bits? [17:28] gartral|watcher, I could very well imagine that yes they do, but you might want to ask that question in #launchpad too :) [17:28] (sorry :)) [17:29] QUESTION: you specify natty on the pbuilder-dist cmd line, does it matter that I'm running on a lucid box? [17:29] cire831, no, it should still work :) [17:29] QUESTION: I htink some of your commands are off, there was nothing in the file that we added the line to ans nuilder-dist wasn#'t found =s [17:29] middle: if ~/.pbuilderrc was empty, that's totally fine [17:29] QUESTION: will pbuilder-dist be upstreamed to Debian? I was surprised to learn that it's in ubuntu-dev-tools rather than devscripts [17:30] maco, it'd be great to see it in Debian too - if you want to propose it for devscripts, please go ahead and do it :) [17:30] maco, you of all people should know how to get that done :-D [17:30] QUESTION: Is there a way to make pbuilder use more than one core on a multicore machine? [17:31] hugohirsch, I would think so - can somebody confirm in #ubuntu-devel? :) [17:31] QUESTION: There is no ..pbuilderrc in my home directory [17:31] mainerror, that's fine - just create it [17:31] QUESTION: Must pbuilder-dist be run as root? Or does it use a fakeroot behind the scenes? [17:31] gmargo3, the reason why pbuilder-dist (via pbuilder) uses root is that it uses chroot internally [17:32] QUESTION: where is it putting the natty files? [17:32] cire831, ~/pbuilder === IAmNotThatGuy is now known as M0hi [17:32] QUESTION: In ~/.pbuilderrc , which directory does ~ means? [17:32] monish001, your home folder [17:33] alright, let's crack on :) [17:33] next we'll teach Bazaar about yourself [17:33] 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. [17:33] Simply run: [17:33] bzr whoami "Frank Chu " [17:33] bzr launchpad-login fchu [17:33] (please, if your name is not "Frank Chu", replace with your own name, thanks) === wolfpack is now known as Guest40940 [17:34] if you don't have a launchpad account yet, you can get it if you sign up at https://launchpad.net/+login [17:35] (and do that step later on) [17:35] if you have launchpad account, your launchpad id is whatever is after "~" in the URL that https://launchpad.net/people/+me redirects you to [17:35] QUESTION: What do we do with our SSh key, can we jsut close the terminal as it is saved somewhere or do we need to write it down? [17:35] middle: yes, just close it - that's fine [17:36] ok, next we'll teach the development tools about ourselves === Guest40940 is now known as wolfpack [17:36] Edit ~/.bashrc (if you use a different shell use whatever configuration file it comes with) [17:36] and add something like this to the bottom: [17:37] export DEBFULNAME="Frank Chu" [17:37] export DEBEMAIL="fchu@example.com" [17:37] (again, please replace with whatever YOUR name and YOUR email is :)) [17:37] afterwards save the file and run [17:37] source ~/.bashrc [17:38] sorry, please make this DEBFULLNAME [17:38] (thanks sapphirepaw) [17:39] if you have a look back at the terminal where your gpg key was created, you might see a message like this: [17:39] pub 4096R/43CDE61D 2010-12-06 [17:39] Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D [17:39] uid Daniel Holbach [17:39] sub 4096R/51FBE68C 2010-12-06 [17:39] in this case "43CDE61D" is my GPG ID [17:40] if you had a GPG key before, run this: [17:40] gpg --fingerprint [17:40] it should give you a similar output [17:40] once you know your gpg key id, you can run: [17:40] gpg --send-keys [17:40] which will upload your key to the keyservers, which allows others to confirm that something you signed is actually from you [17:41] (if you uploaded it already, you can obviously skip that step) [17:42] it would take too much time to go through all the individual steps (it's not that bad actually) to register you gpg and ssh key with LP, so for now I'll just give you the links you need: [17:42] - https://launchpad.net/people/+me/+editpgpkeys (GPG key registration) [17:42] - https://help.launchpad.net/YourAccount/ImportingYourPGPKey (docs for gpg key registration) [17:42] - https://launchpad.net/people/+me/+editsshkeys (ssh key registration) [17:42] - https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair (docs for ssh key registration) [17:42] and that's really it :-) [17:43] QUESTION: "bzr: ERROR: The user paul-mcspadden has not registered any SSH keys with Launchpad." and how do i go about doing this? [17:43] fisch246, you can fix this at https://launchpad.net/people/+me/+editsshkeys [17:43] QUESTION: How can i delete an outdated key from the keyserver? [17:43] HoellP, as far as I know you can revoke a gpg key locally and then upload the revoked key to keyservers [17:44] QUESTION: how do you sign something? [17:44] stefwal82, the development tools will do that "automatically" for you, but you can set up your mail client to sign mails, or sign files manually [17:44] QUESTION: Sending the gpg-key fails with 'keyserver not configured' error. Can I upload my GPG-key to launchpad or does it need to be available via an open key server? [17:46] hugohirsch, you can specify --keyserver keyserver.ubuntu.com (for example) [17:46] QUESTION: which key am i supposed to send? pblic or secret? [17:46] darkdevil56, never share the secret key (--send-keys will figure that out for you) [17:47] QUESTION: Output of 'bzr whoami "Name " '? I am getting blank.. [17:47] monish001, that's fine - the command succeeded [17:49] any more questions? [17:49] if you missed anything, or things are still being worked on, just follow the log of the session later on again - it's fine if you needed a little bit more time :) [17:49] QUESTION: Thx - uploaded my GPG-key. Will it automatically be connected/synced with my Launchpad account? [17:50] hugohirsch, no, you need to head to https://launchpad.net/people/+me/+editpgpkeys to tell Launchpad about it [17:50] QUESTION: the ssh command that i had typed earlier is retrieving and validating all the packagges till now.. is this normal? [17:50] darkdevil56, that must be the pbuilder-dist command - yes that's to be expected - just let it do its work :) [17:50] QUESTION: Is there anything else we need? [17:51] mauriciocinelli, that should be it for now - it should set you up for a good start - whatever else is required for others sessions will be dealt with there [17:51] are there maybe some more general questions about Ubuntu development? [17:51] we still have ~10 minutes before I have to hand the mic to barry :) [17:52] * barry clears his throat [17:52] QUESTION: not completely related, more about the process itself: are the packages synced from debian just the plain packages and ubuntu does the ubuntuspecific patches from-scratch for every new release? or are ubuntu-patches automatically applied on sync and if they don't merge, they must be merged by hand? [17:52] steinex, good question and it will be dealt with in the Debian session === kai__ is now known as rechengehirn [17:53] for now: if the source is unmodified from Debian and we're before Debian Import Freeze, they will be synced automatically and built in Launchpad [17:53] if there are ubuntu changes we need to "merge" and we have a tool that helps us with that (http://merges.ubuntu.com) [17:53] QUESTION: I read something about https://wiki.ubuntu.com/MOTU/Mentoring Could you explain more in detail how it works and who should use it? [17:53] acarpine, unfortunately the Mentoring programme is out of order at this moment [17:54] I suggest you check out https://wiki.ubuntu.com/MOTU/GettingStarted and please feel very welcome to ask all the questions you have in #ubuntu-packaging or #ubuntu-motu [17:54] even if it's not a dedicated mentor for you, there's loads of people who are very happy to help you get started and solve your problems [17:54] QUESTION: I uploaded my key, but LP doesn't find the key with the given fingerprint. Do I need to wait for synchronisation between LP and Ubuntu-Keyserver? [17:54] hugohirsch, yes, you might have to wait a little bit (I don't know the exact timeframe, sorry) [17:55] QUESTION: Does ssh key are need to be updated with every new distro release or new computer? [17:55] wolfpack, no, just leave them as they are [17:55] QUESTION: So, now that we have our environment set up, we look at https://bugs.launchpad.net/ubuntu and -- that's where I'm not sure. [17:55] jledbetter, the upcoming sessions and https://wiki.ubuntu.com/MOTU/GettingStarted should give you some ideas where to look for bugs to fix and how to go about it :) [17:56] more questions? we still have 5 minutes :) [17:56] QUESTION: when I uploaded the key it said it was uploading it to keys.gnupg.net. On launchpad under editpgpkeys it says something about Ubuntu keyservers. Will the Ubuntu keyserver get the new key directly from the gnupg keyserver? [17:56] cire831, yes, it will take a few minutes [17:56] QUESTION:Are ubuntu packages sent back to Debian? [17:56] saimanoj, nice one! [17:57] sending patches back to Debian (or other upstreams) is a manual process and very important [17:57] it is indeed being done [17:57] and there will be more info about that in the Debian session which I believe will be tomorrow [17:57] QUESTION: Fixing bugs, when choose bzr and when use a traditional process (create a patch with a debdiff)? [17:58] acarpine, bzr is a REALLY nice way to go about fixing stuff and barry will take the next hour to walk you through it [17:58] if it should not work out for you, I'm sure that barry will love to hear more about it and yes, in that case the "traditional process" of posting a patch will work too [17:58] QUESTION: in former courses you gave examples, why don't you now? [17:58] stefwal82, I type too slowly - not enough time :) [17:59] and I really enjoy answering loads of questions here - I hope it's useful [17:59] there'll be more examples in other sessions this week [17:59] QUESTION: When I run gpg-key fingerprint , I get three uid, what does it mean? [17:59] simar, do you have more than one gpg key? [17:59] ah no... is that maybe different user IDs on the same key? in any case it shouldn't be a problem [18:00] QUESTION: is the debian session being talked about the same as "Getting fixes into Debian"? [18:00] "Getting fixes into Debian" will definitely be part of it [18:00] QUESTION:What has this allowed me to actually do?! === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Introduction to Ubuntu Distributed Development (UDD) - Instructors: barry [18:01] - you have all the tools to do Ubuntu development installed on your machine [18:01] - your local developer tools know about you, which simplifies work a lot [18:01] - you can do local builds of packages [18:01] - you can interact with other developers and propose your changes on Launchpad to get merged [18:01] - you can upload packages to Launchpad, so they are hosted in your Personal Package Archive (PPA) [18:01] and I'm out of time [18:01] hi, my name is barry warsaw, and i live near washington dc. i work for canonical, do ubuntu development, am a core python developer and project leader for gnu mailman. i'm here to introduce you to a new way of developing ubuntu, called 'ubuntu distributed development', or 'udd' [18:01] next up is the ROCKing Barry Warsaw [18:01] thanks dholbach! [18:01] ... not only an Ubuntu, Launchpad and Python hacker, but also a fun guy, friend and exceptional bass player [18:02] aw shucks, thanks :) [18:02] enjoy the session, you'll love Ubuntu Distributed Development afterwards [18:02] in a nutshell, udd uses the bazaar revision control system to fix bugs and develop features in ubuntu packages. in this session, we'll learn how to fix a bug by: [18:02] * creating a local branch of the project [18:02] [18:02] * developing a fix, then committing it to your local branch [18:02] * link the branch to the bug report in launchpad [18:02] * request a 'merge proposal' for the package maintainer to review [18:03] we'll probably just be scratching the surface of how this works, but hopefully you will come out of this session feeling more confident about using bzr to work on you ubuntu packages. i won't cover much about packaging in particular, or bzr, but i will try to answer any questions you have! [18:03] just a note: we'll be using a bug in computer-janitor as an example. c-j is a little different than most packages in ubuntu because it's developed natively in launchpad. for the purposes of this class, this difference won't matter too much. if it comes up, i'll point it out. [18:04] why use bzr when the old tools work just fine? bzr gives you the benefit of a full distributed version control system to manage package changes. [18:04] * incremental changes can be committed locally as you go [18:04] * logging, diffing, intelligent merging [18:04] * interact better w/other ubuntu devs by sharing works-in-progress [18:04] * work disconnected [18:04] * manage all artifacts in launchpad [18:04] * request reviews online [18:05] * automatic requests for sponsorship review [18:05] * soon: build-from-branch-to-archive [18:05] for now, the documentation is a little bit scattered, but the best place to start is on the wiki. we are acdtively working on cleaning this up and moving it to the official ubuntu developers documentation. [18:05] https://wiki.ubuntu.com/DistributedDevelopment/Documentation [18:06] so, i'm going to give folks a few minutes to catch up on all the prepared overview above, then i'll start digging in... [18:08] anybody need a few more minutes to catch up? [18:08] or are there any questions about the introductory material, or what i hope to cover today? [18:09] so, we need to start by making sure you have the basic tools. you'll need bazaar and a special plugin that adds a lot of useful stuff [18:10] start by doing this: [18:10] sudo aptitude install bzr bzr-builddeb [18:10] you're also going to need to know your launchpad id. dholbach covered this in the previous session. it's the bit after the ~ in your launchpad url [18:11] if you don't have a launchpad login yet, either go get one now or there will be a few steps later that don't work for you. no worries, you can still follow along [18:11] dholbach: points out that you can visit this url: [18:11] https://launchpad.net/people/+me [18:12] and after it redirects, you can look for the ~ in the url. the bit after that is your launchpad id [18:13] monish001 asked: bzr launchpad-login monish001 bzr: ERROR: The user name monish001 is not registered on Launchpad. [18:13] monish001: be sure you've registered on launchpad first. 'bzr launchpad-login' will not create a login for you [18:14] also, some folks may not have aptitude, you can install the bzr tools with this instead: [18:14] sudo apt-get install bzr bzr-builddeb [18:15] okay, now, i'd like you to run this command: [18:15] bzr --version === evilshadeslayer is now known as shadeslayer [18:15] and note the version of bzr that you are using [18:16] we are going to use two different urls later to refer to package source in launchpad. if you are using bzr version 2.3 or higher, you will be able to do things like this: [18:16] bzr branch ubuntu:mypackage [18:16] to get the version of 'mypackage' in natty [18:17] if you have bzr 2.2 or older, this will be spelled like this: [18:17] bzr branch lp:ubuntu/mypackage [18:17] if you sat in on dholbach's session, you've already done this: [18:17] bzr whoami "Your Name " [18:17] bzr launchpad-login mylpid [18:17] and now we're ready to use bzr to fix a bug in ubuntu! [18:18] hugohirsch asked: Is it a problem that I still run 10.10? My bzr is 2.2.1 [18:18] hugohirsch: it is not a problem. this will work just fine. just remember to use the lp:ubuntu/foo urls instead of ubuntu:foo [18:18] cire831 asked: how does it know to get the natty version? what if I'm running lucid and want that version? [18:19] cire831: the ubuntu:foo urls always pick the current in-development version of ubuntu, i.e. as we speak, that's natty [18:19] you can always use ubuntu:natty/foo or ubuntu:maverick/foo etc. to get a specific version of a package in a specific version of ubuntu [18:20] those could also be spelled as lp:ubuntu/natty/foo or lp:ubuntu/maverick/foo or lp:ubuntu/lucid/foo etc [18:20] palhmbs asked: Why does bzr-builddeb setup mail, do I really need it? [18:21] it sets up your email which will be used when you commit changes later on (i.e. it'll show up in your debian/changelog file) [18:21] chilicuil asked: can I use bzr and lp to pull debian versions? [18:21] yes. you can use urls like this: [18:21] debian-lp:squeeze/foo [18:21] or [18:22] lp:debian/squeeze/foo [18:22] okay, let's fix a bug! [18:22] go ahead and open this url in your browser: http://launchpad.net/bugs/726616 [18:22] someone noticed a typo in a file in the package. we'll fix that the udd way :) [18:23] go ahead and cd to a location where you want to do the work. we'll be creating a bunch of directories in there [18:23] cd someplace [18:23] now, just a little bazaar boilerplate to make things efficient: [18:23] bzr init-repo janitor [18:23] cd janitor [18:24] and now we're going to grab the source branch for the current version of computer-janitor in natty: [18:24] bzr branch ubuntu:computer-janitor natty [18:24] * barry will give you a moment to catch up [18:24] mhall119 asked: why is init-repo necessary? why not just bzr branch? [18:25] it's not strictly necessary, but as you'll see in the next step, using a bazaar 'shared repository' like this will make future steps go much faster by reducing the amount of network traffic you'll consume [18:25] (i.e. bzr can cache things locally if you use a shared repo) [18:26] cire831 asked: didn't work. bzr branch ubuntu:computer-janitor natty says not a branch. [18:26] does 'bzr branch lp:ubuntu/computer-janitor' work for you? [18:27] ah. this ubuntu: url might not work for computer-janitor. remember i said it was a little weird because c-j is developed in launchpad natively? if it does not work for you, use this url instead: [18:27] bzr branch lp:computer-janitor [18:27] in general you will use the ubuntu: urls, but in this case it's a little different. don't let that confuse you too much ;) [18:28] everybody good? [18:28] bzr branch lp:computer-janitor natty [18:28] ^^ [18:28] (that just gives you the branch in a directory called 'natty') [18:29] okay, so we're going to work on bug 726616. let's branch the current c-j trunk to a working directory which will only contain our fix [18:29] bzr branch natty bug-726616 [18:29] cire831 asked: what exactly does the natty on the end do? rather than say bzr lp:ubuntu/natty/computer-janitor [18:29] all it does is leave you with a local directory called 'natty' instead of the default 'computer-janitor'. there's no other difference [18:30] it's totally up to you [18:30] now... [18:30] cd bug-726616 [18:30] and we're sitting in a directory where we'll make our fix! [18:31] look around. you'll see the upstream source code, and a debian directory with all the packaging information. it looks like a pretty typical ubuntu source package, right? [18:31] cire831 asked: so I should be able to do bzr branch lp:ubuntu/lucid/computer-janitor lucid to get the lucid version? [18:31] yes [18:31] these urls are very handy when you want to backport fixes for sru's and such [18:33] okay, sorry, just triaging some questions [18:34] so, now, if you open the NEWS file in your favorite editor, and search for the word 'publically' you see the typo [18:34] just use your favorite editor to spell check this to 'publicly' and congratulations! you've just fixed an ubuntu bug [18:35] but of course, now you'd like to share your fix with the world and get it into ubuntu, right? let's do that now [18:35] exit your editor and then at the command line do this: [18:35] bzr diff [18:36] you should see that the NEWS file has the fix. what you'll see is a unified diff between your local change and the original source code [18:36] next thing you want to do is commit this change, but before you do that, you also want to add a debian/changelog entry which records what you've done [18:36] type this: dch -i [18:37] this will open an editor providing you with a template to fill in your change [18:37] you'll add a little bit of descriptive text, such as what i did here: [18:37] computer-janitor (2.1.0-0ubuntu4~udd0) UNRELEASED; urgency=low [18:37] [18:37] * NEWS: fixed a typo. (LP: #726616) [18:37] [18:37] -- Barry Warsaw Mon, 28 Feb 2011 11:18:20 -0500 [18:37] [18:37] note a couple of things: [18:38] the version number will be filled in, but when you see it, it won't have the ~ppa0 suffix. that's a trick we use to specify a version "in the middle" of the previous release and what will be the next release [18:38] using a ~ suffix makes it easier for testing later, but it's not strictly necessary [18:39] also notice the UNRELEASED tag. we'll eventually change that to 'natty' but again, this is a middle step so we can do some testing [18:39] finally, the most important part [18:39] notice this text at the end of the description line: [18:39] (LP: #726616) [18:39] that is really critical to include. it will be used to link your branch with the fix to the bug report [18:39] it must be exactly like that (the parentheses are optional) [18:40] but it must be of the form: [18:40] LP: #123456 [18:40] with a space between the colon and hash, and the hash must be there [18:40] anyway, save the changelog and exit your editor. i'll take some questions now [18:40] fisch246 asked: "bzr branch natty bug-726616" what command do i use if i'm on maverick? === Nik is now known as Nekhelesh [18:41] note that 'natty' in the above example is the local directory of the source branch that you checked out previously. you'd still use that, since you're working on the natty version of the package, even though you're on maverick [18:41] darkdevil56 asked: bash: cd: bug-726616: No such file or directory? [18:42] did you do the 'bzr branch natty bug-726616' command from earlier? [18:43] figure002 asked: where does dch get your email address from? [18:44] in the previous session, dholbach described how to set the DEBEMAIL and DEBFULLNAME environment variables. dch gets those values from there by default, but do a 'man dch' for details [18:44] okay. now, we've fixed the bug, and we've added a changelog entry. we just need to commit our changes to the local branch [18:45] run this: debcommit [18:45] this will call 'bzr commit' with some useful defaults, so it's mostly a convenience. you could use 'bzr commit' but for now, 'debcommit' is better [18:45] you can ask bzr to show you the history of the change you just made: [18:46] bzr log -c -1 [18:46] up to now though, your fix is just sitting in a branch on your local machine. we want to push the change to launchpad so we can share it with others. to do this, run this command: [18:46] bzr push lp:~myid/computer-janitor/bug-726616 [18:47] where of course you use your launchpad id instead of 'myid' [18:47] that'll take just a few seconds to run, and then when the command comes back, type this: [18:47] bzr lp-open [18:47] this should open your web browser to the launchpad page that represents your just pushed branch [18:48] palhmbs asked: if you fix a bug that hasn't been reported, what then, create a bug on launchpad? [18:48] it's generally good practice for there to always be a bug report first. it's not strictly required for any of the udd tasks, but it makes everyone's life easier to track the issue if there is a bug report [18:49] so i do suggest creating the bug report first. do that directly in launchpad not through bzr though [18:49] jderose asked: when i fix a bug, i like to do a PPA test build (also so others can easily test fix) - in this case, is it okay to commit, say, "natty" in the changelog rather than "UNRELEASED"? Wont the PPA builders choke on UNRELEASED? [18:49] i'm running out of time, but i do plan on covering this later. or if time runs out i will answer this in -chat [18:50] cire831 asked: where can I find out how all these tools are integrated. ie. how the bzr stuff knows about LP: # etc. [18:50] more info can be found in #ubuntu-devel or #udd or #bzr [18:50] okay, so we've pushed our fix branch to launchpad, now what? [18:51] if you look at the page that 'bzr lp-open' opened in your browser, scroll down to the 'related bugs' section [18:51] you should see a link to bug 726616 [18:51] There are 10 minutes remaining in the current session. [18:51] this was done automatically by debcommit, and launchpad when you pushed your branch. it was made possible by the 'LP: #726616' text you added in debian/changelog [18:52] if you click on the related bug link, you'll hop over the bug. notice that the bug page also has a link for 'related branches'. that should let you get back to the branch page [18:52] though, there may be multiple such branches from all the other folks in this class :) [18:52] be sure to pick yours! or use the back button [18:52] now, make sure you're on your branch page. scroll down and look for a link that says 'propose for merging' [18:53] click on that [18:53] what that does is inform the owner of the master branch, and all the ubuntu sponsors, that you have a fix for an ubuntu bug [18:53] so you don't have to request a sponsor, or a review, explicitly. (again, here's where computer-janitor is a little odd, but the above is true for 99% of branches) [18:53] er, packages [18:55] maco points out that sponsors aren't specifically notified, but your branch does show up in the sponsorship queue automatically. you can still ping a sonsor directly as normal [18:55] There are 5 minutes remaining in the current session. [18:55] cire831 asked: mine didn't link automatically. I can do it by hand though. [18:56] it can take several minutes for launchpad to process your branch and create the link. you can of course do it manually if you get impatient :) [18:56] cire831 asked: should we actually go ahead and do it? [18:56] go for it! don't worry, i'll be processing that bug when the class is over :) [18:56] darkdevil56 asked: aborting commit write group: PointlessCommit(No changes to commit) bzr: ERROR: No changes to commit. Use --unchanged to commit anyhow.? [18:57] bzr will spit this out if you've already committed all your changes. just use --unchanged, or make another change. [18:57] it can happen if you used 'bzr commit' before you did debcommit [18:58] please note that i skipped a lot of stuff about doing test builds, creating source packages, uploading to a ppa etc. we've basically run out of time, but i'll head over to #ubuntu-classroom-chat to continue for a while [18:58] remember that all the gory details are on the wiki: [18:58] https://wiki.ubuntu.com/DistributedDevelopment/Documentation [18:59] i'll take a few more questions before the next session starts, and thank you all for listening! [18:59] stefwal82 asked: is the worked on problem now uploaded? [18:59] no. a sponsor would have to merge your branch, build the source package, and upload that [19:00] in the future though, there will be some very cool stuff to do even that automatically in launchpad [19:00] if you have upload rights of course :) [19:00] hugohirsch asked: If i fix a bug do I need to create a PPA or is a branch sufficient enough? === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Taking bite out of Unity - Instructors: DBO, jcastro [19:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html following the conclusion of the session. [19:01] a branch is sufficient for a sponsor to review and apply your change. a ppa is not necessary at all! but it's useful for testing your package, or sharing your changes with others before it gets uploaded [19:02] woo, thanks barry, great job! [19:02] oh wait, there you are [19:02] sweet [19:02] This next session is How to Contribute to Unity [19:02] with me and DBO [19:02] o/ [19:02] woot! [19:02] ok so I'm going to go through the intro [19:02] and show you guys how we roll in Unity land [19:03] and then DBO's gonna take your questions [19:03] so first things first [19:03] why are we doing this? [19:03] as it ends up, things in Open Source end up more awesome when more people contribute (duh) [19:03] so what we're concentrating on here for Natty is making it easy for people to fix unity [19:03] or to contribute features [19:04] whatever scratches your itch, so that you can put your "brick in the wall" [19:04] yes, like the pink floyd song [19:04] so, for this session you hopefully already know what unity is [19:04] and you're itching to get your hands on the code [19:04] http://unity.ubuntu.com/getinvolved/ [19:04] we're going to start here [19:05] if you're going to do unity I recommend you bookmark this page [19:05] it's the cheat sheet for how to get the code, and do branch proposals [19:05] so, are people comfortable with bzr? This session doesn't cover bzr basics but I can do a quick tutorial (just comment in -chat) [19:06] oh, someone's asked a good question [19:06] akshatj asked: Does contributing to unity require knowledge of compiz? [19:06] DBO: ^ [19:06] akshatj, in short, no === chris_ is now known as bobthebob1234 [19:07] the longer answer is, not unless you want to work on those specific parts that interface between compiz and unity [19:07] about 90% of the code really doesn't touch compiz at all [19:08] ok so the first step is to grab the code [19:08] this is straight forward [19:08] bzr branch lp:unity [19:08] which is "hey bzr, make a branch of the unity project on launchpad, I want to do stuff" [19:08] you will then decide, what is it you want to fix [19:09] now some people know right away "I am going to go make this" [19:09] other people prefer "hey just tell me what needs to get fixed and I'm on it." [19:09] so the unity team takes bugs that they feel are "bitesize" [19:09] things to familiarize yourself with the code [19:09] and not flood you with a ton of stuff [19:10] so you can pick and choose some bufgs to familiarize yourself [19:10] don't worry, we don't put all the crap bugs in bitesize [19:10] we try to pick a mix of "sexy" bugs too [19:10] for example trevino fixed the little fade in the title bar, etc. [19:10] this list is here: [19:10] https://bugs.launchpad.net/unity/+bugs?field.searchtext=&orderby=-importance&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=bitesize&field.tags_combinator= [19:10] ALL&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search [19:10] ok so launchpad hates me [19:10] https://wiki.ubuntu.com/Unity/Bitesize [19:10] the list of bugs is on that page there [19:11] (we're on steps 2 and 3) [19:11] its worth noting that most bitesize bugs have been picked because they can be handled with little knowledge beyond C++ and glib [19:11] so, you basically find a bug from that list, something you want to fix [19:11] of course, you can feel free to ignore the bitesizers and dig into compiz and fix the universe, but for this tutorial we're going to keep it simple [19:11] ok so now you find a bug you want to fix [19:11] and you have the code [19:11] the next step is to fix the code itself [19:12] this is basically up to you, you need to fix the bug, DBO can you tell people how they can get coding help for fixing bugs? [19:12] the absolute best resource for getting coding help is us, the primary developers [19:12] where can I find you? [19:12] we all idle in #ayatana and are happy to field your questions about the code [19:13] you can also post on ayatana-dev@lists.launchpad.net [19:13] if you ping me there I will either answer your question or direct you to the proper person to ping :) [19:13] and yes as jorge mentioned, we watch the mailing list too [19:13] ok so for this example we're going to assume that you know how to code (heh) and have fixed the bug. [19:13] you would do normal hacker things here, test it, etc. [19:14] the next thing you need to do is commit the fix to your local repo [19:14] this is easy, "bzr commit" [19:14] now, you've fixed it and committed, now we need to put it somewhere where DBO can check it out [19:14] we're going to push a branch to launchpad [19:15] to do this I'll shove it under my username in launchpad [19:15] so, I'll say: [19:15] bzr push lp:jorge/unity/fix-for-123456 [19:15] or [19:15] bzr push lp:jorge/unity/awesome-new-feature-that-does-foo-bar [19:15] I can name it what I want at the end there [19:15] bzr push lp:~jorge/unity/fix-for-123456 [19:15] people generally just pick something descriptive [19:15] you missed the ~ [19:16] oops, sorry [19:16] thanks [19:16] * DBO got your back [19:16] (I see the doc has a typo, I'll fix that after the class) [19:16] ok, let's field some questions at this point [19:16] mhall119 asked: Are there any bugs yet that Python devs can fix? [19:17] mhall119, totally! we need people using libunity to add support for the launcher in other applications [19:17] since python has gir support, and libunity is a standard gobject library, you are able to use it directly [19:17] libunity and python should be sorted real soon, there's a few bugs but the right people are on the problem [19:17] "it's close" [19:18] doh, speaking ahead of myself :) [19:18] rsajdok asked: Can I develop on maverick or only natty? [19:18] natty only, sorry [19:18] I stayed on maverick as long as I could [19:18] and eventually too many deps needed to be backported for me to keep up [19:18] you would need to backport, glib, gio, gtk, and vala at least [19:19] the nice thing is now that the APIs and stuff are getting hashed out we won't need to break things going forward [19:19] what I recommend is waiting until thursday to grab alpha 3, this will have all the goodies (including fixed nvidia and ati drivers) [19:19] and then installing it on a USB key, boot off of it, and code [19:20] as natty stabilizes and it's not so "scary" to run a devel distro we expect more people to mess with the code [19:20] which is what we want! [19:20] rsajdok asked: Can You describe how to compile? cmake . etc.? [19:21] DBO: ^^ this one is all yours [19:21] rsajdok, yeah one second [19:21] heh, cmake! [19:21] rsajdok, grabbing the command :) [19:21] so what you do [19:21] bzr branch lp:unity [19:22] cd unity; mkdir build; cd build; [19:22] then you run this big command [19:22] cmake .. -DCMAKE_INSTALL_PREFIX=/home/USERNAME/staging/ -DCMAKE_BUILD_TYPE=Debug -DCOMPIZ_PLUGIN_INSTALL_TYPE=compiz -DGSETTINGS_LOCALINSTALL=ON [19:22] that will install the unity plugin into your /home/USERNAME/staging directory [19:23] erm [19:23] after you run make and make install that is [19:23] where's the wiki page at? [19:23] You wrote this down right? :) [19:24] on the installing unity wiki page... [19:24] https://wiki.ubuntu.com/Unity/InstallationGuide [19:24] https://wiki.ubuntu.com/Unity/InstallationGuideFromSource [19:24] those 2 pages should help you out [19:24] ah right [19:25] ok [19:25] so, now you have built it === bdrung_ is now known as bdrung [19:25] and fixed your bug [19:25] and tested it [19:25] Pro tip: You will need to test your fix [19:25] as your code will undergo review [19:25] ok, so we submitted the code to launchpad with our last bzr push [19:26] https://code.launchpad.net/unity [19:26] your branch will automagically show up on that page ^ [19:26] what you see here is all the branches for unity [19:26] as people work on the code they do it in branches [19:26] and then submit them [19:26] this is important, as we're very distributed [19:26] so you won't see things going into trunk until people submit a branch [19:27] Pro tip: this page is also a good way to see what's coming down the pipe [19:27] so, every day, when DBO wakes up [19:27] (at like noon) [19:27] he goes through these branches [19:27] DBO: can you tell us what you go through to review these branches? [19:27] so the review process is 2 primary stages [19:27] well 3 [19:28] in the 0th stage I decide what can be reviewed (certain features are outside of the scope of what we can support for natty) [19:29] if your feature/bugfix is able to land for natty, we move on to step 1, otherwise we inform you that your review will be looked at again for Natty +1 [19:29] the first step of code review involves looking over the code itself [19:29] it must conform to the correct coding guidelines (which for now are somewhat loose) and not present any obvious issues [19:30] here I will be looking for memory leaks, crash conditions, general architecture, and overall clarity of the code [19:30] if you pass mustard, we move to step 2, otherwise the problems are noted and the merge will be marked "Needs Fixing" [19:30] you may resubmit at any time if you think the issues have been resolved [19:31] at step 3, I am going to actually install the code on my machine, test that it actually does what its supposed to do, ensure its not doing anything too stupid (leaking tons of memory comes to mind here) [19:31] (coding guidelines here: https://wiki.ubuntu.com/Unity/CodingStyle) [19:31] if that all passes mustard again, I will approve the merge [19:31] if not, I will mark the branch as "Needs Fixing" and send it back to the original developer with the reasoning why [19:32] once approved, assuming the contributor has signed the CA, I will pull the branch into trunk [19:32] and your code ships in the next release [19:32] If you haven't accepted the canonical contributor agreement yet, we'll also send you a mail asking you to either accept/not accept [19:32] https://code.launchpad.net/unity/+merges [19:32] here's the list of all the merges we've had so far [19:32] as you can see, it starts to pile up, which is good [19:33] the more branches we have incoming, the better [19:33] ok so really, those are all the steps, any questions? [19:34] rsajdok asked: Can I develop unity-2d on maverick or only natty? [19:34] Unity-2D has similar requirements to Unity-3d [19:34] I can't say for sure (as I have not checked) but I imagine it would also require natty [19:34] I will ask a Unity-2D dev right now [19:35] mhall119 asked: what info do you want attached to bug reports against Unity? [19:35] General system info is always helpful for starters [19:35] things like CPU, 64 vs 32 bit, GPU, and amount of memory [19:36] we also like to know what package version of compiz and unity you have [19:36] and if you can include steps to reproduce teh issue, that is awesome [19:37] (if you're reporting a bug on the unity in natty "ubuntu-bug unity" will snag a bunch of data for us) [19:37] if the issue is intermittent (and many issues with X/compiz are), if you can manage to get a backtrace using GDB, you instantly become a hero, and we sing your praises on high [19:37] wolfpack asked: Does building and installing UNITY does not removes originally installed unity? [19:38] it depends on where you install it to [19:38] if you install it into /usr, it will overwrite the existing unity plugin [19:38] if you install it anywhere else, it does not [19:38] if you accidentally overwrite the existing plugin, you can do sudo aptitude reinstall unity [19:38] to install the old version again [19:39] more questions? [19:40] DBO: he goes on to ask "So both wiil be working together if installed in directory othe than /usr? " [19:40] wolfpack, you would have to use an env variable to tell compiz which one to use [19:41] ok while we wait for questions [19:41] DBO: why don't you go into some of the architecture [19:41] like, what does what [19:42] wolfpack, I'll get you more details on that in a bit, i actually dont have them off hand because I run my dev setup a bit differently [19:42] jcastro, sure no problem [19:43] jcastro, Unity is broken down into 3 major components. The plugin interface, the UI elements, and the backend elements. [19:43] The plugin interface exists entirely in a file named unityshell.cpp. This is where you go to look for any bug dealing with interactions between unity and compiz [19:44] event handling, grabbing of and passing off events, and other plugin interactions are performed here. This is also the main entry point for Unity [19:44] Unity is also painted from this file (there is a pretty clear paint function if you open it up) [19:45] (jcastro, feel free to interrupt me with questions) [19:45] UI elements are things like the launcher, quicklist, panel, or palces [19:46] these elements are rendered using a library called Nux [19:46] Nux widgets are not that dissimilar from GTK or Qt widgets save for the fact that they can be embedded into existing openGL contexts [19:47] UI elements are laid out in a semi-hierarchal fashion, just like qt and gtk [19:47] really if you have worked in any toolkit before, you should not feel that far out of your comfort zone [19:47] rsajdok asked: Is it possible to develop Unity on virtual machine? [19:47] not last I checked [19:48] most virtual machine drivers still dont do FBO's yet [19:48] which means we cant draw properly [19:48] for a time Virtualbox 4 ran it [19:48] I hear rumors that vmware has fixed this, but I have not tested that [19:48] then we ran into the Xorg transition in natty [19:48] wolfpack asked: Am I allowed to upload patches for bugs? As I can make connection through http only . No ssh is allowed her. [19:49] wolfpack, we take patches :) [19:49] wolfpack, if you can communicate your patch to us through bongos and a string and we understand it, we'll take it [19:50] Amoz asked: sorry for being a bit late, but when you talked about the system info part, and getting a backtrace with GDB, is there a specific command to collect all this information? [19:50] ubuntu-bug unity collects most of the info [19:50] There are 10 minutes remaining in the current session. [19:51] backtraces can be trickier, usually what I do is ssh in from another machine (or switch to a VT), then run "sudo gdb" [19:51] inside gdb, I run "attach [19:51] you will have to check the pid of compiz before you start gdb [19:51] after it finishes attaching, you can simply run "backtrace" adn get the data [19:52] wolfpack, if you need help at the time of collection, you can always stop by #ayatana, and we can walk you through it no problem [19:52] erm [19:52] I am not sure that was wolfpack asking that [19:52] i meant Amoz :) [19:53] 10 minutes left, more questions? [19:54] mhall119 asked: SInce we can't test in a virtualmachine, can we at least run Unity from a LiveCD now? [19:54] live CD is an acceptable way to run unity, we suggest running from a USB key so you can save [19:55] there's been some real churn due to the Xorg transition with people getting working desktops to test on Unity [19:55] Alpha 3 (this thursday) will finally have all that sorted [19:55] There are 5 minutes remaining in the current session. [19:56] jderose asked: I'd like to help document the Python API... what's the best way to do with for gobject introspection? can i make help(Unity.foo) show something useful? [19:57] ohh, please join us in #ayatana after this session [19:57] and we can sort that [19:57] akshatj asked: Are there any plans to provide a Unity Live CD like Gnome Shell does? [19:57] jderose, yes, #ayatana, we'll get you in touch with the right peoples [19:57] akshatj, its called the 11.04 release of Ubuntu :) [19:57] yep, on thursday! [19:58] ok well that's about it [19:58] thanks for participating [19:58] we hope you snag the unity code [19:58] and mess with it, make it better, so that you can contribute! [19:58] DBO: nice job! [19:59] alright, next class, smoke if you got em! [19:59] * DBO bows and dances off stage, ashley simpson style [20:00] * tumbleweed waves [20:00] thanks jcastro and DBO === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Getting your fixes into Ubuntu , how to make sponsors happy - Instructors: tumbleweed [20:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html following the conclusion of the session. [20:01] Hi, and welcome everyone. [20:01] I know it's been a long evening (in my timezone), [20:01] let's bring it to a close with something that helps you get things done in Ubuntu. [20:01] Please ask questions in #ubuntu-classroom-chat, I'll answer them regularly, they'll make this discussion much more interesting. [20:02] darkdevil56: yeah, 10pm here [20:02] I'm Stefano Rivera. I live in sunny Cape Town, South Africa, and am an Ubuntu MOTU and Debian Developer. [20:02] My main interests are Python-related packages, and helping people with Ubuntu Development. [20:02] Tonight I'm talking abut the Ubuntu Sponsorship Queue. [20:03] This talk will be less practical examples like dholbach and barry's excellent talks earlier, and more discussion. [20:03] There's simply no way I can cover examples on how to do everything :) [20:03] The sponsorship queue is how you get things uploaded when you don't have upload rights yourself. [20:03] https://wiki.ubuntu.com/SponsorshipProcess [20:04] All new Ubuntu developers use it, it's how we learned and showed our skills, that led to us becoming Ubuntu developers. [20:04] so, what, why? [20:04] Let's say there's a bug in an Ubuntu package you want to fix. You have a patch for it. [20:04] You could file a bug in Launchpad, with the patch, but as I'm sure you've seen, the bug may go without any feedback for a long time... [20:05] Ubuntu has ~100 000 open bugs, and ~2 000 bugs with patches. That's a lot, far too many for us to ever get around to fixing them all. [20:05] So, instead of waiting for someone else to test & integrate your patch, you could do the next step, and prepare the upload for the Ubuntu archive. [20:05] You do this, request sponsorship, and an Ubuntu Developer who has the necessary rights will then come along, review your work, and if it's ready, sign it and upload it to the archive for you. [20:05] This is more work for you, than filing a bug with a patch, but you'll learn more, and eventually can earn yourself Ubuntu upload rights. [20:06] Someone has to prepare every upload, so if you want something desperately, it might as well be you who does the work. [20:06] For example, I'm a MOTU, but before I was, I used the sponsorship queue to do work on universe packages. [20:06] To fix bugs, upload new versions, and do SRUs (updates to stable releases). [20:06] As a MOTU, I can upload to universe, but not to Ubuntu "main" or "restricted" packages. [20:07] For those, I have to go through the sponsorship queue. [20:07] Of course, because I *can* upload to universe, I review universe things on sponsorship queue, and sponsor the uploads. [20:07] I'm not the only one. We have "Patch Pilot"s every day, who sit down for a few hours, reviewing things in the queue [20:07] Now, I can't tell you how to go from every patch out there, to an upload ready for sponsorship, there are just too many possibilities. [20:07] However, if you followed barry's talk earlier, you will have already got as far as posting something into the sponsorship queue. [20:08] http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html#t18:22 [20:08] Beyond that, you need to read up more generally about Debian packaging: [20:08] https://wiki.ubuntu.com/PackagingGuide http://www.debian.org/doc/maint-guide/ [20:08] And our sponsors are awesome. When they review your work, you'll get good feedback, that should improve your knowledge and abilities. [20:09] When you propose a bzr merge against an Ubuntu branch, it'll be picked up by the sponsorship queue. [20:09] http://reports.qa.ubuntu.com/reports/sponsoring/index.html (this page is generated every half hour or so) [20:09] You can see a few I proposed earlier today (near the bottom), two samba SRUs: ntlm-auth-623342. [20:10] There's another way to get things into the queue, if you attach a "debdiff" patch to a bug, and subscribe "ubuntu-sponsors" to the bug. [20:10] You create a debdiff by running the "debdiff" command from devscripts on two source packages (.dsc files). debdiff will give you the diff between them. [20:10] It's up to you which approach you find more comfortable. [20:10] I find UDD (bzr) more flexible, e.g. it handles new upstream versions quite well, but not all developers prefer it. [20:10] When you are doing merging, for example, it can be quite confusing to read the diffs, in UDD. [20:11] ok, that's a broad overview of the sponsors, what we do, and how [20:11] (any questions?) [20:12] right, let's go on to the meat of this, how to make sponsors happy: [20:12] I'm just going to list some stuff here, I hope to get some decent questions on them: [20:12] * Read the debdiff / bzr diff that you propose [20:12] - The sponsor is going to be reading it, so you should as well. You might find mistakes you made. [20:13] - Does the changelog entry accurately describe the changes? [20:13] + There's a mailing list, natty-changes, where the changelog entries of all natty uploads get mailed (same for other releases) [20:14] people read these, wanting to understand how things are changing [20:14] the changelog is the how you communicate what you've done [20:14] it also helps future mergers to understand what's necessary, and what isn't [20:14] + "Fixed FTBFS" is a poor description, rather say "explicitly linked to libfoo to fix FTBFS with ld --as-needed" [20:15] * Was your fix the right fix? [20:15] - Does it work, and fix the issue? [20:16] - Does it belong in Ubuntu, or in Debian, or upstream? [20:16] (of course, the debian session is tommorrow night) [20:16] - Is it minimal? We try to change as little as possible in Ubuntu, the closer it is to Debian, the less work we have to do. [20:16] that's something that's worth going into: [20:17] Whenever we make a change in Ubuntu, we have to carry it until we can pass it upstream [20:17] The majority of our packages, we import directly from Debian, with no changes [20:17] these happen automatically [20:17] however, when we have changes, whenever we want a new version from Debian, we have to manually re-add the changes to the new version [20:18] this is Merging https://wiki.ubuntu.com/UbuntuDevelopment/Merging [20:19] so, if a package is currently unmodified in Ubuntu, it may be a bad idea to change it, just to correct a spelling mistake like barry did earlier [20:19] we should rather report the spelling mistake to the upstream, and we'll get the benefit of the fix, without extra effort, when the upstram releases a new version [20:19] tumbleweed: there are ways to do it. i did not have time to talk about how to integrate udd with patch systems, but that's laid out in the wiki pages [20:19] tumbleweed: yes, that's always ideal [20:20] barry: thanks :) [20:20] :) [20:20] chadadavis: Yes, it probably will be accepted upstream easily [20:21] chadadavis: but if it's not a major issue, why waste development time on it in Ubuntu, and Debian, and upstream [20:21] why not just get it straight upstream [20:21] (err, that qustion was) [20:21] 22:20 < chadadavis> But if the change is so trivial, wouldn't it also be more likely to be accepted upstream? How is the review process in that direction. Can any of that be 'seen' from Launchpad? === palhmbs is now known as palhmbs_ [20:21] So, yes Debian developers can chose to see the changes Ubuntu makes [20:22] some do, some don't [20:22] in general, if you want to get their attention, you should file a bug in Debian, with a patch [20:22] upstreams can also chose to follow their bugs in Ubuntu, by subscribing to their package [20:23] but some packages have thousands of bugs filed against them in Ubuntu, and nobody can sift through them easily [20:24] 22:23 < chadadavis> But bugs against ubuntu stay in Launchpad until they are fixed upstream then? Assuming one would prefer to fix a certain bug upstream than make the change in Ubuntu? [20:24] correct. And maybe nobody will notice and close the bug. That happens a lot. Ubuntu has too many bugs for them to be kept well up to date [20:24] 36DAA71NS asked: The problem sometimes is that a bug discovered in ubuntu leads to an orphaned upstream package. Therefore the fix in Ubuntu seems to be easier although it's more expensive on the long run. Right? [20:25] I don't know if bugs in Ubuntu *lead* to packages being orphaned upstream, but yes, we certainly have packages in Ubuntu that no upstream cares about any more [20:25] and yes, in that case, fixing it in Ubuntu is the only option [20:26] when I said "Does it belong in Ubuntu, or in Debian, or upstream?", that requires some context to judge it [20:26] if you feel unsure, ask in #ubuntu-motu, there are almost alwysa people around who'll help [20:27] < 36DAA71NS> The problem seems that there's no easy way to get the bugs fixed upstream [20:27] that's unfortunatly true in many places [20:27] however there are also upstreams who merge patches I send them within the hour [20:28] Ubuntu is big, we have a bit of everything :) [20:28] continuing with my recommendations, if there are no more questions: [20:28] * Test your fix: [20:28] - Test-build it in pbuilder / sbuild / a PPA [20:29] - read what lintian has to say. Many packages arrive from Debian, with loud lintian warnings. Don't worry about that, worry about new ones that you are responsible for. [20:29] - Does it install / upgrade correctly (if you touched maintainer scripts) [20:29] these are pretty common sense, but we all slip up :) [20:29] * Should the bug / patch be forwarded to Debian? [20:30] - If you do this, link the Debian bug back to the launchpad bug (also affects project), that way the sponsor knows you did your homework. [20:30] it's not just to say you did your homework, it'll help future mergers (quite possibly you) to remember [20:31] ok, I've run out of pre-typed recommendations, and am hoping for some more questions [20:32] other things I can suggest for people wanting to get into ubuntu devolpment: [20:32] - take a look at how other people are solving problems. Read natty-changes or install apt-listchanges [20:33] < 36DAA71NS> So basically a good way is to find the corresponging bugtracker to see whether the upstream project is alive or not [20:33] most upstreams are alive [20:34] and many bugs that we fix day to day are about taking patches from upstream bugtrackers and pulling them into Ubuntu [20:34] or fixing bugs in our packaging [20:34] these things obviously don't involve any fowarding upstream (although possibly to Debian, for packaging issues) [20:34] < 36DAA71NS> after that contact MOTUs via IRC and proceed afterwards? [20:35] Yeah #ubuntu-motu is very friendly to beginner ubuntu contributors. I waste way too many evenings there :) [20:35] < chadadavis> Does Launchpad's tracker for a package generally link to the corresponding upstream tracker? I.e. does Launchpad have a facility like that built in? [20:36] yes it does. Most small packages aren't linked to an upstream tracker (this requires registering a launchpad project in th ename of the upstraem package) [20:36] but most big ones are [20:36] of course Rhonda will be covering a fair portion of this in her talk tomorrow night, on getting things into Debian [20:38] anything else? or are we all falling asleep :) [20:38] < chadadavis> General newbie question: would you recommend browsing bugs across all packages (i.e. the most critical/newest) to get a feel for all of ubuntu, or do newbies contribute more by becoming more familiar with the innards of just a few packages? [20:38] I'll be honest, I don't browse new bugs on launchpad very much [20:39] there are pretty awesome people out there who do that, and triage them [20:39] I'm subscribed to the bugs of packages I care about, and I try to deal with all of them [20:39] (this does mean my bug inbox gets pretty full when I've been busy with other things) [20:40] but there's a new site out there to help you find things to fix in Ubuntu (I'm suprised I didn't see dholbach mention it yet) [20:40] http://harvest.ubuntu.com/ [20:41] that tries to pick out th einteresting things from launchpad, that are ready to deal with [20:41] < Endanwender> What is with bug-fixes submitted in Debian? How long it need to find the way in Ubuntu? [20:41] So, Ubuntu releases once every 6 months [20:42] from about a week after the release, until Debian Import Freeze, we automatically pull new versions of packages from Debian into Ubuntu [20:43] Debian Import Freeze was around new year, in natty http://wiki.ubuntu.com/NattyReleaseSchedule [20:43] during that time, any uploads to debian get pulled over pretty quickly (assuming we haven't deviated from Debian) [20:44] how long between submitting a bug fix to debian and, and the debian maintainer of th epackage uploading th efix, well that varies [20:44] debian is like any other upsteram in that respect [20:44] some debian packages are small, actively maintained and have 0 bugs, others are fighting under the deluge of hundreds of bugs. And there's a lot inbetween. [20:46] anything else? [20:50] Endanwender asked: Have I understood the correctly? Between the release cycles of Ubuntu and Debian no further exchange between bug-fixes and so on takes place? [20:50] Endanwender: so, there are Debian Developers who take active care of their packages in Ubuntu [20:50] There are 10 minutes remaining in the current session. [20:50] you could say I'm one of them [20:51] if I see a serious bug reported in Debian, I'll make sure the fix gets into Ubuntu soon [20:51] and if I see a bug reported in Ubuntu, I'll fix it in Debian, and sync it across to Ubuntu [20:51] but there are no formal bug exchanges [20:52] if you want to forward a bug from Ubuntu to Debian or vice-versa, you need to do it manually [20:52] (we have tools to automate this in ubuntu-dev-tools) [20:52] and Rhonda in sure to go into deal on it tomorrow night [20:52] detail [20:53] the reason for this is that not all Ubuntu bug reports are of interest, or even relevant to Upstream / Debian [20:53] the upstreams need to decide for themselves, if they want to spend the time reading and understanding them. [20:55] There are 5 minutes remaining in the current session. [20:57] Endanwender asked: Ah ok. Thx for the info. I'm a little bit surprised about this. I thought both distrubution have a direct exchange concerning this. [20:57] Endanwender: we keep things that can't be automated perfectly manual [20:58] but you'll find most Ubuntu developers should know thier way around th Debian and Redhat bugtrackers, quite well === 36DAA71NS is now known as hugohirsch [20:59] * tumbleweed guesses that's that [20:59] thanks for listening everyone, hope you enjoyed th efirst day of Ubuntu Developer Week, and will be back for more, tomorrow [20:59] good night :) [21:00] Logs for this session will be available at http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html === 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 || === palhmbs_ is now known as palhmbs [22:30] is this the right channel for the Ubuntu Developer week? [22:31] shizzle: yes [22:32] Thanks === herb__ is now known as herb === SuperHark is now known as MichealH === palhmbs is now known as Guest5969 === pleia2_ is now known as pleia2 [23:11] does anyone have a book to be a linux developer?? === nhandler_ is now known as nhandler === Guest5969 is now known as Guest5969_ === palhmbs is now known as palhmbs_ === palhmbs_ is now known as palhmbs