[04:32] <Gillfish> can anyone tell me if I can set this up to log the classes tomorrow?
[04:34] <JoseeAntonioR> Gillfish: you're all set for tomorrow :)
[04:35] <JoseeAntonioR> Gillfish: logs will be available after the sessions
[04:35] <Gillfish> thanks.  I have to attend this for A college class
[04:35] <JoseeAntonioR> no worries
[08:12] <deepak> hello
[09:51] <Anand_> is it started?
[12:46] <Cobold> Hi all..?
[13:00] <djones_> hello
[13:01] <genupulas> djones_, this is Official Channel , If you want help please do at #ubuntu
[13:02] <djones_> no dont need help just saying hello waiting for the discussions to start
[13:03] <genupulas> please join at #ubuntu-classroom-chat
[13:50] <xkernel> Does this channel will host the Ubuntu Developer week today's session?
[13:53] <genupulas> yes
[13:53] <genupulas> xkernel,
[14:23] <mohamedalaa98> About an half hour remaining :)
[14:23] <mohamedalaa98> *a
[14:26] <Geeknux> still waiting!
[14:26] <DoctorRon> Hey there friends...
[14:26] <Gladen> Just to be clear, join #ubuntu-classroom-chat for the regular smalltalk :P
[14:36] <Gillfish> j/ #ubuntu-classroom-chat
[14:48] <dudel> s
[14:50] <JoseeAntonioR> Hey! Remember all discussion/questions will take place in #ubuntu-classroom-chat, you should join by typing "/j #ubuntu-classroom-chat" without quotes if you're not already in there :)
[14:51]  * dholbach hugs JoseeAntonioR
[14:51]  * JoseeAntonioR hugs dholbach back
[14:52] <quequotion> what's coming up on the schedule?
[14:52] <dholbach> quequotion, https://wiki.ubuntu.com/UbuntuDeveloperWeek/ :)
[14:52] <phoenix_firebrd> dholbach: hi
[14:53]  * quequotion runs date -u
[14:54] <tuxfan_> 6min and counting :)
[14:55] <quequotion> oh.... Unity's not for another 4 hours... too bad I have work early tomorrow morning....
[14:55]  * mohamedalaa98 is waiting
[14:55] <JoseeAntonioR> quequotion: we'll have logs of everything
[14:55] <tuxfan_> QUESTION: Will there be logs of the session cause i toohave to work :)
[14:56] <quequotion> logs aren't as good as partcicipation :(
[14:57] <amin_> 2mins
[14:57] <dholbach> quequotion, the good thing is, after reading the logs you'll know more and you know who to ask all the questions you might have - today is not the only day all these people are on IRC :-)
[14:58] <quequotion> dholbach, true, but I hope i'll find as effective an opportunity to give my opinions as well.
[15:00] <dholbach> WELCOME EVERYBODY TO A GREAT UBUNTU DEVELOPER WEEK! :-)
[15:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html following the conclusion of the session.
[15:01] <dholbach> We have three days of great sessions lined up to get you started with Ubuntu Development, to help you get to know some other developers and find new friends - and of course have a lot of fun.
[15:01] <dholbach> First a few organisational bits and pieces:
[15:01] <dholbach>  - There will be logs after the sessions. We will link them from the timetable on https://wiki.ubuntu.com/UbuntuDeveloperWeek/
[15:02] <dholbach>  - If you have questions, please do ask! But please ask in #ubuntu-classroom-chat - if you're not there, please join now.
[15:02] <dholbach>  - When you ask questions, please prefix them with QUESTION: - ie: QUESTION: What is jcastro's favourite electronic music artist?
[15:02] <dholbach>     This way the questions will stand out and the bot can pick them up easily.
[15:03] <dholbach> All right - with that... let's get started. :-)
[15:04] <dholbach> My name is Daniel Holbach, I live in Berlin, Germany and have been part of the Ubuntu project since about 8 years now and always loved Ubuntu development and our community. So that's what I mostly work on.
[15:04] <dholbach> We'll have two hours to get you introduced to Ubuntu Development and get your development environment set up.
[15:05] <dholbach> After that you should be able to build packages, you should know where to find things, and at least have heard the most important bits and pieces once. :-)
[15:05] <dholbach> If I'm going too fast, too slow, don't make sense or you have questions, please ask - #ubuntu-classroom-chat is all yours. :-)
[15:05] <ClassBot> jierro asked: What is jcastro's favourite electronic music artist?
[15:06] <dholbach> It's deadmau5 or however the mau5 is spelled and he mentions him at least once a day to me. :-)
[15:06] <dholbach> Let's see if we get more Ubuntu development related questions though next. ;-)
[15:07] <dholbach> Ubuntu is made up of thousands of different components, written in many different programming languages. Every component - be it a software library, a tool or a graphical application - is available as a source package. Source packages in most cases consist of two parts: the actual source code and metadata.
[15:07] <dholbach> Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package. Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install.
[15:07] <ClassBot> quequotion asked: are we really going to learn how to build packages, or more specifically debian-package things? I've spent a lot of time not getting that right.
[15:08] <dholbach> quequotion, we'll see how much time we have during these two sessions, but maybe I can provide a little overview - there'll be more content about this during the week though.
[15:08] <ClassBot> tuxfan_ asked: will this session have to do with quickly and python specifically?
[15:09] <dholbach> tuxfan_, no, but at 19:00 UTC there'll be a session about Ubuntu App Developer Tools led by mhall119 where this will be covered.
[15:09] <dholbach> Also will an  Ubuntu *App* Developer Week  be scheduled soon, which will have lots of app-related content, while at Ubuntu Developer Week we'll mostly concentrate on developing Ubuntu itself
[15:09] <ClassBot> jincreator asked: Due to some problems, currently my environment is precise. Is it can be problem to follow sessions?
[15:10] <dholbach> jincreator, yes, should be fine - we'll get back to the question in about an hour :)
[15:10] <dholbach> 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.
[15:10] <dholbach> The 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.
[15:11] <dholbach> Any more questions so far?
[15:11] <dholbach> Ok, cool - let's talk a bit more about how we put together releases then.
[15:12] <dholbach> Ubuntu’s development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates.
[15:12] <dholbach> With every freeze date that is reached developers are expected to make fewer, less intrusive changes. Feature Freeze is the first big freeze date after the first half of the cycle has passed.
[15:12] <dholbach> At this stage features must be largely implemented. 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.
[15:13] <dholbach> 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.
[15:13] <ClassBot> tuxfan_ asked: What do you mean by freeze date?
[15:13] <dholbach> If you have a look at https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule you can see the schedule for the current 13.04 release.
[15:14] <dholbach> If you scroll down a little bit you can see that in March we have established a few dates, which are basically deadlines for all the Ubuntu developers.
[15:15] <dholbach> So in order to get a good release out, we agree on these dates beforehand and make sure that towards the end of a release cycle we just stabilise and fix and stop introducing crazy big changes. :-)
[15:15] <ClassBot> maxi_ asked: freature freeze is is always the first freeze?
[15:15] <dholbach> We have some deadlines before, like "Feature Definition Freeze" where the plans for the release need to be ironed out.
[15:16] <dholbach> (More on the planning aspect in a bit.)
[15:16] <dholbach> And "Debian Import Freeze" which means that we stop automatically importing changes from Debian. (More on that in a sec too.)
[15:16] <dholbach> But yes, Feature Freeze, is the first big, notable, one.
[15:16] <ClassBot> tuxfan_ asked: So freeze date is like deadlines for big changes in the OS and then from these dates and on only critical bug fixxing?
[15:16] <dholbach> tuxfan_, yes.
[15:17] <dholbach> This also determines what kind of things Ubuntu developers, volunteers and enthusiasts work on.
[15:17] <dholbach> If you want to get big crazy changes introduced in Ubuntu 2 days before the release, you will have a hard time arguing with the release team. :-)
[15:17] <ClassBot> mohamedalaa98 asked: what is the most important programming languages that should be learned to start development in ubuntu?
[15:18] <dholbach> Almost all programming languages are used in Ubuntu. On the Ubuntu installation CD you will have C, C++, Perl, Python, C# (I think), Vala, Go (I think) and many others.
[15:19] <dholbach> For low-level things like interaction with hardware, C is used a lot. Python is a favourite within the Ubuntu world, but we're not limited to it.
[15:19] <dholbach> All right, since it came up earlier, let's talk a bit about feature planning.
[15:20] <dholbach> 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. 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.
[15:20] <dholbach> 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.
[15:20] <dholbach> This is all done in an open and transparent fashion, so even if you cannot attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants and subscribe to changes of specifications, so you are always up to date.
[15:21] <ClassBot> xkernel asked: If I want to develop a feature or solve a bug say in Unity, how do I test it?
[15:22] <dholbach> xkernel, I'll get back to the question in more detail in a bit, but basically when you have your development environment set up, you can very easily hack on a package, do some changes, test-build it, test-install it and see if it works and then propose your change for inclusion.
[15:22] <ClassBot> johnhamelink asked: You mentioned that if there are no major bugs in ubuntu then an RC becomes the final release, how do you make sure bugs don't regress?
[15:22] <dholbach> johnhamelink, great question! :-)
[15:22] <dholbach> We'll have some sessions on Automated Testing this week.
[15:22] <dholbach> Tomorrow 18:00 UTC - Testing with autopilot -- balloons
[15:23] <dholbach> Thursday 15:00 UTC - Automated Testing in Ubuntu -- pitti
[15:23] <dholbach> We have lots of automated testing infrastructure in place, so that whenever changes are introduced test suites are run again and changes can only go in if the test suites pass. That's the reason why writing test cases is an excellent way to help Ubuntu in terms of Ubuntu development.
[15:24] <dholbach> Coming back to Ubuntu Developer Summit and feature planning: 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.
[15:25] <dholbach> 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.
[15:25] <dholbach> https://wiki.ubuntu.com/Teams might be a first step to finding out which team to contact how. I'll share some more info later on though.
[15:25] <dholbach> 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.
[15:26] <dholbach> 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.
[15:26] <dholbach> 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.
[15:26] <dholbach> These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it.
[15:27] <dholbach> 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).
 QUESTION :  I'm a C/C++ developer new to ubuntu where shall I start with ?
[15:28] <dholbach> CodeRed, You're absolutely right just where you are now. In this session I'll give a quick introduction and overview over Ubuntu Development and in the second session we'll talk about "getting set up" - afterwards I'll also share a few links on where to go next. Thanks a lot for your interest! :-)
[15:28] <ClassBot> Lionthinker asked: are derivatives the only downstreams for Ubuntu?
[15:29] <dholbach> Lionthinker, Ubuntu is used in many many places. There are derivatives/flavours/remixes, there are device manufacturers using it with small modifications, there are operators of clouds using it. There are LOTS and LOTS. :)
[15:29] <ClassBot> tuxfan_ asked: So you are saying that through Upstream 3rd party apps bugs are fixed by ubuntu team?
[15:30] <dholbach> tuxfan_, In most of the cases the software authors are in the best possible position to fix bugs, as they know the code well, but yes, it happens that bugs are fixed in Ubuntu and patches sent upstream. Depending on the project it happens a lot.
[15:30] <ClassBot> everestt asked: What is a downstream?
[15:31] <dholbach> everestt, Imagine software being written somewhere, then distributed by somebody else, then this is used by somebody else.
[15:32] <dholbach> As an Ubuntu user, you could see some app as the Upstream, if it's in Debian, then Debian's upstream too, and Mint could be seen as s Downstream. :)
[15:33] <ClassBot> dutchguy asked: Are you not afraid of beginner developers introducing bugs into a project?
[15:33] <dholbach> dutchguy, We have a very good review process for new contributors, which I'll talk about in a bit.
[15:33] <dholbach> 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.
[15:34] <dholbach> 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.
[15:35] <dholbach> 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.
[15:35] <dholbach> Open Source Development happens in a distributed world with different goals and different areas of focus. For example there might be the case that a particular Upstream is interested in working on a new big feature while Ubuntu, because of the tight release schedule, is interested in shipping a solid version with just an additional bug fix.
[15:36] <dholbach> 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.
[15:37] <dholbach> So let's say we have  superedit 1.0  in Ubuntu and Upstream is working on a rewrite of their font rendering for the 1.1 release.
[15:38] <dholbach> If Ubuntu just has a couple of weeks until release left, we'll stick with 1.0 obviously. If there's a bug fix we need, we can add that on top of our 1.0 version and forward it to Upstream if they don't have it included yet.
[15:38] <dholbach> Once the Ubuntu is released and the new release cycle started, we can take 1.1 from Upstream and we're totally in sync with Upstream again.
[15:39] <dholbach> Maybe with this example you can imagine how multiple teams can work in similar but different directions because of different timelines.
[15:39] <dholbach> The bigger the differences between the teams become, the harder it will be to maintain the delta in code, etc. That's why collaboration and planning is so important.
[15:40] <ClassBot> jierro asked: Is development on ubuntu for tablets and phones already benefiting on ubuntu for desktop in any way? Like memory leaks, optimisations and stuff
[15:40] <dholbach> jierro, Yes, absolutely. Wherever the code base is the same you will fix the bug (be it in functionality, memory usage or anything else) in one place and everybody will benefit. That's the beauty. :-)
[15:40] <ClassBot> tuxfan_ asked: But will ver1.1 be updated in the allready released ubuntu version?
[15:41] <dholbach> tuxfan_, that depends - if it's only serious bug fixes, it can go into the stable release ("stable release update" - "sru"), but if not, it can probably be backported
[15:42] <dholbach> a rewrite of the font rendering (as in the example above) won't constitute a serious bug fix though :)
[15:42] <ClassBot> maxi_ asked: why sometimes near the release are added visual characteristics?
[15:42] <dholbach> maxi_, sometimes teams are late and they get freeze exceptions from the release team :)
[15:42] <ClassBot> rt01 asked: does ubuntu maintain communication with upstream ? for example, if a bug is found in one particular version, does ubuntu proactively communicates upstream to find it fixed or it just waits until upstream releases a new version ?
[15:43] <dholbach> rt01, that depends - of course we can't just forward ALL the bugs to upstream, but for a lot of projects we have very healthy communication channels where bugs, patches and information are passed back and forth
[15:43] <dholbach> also many Ubuntu developers are actively involved in other projects (wear multiple hats)
[15:43] <ClassBot> Lionthinker asked: if an upstream project is not yet done when freezing and shipping commences, can and does Ubuntu update the apps when released?
[15:44] <dholbach> Lionthinker, I answered the question above. "that depends - if it's only serious bug fixes, it can go into the stable release ("stable release update" - "sru"), but if not, it can probably be backported
[15:44] <dholbach>  a rewrite of the font rendering (as in the example above) won't constitute a serious bug fix though :)"
[15:44] <ClassBot> Niraj_ asked: Why does it happen sometimes that some old release updates do not contain updated version of a package, whereas later releases include that update?
[15:44] <dholbach> Niraj_, see above
[15:44] <dholbach> it's because every change we introduce in a stable release might break functionality for millions of users
[15:45] <dholbach> we have to be very very conservative with stable releases
[15:45] <ClassBot> CodeRed asked: what skills are required for ubuntu kernel development ?
[15:45] <dholbach> CodeRed, C skills will be necessary and https://wiki.ubuntu.com/KernelTeam might be a good start
[15:45] <ClassBot> skyra asked: Which is better idea to fix the bug in the upstream directly or to fix it in ubuntu and send it upstream? Or there is no difference?
[15:46] <dholbach> skyra, that depends - if we only have short time to fix the bug in Ubuntu because of the release date, we might want to get the fix into Ubuntu first and then forward it
[15:46] <dholbach> if it's a small bug, we can forward it first and then get it from upstream in the next release
[15:46] <ClassBot> Lionthinker asked: if an upstream project is not yet done when freezing and shipping commences, can and does Ubuntu update the apps when released?
[15:46] <dholbach> already answered
[15:46] <ClassBot> tuxfan_ asked: So why don't you just release it after becoming stable. I mean sometimes apps in later Ubuntu releases don't arrive in former Ubuntu releases (e.g 12.10 app ver won't probably make it in 12.04)
[15:47] <dholbach> I think this kind of question is sufficiently answered now.
[15:47] <dholbach> It's also quite relevant that maintaining several stable releases at the same time is a serious burden in terms of work.
[15:47] <ClassBot> Brace asked: If you only have a few hours here and there (say one evening a fortnight) is it still possible to help out?
[15:48] <dholbach> Brace, absolutely. We have many pupils, students, people who have a day job or who just have a couple of hours every now and then and they all contribute to Ubuntu. :-)
[15:48] <ClassBot> nep1x asked: What does "backported" mean?
[15:49] <dholbach> nep1x, there are many repositories for Ubuntu. There's the release repository obviously, there's "-security" with security fixes, there's "-updates" with critical fixes, and then theres's "-backports" with Ubuntu backports, so new versions which go into the release after it's released. (Generally safe, but use at your own risk.)
[15:49] <ClassBot> tuxfan_ asked: Does conservative mean that non LTS releases are "equipped" mostly with non stable app versions? whilst LTS with stable ones?
[15:50] <dholbach> tuxfan_, no
[15:50] <dholbach> tuxfan_, it means that fixes have to be super-safe before they go into a stable release, no matter if LTS or not
[15:50] <ClassBot> There are 10 minutes remaining in the current session.
[15:50] <dholbach> tuxfan_, we had "obvious one line fixes" which broke functionality for users or some of our users
[15:50] <ClassBot> jincreator asked: I heard about MicroReleaseException. What is required that package become on MRE?
[15:51] <dholbach> jincreator, https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
[15:51] <ClassBot> Lionthinker asked: how will a rolling release schedule change development?
[15:51] <dholbach> Interesting question,but we won't have time for this in this session. Try googling for some of the recent articles about it.
[15:52] <dholbach> I'll quickly get back to the "Introduction to Ubuntu Development". :-)
[15:52] <dholbach> So let's say we want to fix a bug in Ubuntu.
[15:52] <dholbach> 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.
[15:52] <dholbach> 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.
[15:53] <dholbach> So this is the code review bit I talked about earlier. Although we have documentation, this is the primary way you will learn conventions and it's a great way to get to know other Ubuntu developers.
[15:53] <dholbach> After a while, when you've built a good track record of good contributions, you can apply for upload rights yourself.
[15:53] <dholbach> This whole process is quite straight-forward.
[15:54] <ClassBot> jincreator asked: Why we need freeze for even translating?
[15:54] <dholbach> jincreator, If strings in packages change very late, translators will have to re-do their translations.
[15:54] <ClassBot> bobweaver asked: What is the best approach to talking to a Upstreamer ?  Like is there any case studies on this or are there any plains for launchpad to integrate this function more then just contact this user ? I ask for making recipes and using others branchs
[15:55] <dholbach> bobweaver, Upstream projects have IRC channels and mailing lists of their own, and usually by just a bit of googling you can find them pretty quickly.
[15:55] <ClassBot> There are 5 minutes remaining in the current session.
[15:55] <dholbach> It would be nice to have it all automated in Launchpad and some parts are, but it won't work for "every project" and "every bug tracker" out there.
[15:55] <ClassBot> Lionthinker asked: a developer with upload rights is a MOTU, right?
[15:55] <dholbach> no, MOTUs are just one team with upload rights - more on that in a bit.
[15:56] <dholbach> 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.
[15:56] <dholbach> Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream.
[15:56] <dholbach> The most important thing I want to get across today is that you don't need to be an expert with programming languages or anything. 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.
[15:57] <dholbach> Good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software.
[15:58] <ClassBot> jincreator asked: Why there is freeze that affect even translators? I mean, something like (non)languagetranslationdeadline.
[15:59] <dholbach> jincreator, there are many reasons, some of them are: to give testers the opportunity to try Ubuntu in their own language before release, or size of the translations, etc.
[15:59] <dholbach> All right, let's take 2-3 minutes of a break before we crack on with "Getting set up for Ubuntu Development" - I need to get some more tea!
[15:59] <dholbach> See you in 2-3 mins.
[16:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html following the conclusion of the session.
[16:03] <dholbach> All right my friends - we're back!
[16:04] <dholbach> And we'll kick off "Getting set up for Ubuntu Development" in just a sec.
[16:05] <dholbach> While making a cup of tea I just decided we'll just go through the bare minimum of setting up your development environment today and work on a small fix of our own towards the end of the session.
[16:05] <dholbach> To get every little bit set up, I'll refer you to some really nice documentation later on.
[16:05] <dholbach> Hope that meets your agreement. :-)
[16:06] <dholbach> First of all we'll install some packaging-related software. This includes:
[16:06] <dholbach>  - Ubuntu-specific packaging utilities
[16:06] <dholbach>  - Encryption software so your work can be verified as being done by you
[16:06] <dholbach>  -     Additional encryption software so you can securely transfer files
[16:07] <dholbach> We'll also configure some of the tools you'll need and I'll mention how to get all the rest set up.
[16:08] <dholbach> So somebody asked earlier if it's OK to use an older Ubuntu release and the answer is: 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.
[16:08] <dholbach> Don’t worry though, the Ubuntu development release wiki page (https://wiki.ubuntu.com/UsingDevelopmentReleases) shows a variety of ways to safely use the development release.
[16:09] <dholbach> 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:
[16:09] <dholbach> $ sudo apt-get install packaging-dev
[16:09] <dholbach> (without the $)
[16:09] <dholbach> For users before Ubuntu 11.10 “Oneiric Ocelot”:
[16:10] <dholbach> $ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file
[16:10] <ClassBot> tuxfan_ asked: Does that mean that we have to always have the latest Ubuntu installed (e.g on a VM)?
[16:10] <dholbach> if you want to develop Ubuntu itself, you will have to have a way to verify that the fix you're working on actually works - the most reliable way is to have a VM for example
[16:11] <dholbach> Installing the packages is going to take a while, depending on your internet connection. So let's crack on.
[16:11] <ClassBot> nuragussuryoko asked: need to confirm, is "current development version of Ubuntu" == 13.04 ?
[16:11] <dholbach> nuragussuryoko, yes. 13.04 aka raring ringtail :)
[16:12] <dholbach> So what we're installing now is going to give us:
[16:12] <dholbach>  - 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.
[16:12] <dholbach>  - pbuilder – a tool to do reproducible builds of a package in a clean and isolated environment.
[16:12] <dholbach>  - ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier.
[16:12] <dholbach>  - bzr-builddeb (and bzr, a dependency) – distributed version control with Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each other’s work.
[16:12] <dholbach>  - apt-file provides an easy way to find the binary package that contains a given file.
[16:13] <dholbach> Next we'll set up pbuilder. A very nice tool you're soon going to love. :-)
[16:14] <dholbach> pbuilder allows you to build packages locally on your machine. It serves a couple of purposes:
[16:14] <dholbach>  - 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
[16:14] <dholbach>  - There is no need to install all necessary build dependencies locally
[16:14] <dholbach>  - You can set up multiple instances for various Ubuntu and Debian releases
[16:14] <dholbach> Setting pbuilder up is very easy, simply run:
[16:14] <dholbach> $ pbuilder-dist <release> create
[16:14] <dholbach> where <release> is for example precise, quantal, raring 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.
[16:15] <dholbach> For now you might want to just run:
[16:15] <dholbach> $ pbuilder-dist raring create
[16:15] <ClassBot> tuxfan_ asked: pbuilder works kinda like a sandbox?or didn't i get it right?
[16:16] <dholbach> tuxfan_, it will use a chrooted environment (http://en.wikipedia.org/wiki/Chroot) to build the package in, this guarantees that the build works reliably and does not depend on some changes you might have done on your local file system somewhere
[16:17] <ClassBot> nep1x asked: Launchpad seems to be a very important component, but I don t understand well what is it exactly. Can you explait it breafly?
[16:18] <dholbach> nep1x, https://launchpad.net is the main infrastructure we use for Ubuntu. Translations of Ubuntu packages (and other projects) live there, bug reports live there, code branches, Ubuntu packages and many many other things.
[16:19] <dholbach> In this session I'll skip setting up your launchpad account, but I'll give some information later on on how to get everything set up over there. (It just takes a couple of minutes.)
[16:19] <ClassBot> quequotion asked: Are the dependencies different for later releases (12.04+)?
[16:19] <dholbach> quequotion, Yes, dependencies of packages change, just as the code changes over different releases.
[16:19] <ClassBot> epikvision asked: Can pbuilder serve as a temporary replacement for not running development release?
[16:20] <dholbach> epikvision, You can, sort of, a little bit, just as you can use a chroot environment - but it's not very convenient (using graphics will be hard, etc.). It's more tailored towards building packages.
[16:20] <ClassBot> Lionthinker asked: Whats a translation in coding speak?
[16:21] <dholbach> Lionthinker, In gedit the first menu point says "File" when I try to click on it. That's "Datei" in German. :-)
[16:21] <ClassBot> quequotion asked: What about multilib packaging, and specifically amd64 with i386?
[16:21] <dholbach> quequotion, Yeah what about it? :)
[16:22] <dholbach> I guess you're referring to multiarch? I'm not sure what your question is about.
[16:22] <dholbach> It was introduced a couple of releases back and it's working well for a lot of common cases. Not all packages have been multiarched yet. http://wiki.debian.org/Multiarch/ has some more background. Hope that helps.
[16:22] <ClassBot> retnan asked: Is it possible to do development on github and having changes updated on launchpad
[16:23] <dholbach> retnan, there's a bzr-git plugin which might help, also are there code imports in Launchpad, but I don't have much experience with those.
[16:23] <ClassBot> quequotion asked: sorry, by dependencies I meant the build environment dependencies; has anything changed since 11.10?
[16:23] <dholbach> quequotion, yes, a lot - running a more recent Ubuntu in a VM will make development easier
[16:24] <dholbach> All right, let's crack on - I hope the installation of the packages and setting up pbuilder worked for all of you or are still in progress. :-)
[16:24] <dholbach> Next let's tell some of the development tools who we are.
[16:25] <dholbach> Please open your ~/.bashrc in a text editor and add something like this to the bottom of it:
[16:25] <dholbach> export DEBFULLNAME="Bob Dobbs"
[16:25] <dholbach> export DEBEMAIL="subgenius@example.com"
[16:25] <dholbach> If you do not use the default shell, which is bash, please edit the configuration file for that shell accordingly.
[16:25] <dholbach> Now save the file and either restart your terminal or run:
[16:26] <dholbach> $ source ~/.bashrc
[16:26] <dholbach> Ok... did this work all work out for everyone? Any questions? Any catastrophes?
[16:27] <ClassBot> phoenix_firebrd asked: what is the difference in using pbuilder-dist and pbuilder
[16:28] <dholbach> phoenix_firebrd, pbuilder-dist is just a wrapper around pbuilder, which makes it very easy to use pbuilder for many different releases, for example can I simply run   pbuilder-dist precise create  to create one for the precise release
[16:28] <dholbach> with plain pbuilder you will have to edit a configuration file, etc
[16:28] <ClassBot> nuragussuryoko asked: sorry n00b one. I'm using 12.10 and was disconnected. Shall I follow-through, or install 13.04 first?
[16:29] <dholbach> nuragussuryoko, feel free to take all the steps we discuss here on your 12.10 installation - later on you can still install 13.04 in a VM (https://wiki.ubuntu.com/UsingDevelopmentReleases will help) and repeat the steps there
[16:29] <ClassBot> phoenix_firebrd asked: what is the difference in using pbuilder-dist and pbuilder
[16:29] <dholbach> ah yes, had that one already
[16:29] <ClassBot> epikvision asked: We only need to run pbuilder <release> once?
[16:29] <dholbach> epikvision, pbuilder-dist <release> create
[16:29] <dholbach> yes, just once
[16:30] <ClassBot> quequotion asked: do i need "export"?
[16:30] <dholbach> quequotion, yes
[16:30] <ClassBot> x86_ asked: I had done that pbuilder-dist step earlier. How do I check if its k and which version is used in place of raring ?
[16:30] <dholbach> x86_,    ls ~/pbuilder/
[16:30] <ClassBot> anish1307i asked: can we use pbuilder to create package in running system and then test it on VM?
[16:30] <dholbach> anish1307i, yes, you can simply copy them over
[16:30] <ClassBot> phoenix_firebrd asked: Is there a way to set the release to example raring or unreleased in bashrc
[16:31] <dholbach> phoenix_firebrd, hum - do I assume correctly that you're talking about the default for the release name in debian/changelog entries?
[16:32] <dholbach> phoenix_firebrd, I'm not 100% sure - can somebody in the audience help out? I'll try to find something real quick, otherwise we'll have to carry on
[16:35] <dholbach> phoenix_firebrd, ok, didn't find it quickly - you might want to refer to "man dch" and add one of the environment variables discussed in there to .devscripts - maybe DEBCHANGE_RELEASE_HEURISTIC?
[16:35] <dholbach> sorry
[16:35] <ClassBot> nep1x asked: do we have to run pbuilder-dist <release> right now? which release? can i get an environment different than the release I ve alredy installed?
[16:36] <dholbach> nep1x, yes, that's possible - please run: "pbuilder-dist raring create"
[16:36] <dholbach> all right, we have around 20 minutes left, so get's get to a quick example of Ubuntu development
[16:36] <dholbach> in my tea break earlier, I deliberately broke a package :)
[16:37] <dholbach> we are going to fix it now :)
[16:37] <dholbach> I pushed my work to lp:~dholbach/ubuntu/raring/hello/crazy-change - to get the branch, simply run:
[16:37] <dholbach> $ bzr branch lp:~dholbach/ubuntu/raring/hello/crazy-change
[16:37] <dholbach> Now simply:
[16:37] <dholbach> $ cd crazy-change
[16:38] <dholbach> If you run "ls debian" now, you will set a list of files which are relevant to the packaging.
[16:39] <dholbach> I made a change to debian/control - if you open the file in your favourite editor, maybe you'll find out which bit I broke. :-)
[16:39] <dholbach> Until somebody mentions it in #ubuntu-classroom-chat I'll talk a bit about what debian/control is all about.
[16:40] <dholbach> You can see that it's divided in two sections. Section 1 is all about the Source of the ("hello" in this case) package.
[16:40] <dholbach> The second one is about the resulting binary package, so the .deb package you would install after a build.
 install-infooooooooo
[16:40] <dholbach> x86_ got it right. :-)
[16:40] <dholbach> The broken line is this one:
[16:40] <dholbach> Depends: ${shlibs:Depends}, dpkg (>= 1.15.4) | install-infoooooooooooooo
[16:41] <dholbach> It specifies the dependencies of the "hello" package after a build.
[16:41] <dholbach> "${shlibs:Depends}" is not a real package name, but it's a variable which is substituted with a list of library packages "hello" depends on.
[16:42] <dholbach> This is determined automatically during the build.
[16:42] <dholbach> If we built the package as it is right now, it'd mean that it would refer to a non-existing package.
[16:42] <dholbach> Please go ahead and change "install-infoooooooooooooo" to "install-info". :-)
[16:42] <dholbach> And save the file.
[16:43] <dholbach> Next please run "dch -i".
[16:43] <dholbach> You can see that an editor is opened with a boiler plate changelog entry which should have your name and email address filled in already. :-)
[16:44] <dholbach> If you have a look at the last changelog entry, you can see an example of a very very bad changelog entry: http://paste.ubuntu.com/1586340/
[16:44] <dholbach> debian/changelog is the place where all the changes we upload to Ubuntu are documented. We do this not just for ourselves, but for all the other Ubuntu developers as well.
[16:45] <dholbach> A good changelog entry includes: a reference of what was changed, where things were changed, why things were changed and if there was a discussion about the changes (like on a mailing list of a bug report), you refer to those as well
[16:45] <dholbach> that's very important, especially if you go back and try to figure why something was changed half a year ago
[16:46] <dholbach> and you should try to have separate bullet points for separate things :-)
[16:46] <dholbach> so for something as simple as fixing the dependency, we could write something like:
[16:47] <dholbach>   * debian/control: fixed dependency: changed "install-infoooooooooooooo" to "install-info".
[16:47] <dholbach> Or something along those lines.
[16:48] <ClassBot> jincreator asked: Where can I find list of variables used in making debian file such as {shlibs:Depends} ?
[16:50] <dholbach> {shlibs:Depends} is probably the most important one, especially if you deal with shared libraries and linked code.
[16:50] <ClassBot> There are 10 minutes remaining in the current session.
[16:50] <dholbach> there's {misc:Depends} and some substitution variables for python and perl as well - I'll give a link to packaging information after the session. :)
[16:50] <ClassBot> johnhamelink asked: If there was a bug report, what would the debian/changelog look like?
[16:51] <dholbach> johnhamelink, good question :)
[16:51] <dholbach> So let's say there was Launchpad bug report 12345678 about the problem I created earlier.
[16:51] <dholbach> In that case you'd simply add  (LP: #12345678)  to the end of the line
[16:51] <dholbach> this would get the bug report automatically closed as soon as the fix lands in Ubuntu
[16:52] <dholbach> So, to build the package, please run:
[16:52] <dholbach> $ bzr bd -- -S
[16:52] <dholbach> This will generate a source package from the branch (which is just a directory with the source code history in it).
[16:53] <dholbach> The source package is a format we use to upload changes to Launchpad and build the binary packages from.
[16:53] <dholbach> If you now run "ls ../hello_*", you will see these files listed:
[16:54] <dholbach> ../hello_2.8-2ubuntu2.debian.tar.gz  ../hello_2.8-2ubuntu2.dsc  ../hello_2.8-2ubuntu2_source.changes  ../hello_2.8.orig.tar.gz
[16:54] <dholbach> They make up the source package.
[16:54] <dholbach> If you now run this command: "pbuilder-dist raring build ../hello_2.8-2ubuntu2.dsc" it will build the binary (.deb package) from the source package.
[16:55] <ClassBot> EagleScreen asked: as the same way you use (LP: #12345678), is there a expecific syntax to reference Debian bug reports?
[16:55] <dholbach> Yes, it's "Closes: #123456"
[16:55] <ClassBot> maxi_ asked: debsign: gpg error occurred!  Aborting.... debuild: fatal error at line 1278: running debsign failed bzr: ERROR: The build failed.
[16:55] <ClassBot> There are 5 minutes remaining in the current session.
[16:56] <dholbach> That's probably because the mail address in your changelog entry does not match any on your GPG key. Feel free to ignore it for now and just run:  bzr bd -- -S -us -uc
[16:56] <dholbach> (which will not sign the package)
[16:56] <dholbach> The build will take a while, but afterwards you can run "ls ~/pbuilder/raring_result/"
[16:57] <dholbach> and you will see some shiny .deb packages - probably the first ones you ever built :-D
[16:57] <dholbach> and hopefully not the last!
[16:57] <dholbach> All right, we have 2 minutes left until the next session, so I want to get some final words out before the next session starts.
[16:57] <dholbach> We have documentation, and it's available at  http://developer.ubuntu.com/packaging/
[16:58] <dholbach> currently it's available in English and Spanish
[16:58] <dholbach> if you want to help get it translated to other languages, you'd have my eternal gratitude - you can do it here: https://translations.launchpad.net/ubuntu-packaging-guide/
[16:59] <dholbach> Also: you CAN help out with Ubuntu development. You're not alone. You can ask all your questions in #ubuntu-motu on irc.freenode.net - we need people like you and if you're only a bit of a social animal, I promise you'll find lots of friends here.
[16:59] <dholbach> Please bookmark http://developer.ubuntu.com/packaging/
[16:59] <dholbach> And enjoy the rest of the week - you all are awesome. Thanks for the session and I hope to see more of you in the next time!
[17:00] <coolbhavi> thanks dholbach :)
[17:00] <dholbach> Next up is coolbhavi with "Introduction to patch systems".
[17:00] <coolbhavi> yup :-)
[17:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html following the conclusion of the session.
[17:00] <coolbhavi> Hi All and welcome to my session on introduction to patch systems and why are patch systems used in general
[17:01] <coolbhavi> Here is a short intro on me: I am Bhavani Shankar a Ubuntu developer, currently serving on the Application Review Board and LoCo council in Ubuntu
[17:01] <coolbhavi> So lets get started:
[17:02] <coolbhavi> As a prerequisite, please ensure that you have installed packaging-dev package (so that it should pull in quilt) which is the most popular version of patch system used right now
[17:02] <coolbhavi> == What is a patch? [17:02] <coolbhavi> Patch in its simplest form means a code change introduced in the program to fix an existing bug in general
[17:03] <coolbhavi> == Why to use patch systems at the first place? ==
[17:03] <coolbhavi> imply put we use patch systems to generate and apply code changes without having to actually change the original code everytime making it look complicated to track changes/making the code look clumsy
[17:03] <coolbhavi> == Ok, now we know the general idea of what a patch means but what are the different systems present in ubuntu/debian? ==
[17:04] <coolbhavi> There are/were different patch systems present in ubuntu/debian namely:
[17:04] <coolbhavi> dpatch which had patches defined in a path called debian/patches/00list with extension .dpatch which is deprecated now
[17:05] <coolbhavi> cdbs simple patchsys which allowed to generate a diff which was stored in debian/patches path with a .diff extension and is deprecated now
[17:05] <coolbhavi> The most current and widely used system is the quilt patch system which allows you to add a patch in debian/patches/series path and apply it on the source code
[17:05] <coolbhavi> Any questions?
[17:06] <coolbhavi> So lets move on:
[17:07] <coolbhavi> == What is quilt patch system in general? ==
[17:07] <coolbhavi> With quilt, all work occurs within a single directory tree. Since version 0.30, commands can be invoked from anywhere within the source tree (the directory tree is scanned upwards until either the .pc or the patches directory is found).
[17:08] <ClassBot> Niraj_ asked: Why does ubuntu use different patch system than linux, which uses git diff?
[17:10] <coolbhavi> Niraj_, diff is also a generic patch system which is used in almost all linux systems. The newer patch systems are used in ubuntu and debian primarily to their ease of usage which I am going to show now
[17:11] <ClassBot> kix_ asked: using diff is a problem in general?
[17:12] <coolbhavi> Kix_, not so but while doing diffing on a large chunk of code you need to be pretty sure of what changes you are introducing
[17:12] <coolbhavi> so moving on
[17:13] <coolbhavi> Quilt manages a stack of patches. Patches are applied incrementally on top of the base tree plus all preceding patches. They can be pushed on top of the stack (quilt push), and popped off the stack (quilt pop). Commands are available for querying the contents of the series file
[17:13] <coolbhavi> The order of patches to apply is kept in debian/patches/series as said earlier.
[17:14] <coolbhavi> more information is available in /usr/share/doc/quilt/quilt.pdf which is available when quilt is installed.
[17:14] <coolbhavi> == How does quilt work? ==
[17:15] <coolbhavi> Before working with Quilt you need to tell it where to find the patches. Add this to your ~/.bashrc: export QUILT_PATCHES=debian/patches
[17:15] <ClassBot> phoenix_firebrd asked: can the series file be edited manually ?
[17:17] <coolbhavi> phoenix_firebrd, yes if you comment out any patch in series file for example, the patch will not be applied when you build the package
[17:17] <coolbhavi> And source the file to apply the new export:
[17:17] <coolbhavi> $ . ~/.bashrc
[17:18] <coolbhavi> By default all patches are applied already to UDD checkouts or downloaded packages. You can check this with:
[17:18] <coolbhavi> $ quilt applied
[17:18] <coolbhavi> Example: I have downloaded the package mobile-broadband-provider-info package using pull-lp-source from ubuntu-dev-tools and when I check I get
[17:18] <coolbhavi> bhavani@bhavani-spagetti-monster:~/mobile/mobile-broadband-provider-info-20130121$ quilt applied
[17:18] <coolbhavi> update_3_UK_secondary_dns.patch
[17:19] <coolbhavi> If you wanted to remove the patch you would run pop:
[17:19] <coolbhavi> $ quilt pop
[17:19] <coolbhavi> in my example:
[17:19] <coolbhavi> $ quilt pop
[17:19] <coolbhavi> Removing patch update_3_UK_secondary_dns.patch
[17:19] <coolbhavi> Restoring serviceproviders.xml
[17:19] <coolbhavi> No patches applied
[17:20] <coolbhavi> And to apply a patch you use push:
[17:20] <coolbhavi> $ quilt push
[17:20] <coolbhavi> Applying patch update_3_UK_secondary_dns.patch
[17:20] <coolbhavi> patching file serviceproviders.xml
[17:20] <coolbhavi> Now at patch update_3_UK_secondary_dns.patch
[17:21] <coolbhavi> And to add a patch one would typically use:
[17:21] <coolbhavi> quilt new
[17:21] <coolbhavi> quilt new serviceproviders.patch
[17:21] <coolbhavi> Patch serviceproviders.patch is now on top
[17:21] <coolbhavi> quilt add serviceproviders.xml
[17:21] <coolbhavi> File serviceproviders.xml added to patch serviceproviders.patch
[17:22] <coolbhavi> And then do required changes (for example work on a bug) and then use quilt refresh on the patch.
[17:22] <coolbhavi> Note that quilt add step is important otherwise you might not end up adding the patch in quilt
[17:23] <coolbhavi> == Seems complex. Is there any way that simplifies this process in ubuntu? ==
[17:24] <ClassBot> phoenix_firebrd asked: quilt add <file> is like quilt edit <file>
[17:25] <coolbhavi> phoenix_firebrd, yes basically you add the file first to the stack and edit it then to make up your desired patch
[17:26] <coolbhavi> so moving on:
[17:27] <coolbhavi> Yes there is a way to simplify the process. You can use the edit-patch command in ubuntu to effectively do the same
[17:27] <coolbhavi> $ edit-patch 99-new-patch
[17:27] <coolbhavi> This will copy the packaging to a temporary directory. You can now edit files with a text editor or apply patches from
[17:27] <coolbhavi> upstream, for example:
[17:28] <coolbhavi> $ patch -p1 < ../bugfix.patch
[17:28] <coolbhavi> After editing the file type exit or press control-d to quit the temporary shell. The new patch will have been
[17:28] <coolbhavi> added into debian/patches.
[17:29] <ClassBot> EagleScreen asked: Should quilt only be used to edit upstream sources? or should we use it also for doing changes in the debian packaging specfic files inside /debian directory?
[17:31] <coolbhavi> EagleScreen, normally changes inside the debian directory will be treated as native to the package so not required and patch systems are always used for integrating upstream changes
[17:31] <ClassBot> jincreator asked: Unlike git, should "quilt add <patch>" must before change file?
[17:33] <coolbhavi> jincreator, yes as I said earlier its a nice practice to do so as you wont have a chance to miss adding up the patch when you are working with multiple patches especially
[17:34] <coolbhavi> moving on again:
[17:34] <coolbhavi> As an example of edit-patch on my system:
[17:35] <coolbhavi> bhavani@bhavani-spagetti-monster:~/mobile/mobile-broadband-provider-info-20130121$ edit-patch bhavi.patch
[17:35] <coolbhavi> Normalizing patch path to bhavi.patch
[17:35] <coolbhavi> Normalizing patch name to bhavi.patch
[17:35] <coolbhavi> Top patch: update_3_UK_secondary_dns.patch
[17:35] <coolbhavi> File series fully applied, ends at patch update_3_UK_secondary_dns.patch
[17:35] <coolbhavi> Patch bhavi.patch is now on top
[17:35] <coolbhavi> bhavani@bhavani-spagetti-monster:/tmp/quilt-jC7JBQ$
[17:35] <coolbhavi> As you can see it gives a temperory shell where you can make any changes required to the source and when you exit a new patch will be created by the name bhavi.patch
[17:36] <coolbhavi> == Making a package use quilt ==
[17:36] <coolbhavi> Modern packages use Quilt by default, it is built into the packaging format. Check in debian/source/format to ensure it says 3.0 (quilt).
[17:37] <coolbhavi> Older packages using source format 1.0 will need to explicitly use Quilt, usually by including a makefile into debian/rules. (ex: passing include /usr/share/quilt/quilt.make)
[17:38] <coolbhavi> == Few Notes to take care while generating a patch ==
[17:39] <coolbhavi> Do not change a package’s patch system without discussing it with the Debian maintainer or relevant Ubuntu team. If there is no existing patch system then feel free to add Quilt.
[17:39] <coolbhavi> Do not make any changes to the package such that it can break something. When in doubt, please consult the upstream maintainer
[17:41] <coolbhavi> Its always beneficial to add patch tags or headers so that the main intention of the patch can easily be understood. (For patch tagging guidelines used in ubuntu please refer: http://dep.debian.net/deps/dep3/)
[17:41] <coolbhavi> == Further references ==
[17:42] <coolbhavi> The ubuntu packaging guide (developer.ubuntu.com/packaging) is always a great start towards learning the concepts of ubuntu development.
[17:42] <coolbhavi> Still 15 minutes left
[17:42] <coolbhavi> any questions?
[17:43] <ClassBot> johnhamelink asked: when do you decide "this isn't for upstream, this is a patch"?
[17:45] <coolbhavi> johnhamelink, good question :-) A simple answer would be when a particular bug/problem affects only the os you are using and other environments does'nt show such behaviour
[17:46] <ClassBot> phoenix_firebrd asked: how do you refresh a old patch using quilt?
[17:49] <coolbhavi> phoenix_firebrd, the simplest way I do that is first try to apply the patch and if it fails I would edit the patch and refresh it or just remove it if its not applicable to the present upstream version
[17:49] <ClassBot> nnutter asked: Have you ever used git-buildpackage or similar? Is it worth using that over plain quilt or edit-patch?
[17:50] <ClassBot> There are 10 minutes remaining in the current session.
[17:52] <coolbhavi> nnutter, yes personally I use git when I am committing upstream or pulling for my packages and it certainly helps. but I use quilt on ubuntu/debian for its simplicity
[17:52] <ClassBot> jincreator asked: Is bzr plugin for edit-patch(quilt) exists?
[17:54] <coolbhavi> jincreator, yes basically I would do a edit-patch generate the patch and do a bzr add <patch name> for adding my patch to my bzr trunk
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
[17:59] <coolbhavi> Thats it from me provided there are no more questions coming. Thanks for turning up and see you tomorrow for a session on ubuntu app review board :) good night! :)
[18:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html following the conclusion of the session.
[18:01] <tumbleweed> Hello Ubuntu Developer Week!
[18:01] <tumbleweed> I've just got back from supper, I guess it's time to start
[18:01] <tumbleweed> Hope you are enjoying yourselves
[18:01] <tumbleweed> Who is new here? Who has been involved in Ubuntu for a while, and is here to learn something new?
[18:01] <tumbleweed> Please say hi in the chat channel - #ubuntu-classroom-chat
[18:01] <tumbleweed> that is also the place to ask questions
[18:02] <tumbleweed> please start them with QUESTION: so the bot can pick them up
[18:02] <tumbleweed> If you have any questions with any of this, when you go home and do this, afterwards
[18:02] <tumbleweed> I suggest sticking your nose into #ubuntu-motu and asking there
[18:02] <tumbleweed> ok, we have an audience \o/
[18:03] <tumbleweed> so, I'm Stefano Rivera, an Ubuntu Developer and a Debian Developer
[18:03] <tumbleweed> I'm in sunny Cape Town, South Africa
[18:03] <tumbleweed> and I'm here to talk about dealing with upstreams
[18:03]  * tumbleweed sees a few familiar faces in the chat channel, and a good number of new ones
[18:04] <tumbleweed> What do I mean by an upstream?
[18:04] <tumbleweed> well, Ubuntu is made up of ~20 000 source packages, (which build ~40 000 binary packages)
[18:04] <tumbleweed> we Ubuntu Developers don't write all of those ourselves. We only authored a tiny handful of them
[18:04] <tumbleweed> everything else came from other projects
[18:04] <tumbleweed> some of these are big projects like GNOME and KDE, which produce hundreds of packages
[18:04] <tumbleweed> most are tiny little projects with one, or maybe half a dozen active contributors
[18:04] <tumbleweed> these projects are our upstreams
[18:04] <tumbleweed> they release new versions of their software, and we package it, make a few tweaks to get it to work nicely with the rest of Ubuntu, and ship it to users
[18:05] <tumbleweed> then we are on the front-line of incoming bug reports, and have to forward the relevant ones back to the upstreams
[18:05] <tumbleweed> that's what a linux distribution is, really
[18:05] <tumbleweed> OK, I lied a bit there
[18:05] <tumbleweed> I assume you all know that Ubuntu is derived from Debian
[18:05] <tumbleweed> in fact, about 75% of packages in Universe are entirely unmodified from Debian
[18:06] <tumbleweed> that's a very good thing
[18:06] <tumbleweed> there's no need for those packages to be modified in Ubuntu
[18:06] <tumbleweed> the vast majority of bugs that we'd encounter in them are relevant to Debian, Ubuntu, and (if except for packaging bugs, the original upstream)
[18:06] <tumbleweed> We contribute a lot back to Debian (as much as possible)
[18:06] <tumbleweed> https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
[18:07] <tumbleweed> so, a lot of the work I do in Ubuntu
[18:07] <tumbleweed> is fixing problems we come across, but they aren't necessarily specific to Ubuntu
[18:08] <tumbleweed> and the best place to deal with the problem is as close to the source as possible
[18:08] <tumbleweed> that means the least duplication of effort, and shares the benefit as widely as possible
[18:08] <tumbleweed> if we submit a patch to the upstream developers, and they release a new release containing our bug fix, it benefits everyone:
[18:08] <tumbleweed> users of other linux distributions, cygwin and macports users, people who installed this package themselves from scratch, etc.
[18:08] <tumbleweed> I hope at this point, you are aware of some the advantages of working well with our upstreams
[18:08] <tumbleweed> (and that I might have written up some of this beforehand, for pasting) :P
[18:09] <tumbleweed> (actually, beforehand, for a previous Ubuntu Developer Week)
[18:09] <tumbleweed> but I've kind of got to the end of the introduction now
[18:09] <tumbleweed> let's go into some more specifics
[18:09] <tumbleweed> and hopefully get piles of questions
[18:10] <tumbleweed> who here has ever contributed a bug fix to an open source project?
[18:11] <tumbleweed> yay, people are doing useful things :)
[18:12] <tumbleweed> yeah, many big projects have complex processes
[18:12] <tumbleweed> and it can be hard to figure out where the information for new contributors is
[18:13] <tumbleweed> generally, it's best to start with the home page, and dig around for a bug tracker or documentation on contributing patches
[18:13] <tumbleweed> you all clearly can use IRC (you're here)
[18:13] <tumbleweed> so if a project has an IRC channel, that's often a good place to get advice on how to get things done
[18:15] <tumbleweed> most of the time, if you submit a useful patch, someone will figure out what to do with
[18:15] <tumbleweed> epikvision asks about mentors
[18:15] <tumbleweed> many larger projects have mentors programs
[18:15] <tumbleweed> Ubuntu doesn't (we had in the past, but they've dried up)
[18:16] <tumbleweed> Debian has the #debian-mentors IRC channel, and debian-mentors mailing lists
[18:16] <tumbleweed> but they aren't really a mentor finding system
[18:16] <tumbleweed> so much as a place that new people can get help from experienced people
[18:17] <tumbleweed> most of the time, if you get involved with a project, you'll slowly build a relationship with the existing contributors
[18:17] <tumbleweed> and often one or more of them will act as mentors
[18:17] <tumbleweed> Please preifx questions with QUESTION: it makes it easier for me to respond to them
[18:18] <tumbleweed> yes, debian-mentors is more about package sponsorship than long term mentoring
[18:18] <tumbleweed> 20:18 < CodeRed> question : so how to get a proper guidance ?
[18:18] <tumbleweed> that depends on the project
[18:18] <tumbleweed> if we are talking about Ubuntu
[18:19] <tumbleweed> the best place to get guidance is in our public IRC channels
[18:19] <tumbleweed> #ubuntu-motu and #ubuntu-devel are both great places to get help in working on Ubuntu
[18:20] <tumbleweed> there's also a #ubuntu-packaging channel, that's more about general packaging, esp. in PPAs
[18:20] <tumbleweed> one of the problems with one-on-one mentorship is that it can be very draining on the mentor
[18:20] <ClassBot> There are 10 minutes remaining in the current session.
[18:20] <tumbleweed> who are often busy people
[18:21] <tumbleweed> so, I'd say it makes a lot of sense to get help in a public channel, where more than one person can help you
[18:21] <tumbleweed> (whoever is available, basically)
[18:21] <ClassBot> everestt asked: package sponsorship? what is that?
[18:21] <tumbleweed> right, good question
[18:21] <tumbleweed> you probably can't understand a thing I'm saying if you aren't already familiar with the Debian and Ubuntu processes :P
[18:21] <tumbleweed> so, let me clarify
[18:22] <tumbleweed> the way we work with new contributors in Debian and Ubuntu is through sponsored uploads
[18:22] <tumbleweed> our existing developers who have upload privileges can  upload packages for new contributors
[18:22] <tumbleweed> so, if you want to fix a bug in an Ubuntu package
[18:23] <tumbleweed> you apply the patch on the source package, prepare an upload, and ask an Ubuntu developer to upload it
[18:23] <tumbleweed> the recommended wayt o ask, is to put it on the sponsorship queue
[18:23] <tumbleweed> https://wiki.ubuntu.com/SponsorshipProcess
[18:23] <tumbleweed> and of course (I was here to talk about upstreams, right) you submit the patch to relevent the upstream developers
[18:24] <tumbleweed> did that clarify?
[18:24] <tumbleweed> great
[18:25] <ClassBot> There are 5 minutes remaining in the current session.
[18:25] <tumbleweed> while I'm here, I guess I might as well suggest good things to work on in Ubuntu
[18:26] <tumbleweed> I recommend starting with easy patches, to learn the procedures (Ubuntu is a big and complex project)
[18:27] <tumbleweed> harvest.ubuntu.com lets you find easy bugs (if you poke around it a bit)
[18:27] <ClassBot> CodeRed asked: like i tried ubuntu-app-devel but couldn't find a way to start
[18:27] <tumbleweed> CodeRed: I'm afraid I can't really cover that now. app development is too big a t opic for 3 mins
[18:28] <ClassBot> bobweaver asked: say you found some code that no one has toched in a yeah or so.  you sent email to upstreamer and have waited 3 months. when is it ok to take the project over. if it is at all
[18:28] <tumbleweed> bobweaver: that's a tough question
[18:28] <tumbleweed> if a project has died, then taking it over can be a useful thing to do
[18:29] <tumbleweed> if the project is useful to you, and you're prepared to toake it over, then you are doing everyone ag reat service
[18:29] <tumbleweed> I suggest talking to the upstream about that, though
[18:29] <tumbleweed> it's worth avoiding forking the project if possible
[18:30] <tumbleweed> but yes, porjects do die
[18:30] <tumbleweed> I'm afraid I'm out of time, notgary has the stage now
[18:30] <JoseeAntonioR> Guys, next session is at www.ubuntuonair.com , so just go and click the play button :)
[18:30] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html following the conclusion of the session.
[18:50] <ClassBot> There are 10 minutes remaining in the current session.
[18:55] <ClassBot> There are 5 minutes remaining in the current session.
[18:59] <mhall119> JoseeAntonioR: are you going to let everyone at ubuntuonair know that the next session is back in IRC?
[19:00] <JoseeAntonioR> mhall119: yes
[19:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html following the conclusion of the session.
[19:01] <mhall119> hello everybody
[19:01] <mhall119> I'm Michael Hall, one of the community managers for Canonical
[19:01] <mhall119> has everyone been enjoying Ubuntu Developer Week so far?
[19:02] <mhall119> in this session I'm going to give an overview of all the tools that are available to Ubuntu developers
[19:03] <mhall119> if you have questions at any point, please ask them in the -chat channel, starting with QUESTION: and I will break periodically to answer them
[19:03] <mhall119> if there is anything you want me to talk about, please ask about that too
[19:03] <mhall119> and if there is time I'll get to it
[19:04] <mhall119> alright, to get things started, if you've been following other sessions today I'm sure you've heard about Launchpad
[19:04] <mhall119> Launcpad is an open source project hosting service developed and provided by Canonical
[19:05] <mhall119> it's similar in a lot of ways to github or sourceforge, with some key differences that make it ideal for Ubuntu related development
[19:05] <mhall119> like those other solutions, Launchpad is organized around Projects
[19:05] <mhall119> if your Project is open source, you can use Launchpad free of charge
[19:05] <mhall119> you can also optionally host proprietary code projects on Launchpad if you purchase a subscription
[19:06] <mhall119> you don't really get anything extra by paying, it just lets you keep your proprietary code private
[19:07] <mhall119> Launchpad also supports Teams, and pretty much anywhere you can set a person you can also set a team, so a team can be the owner of a project, which gives everybody in that team access to the project
[19:07] <mhall119> project ownership lets you manage the project's settings and information, bug priority and so on
[19:08] <mhall119> team ownership is a good idea because it means that even if you're away on holiday, somebody else can take care of anything that needs t obe done
[19:08] <mhall119> Teams in Launchpad come in 4 levels of membership control:
[19:09] <mhall119> Open Teams: These anybody with a Launchpad account can join
[19:09] <mhall119> Moderated Teams: Anyboty with a Launchpad account can request to join, but an admin on that team must approve it
[19:10] <mhall119> Delegated Teams: These are kind of a hybrid, the require admin approval for direct access, like Moderated Teams, but they can also have other teams as members without managing the membership of those other teams
[19:11] <mhall119> finally, Restricted Teams: These you can only get membership by being invited by an admin, you can't request to join them
[19:12] <ClassBot> amin_ asked: I'm a newbie in developing apps under linux, specifically under Ubuntu. I couldn't find too much useful stuff on "quickly". So my question is what are some extensive and complete documentations and references for quickly (especially glade and connecting ui to source)
[19:12] <mhall119> there are tutorials for using quickly on our developer portal (developer.ubuntu.com) which I will talk about more soon
[19:12] <ClassBot> JumpLink916061 asked: Is launchpad itself also open source?
[19:12] <mhall119> Yes, Launchpad was open sourced years ago
[19:13] <mhall119> and, of course, it uses itself for project hosting: https://launchpad.net/launchpad :)
[19:13] <mhall119> Launchpad also gives you a bug tracker, like bugzilla, for each project
[19:14] <mhall119> bugs can also be given custom tags that you define for your own project, that lets you easily categorize them
[19:15] <mhall119> a common tag is "bitesize", which indicates that it is a small or easy fix, ideal for new contributors who want to get their feet wet
[19:16] <mhall119> this has been widely adopted across projects on Launchpad, so if you want to start contributing to something, look for those bugs
[19:16] <mhall119> next, one of Launchpad's most important features is tracking Bazaar branches
[19:17] <mhall119> Launchpad and Bazaar go hand-in-hand, which shouldn't be surprising because they were both developed at the same time for the same target audience
[19:17] <mhall119> Launchpad itself is a remote Bazaar repository that you can push to
[19:18] <mhall119> branches in Launchpad can be owned by either an individual or a team
[19:18] <mhall119> and a Project typically has one branch that is it's "Development Focus"
[19:18] <mhall119> this branch is typically owned by the team that owns the project, meaning you have to be on the team to push to it
[19:19] <mhall119> however, anybody can push a branch to that project's namespace, and then propose for it to be merged into the development focus
[19:19] <mhall119> which takes us to the next big feature on LP: Merge Propsals
[19:19] <mhall119> if you are a github user, these are like pull requests
[19:20] <mhall119> since only the owning team can land changes in the development focus ("trunk" usually), everybody else sends a merge proposal that must be reviewed and accepted by that team
[19:20] <mhall119> and Launchpad tracks all of this, you can keep tabs on the state of the request and the back-and-forth conversations all on Launchpad
[19:21] <mhall119> finally, and rather unique to Launchpad, are PPAs, or Personal Package Archives
[19:22] <mhall119> PPAs are a mini-repository for debian packages, they look to Apt and Ubuntu Software Center exactly like the main repositories, only they are owned by an individual or a team
[19:22] <mhall119> PPAs are a great way to provide packages of your code or application to users, and keep those users up to date
[19:23] <mhall119> it's often used for pre-release versions of code that will eventually make it's way into the main archives
[19:24] <mhall119> any questions about Launchpad before I move on?
[19:24] <mhall119> Launchpad user profiles and team membership is also used on many other Ubuntu related websites, so if you plan on doing much of anything in the Ubuntu ecosystem, you're going to want to sign up
[19:25] <mhall119> alrighty, moving on
[19:25] <mhall119> As I said earlier, Launchpad and Bzr go hand-in-hand
[19:26] <mhall119> Bzr is the primary version control system used in Ubuntu development
[19:26] <mhall119> it's similar in many ways to git or mercurial, because they all got started at about the same time, and borrowed many ideas from eachother
[19:27] <mhall119> Bzr is very branch-focused, instead of "cloning" a remote repository, you branch it
[19:27] <mhall119> also, unlike git and mercurial, bzr typically has separate directories for separate branches
[19:28] <mhall119> these are commonly referred to as feature branches, because you create one for each feature or bug fix you are going to work on
[19:28] <mhall119> so, for example, to get the code for Launchpad, you would run "bzr branch lp:launchpad ./my-launchpad-branch"
[19:29] <mhall119> (don't do this right now, it's huge)
[19:30] <mhall119> bzr can work over many different transport layers, HTTP is common, but it will also work over FTP, SSH and others
[19:30] <mhall119> you'll also see some common aliases, like lp: and ubuntu:
[19:30] <mhall119> lp: is short-hand for the development focus of a project, so lp:launchpad means the development focus branch (or trunk) for the "launchpad" project
[19:31] <mhall119> lp:quicky for the quickly project, and so on
[19:31] <mhall119> ubuntu: is short-hand for the package branch used to create the debian package in Ubuntu's archives
[19:32] <mhall119> this is used more for those participating in ubuntu's distributed development, not by the original project's developers, who will typically use the lp: prefix
[19:33] <mhall119> now, if you run "bzr branch lp:launchpad ./my-launchpad-branch", you will get both the branch history and a local checkout in ./my-launchpad-branch/
[19:33] <mhall119> but bzr also lets you have a checkout separate from the branch history
[19:34] <mhall119> so you can run "bzr checkout ./my-launchpad-branch/ ./my-launchpad-work/" and you'll have a checkout of the tip in your -work directory, but the rest of the branch history says in -branch
[19:34] <mhall119> and, in fact, you can switch your checkout directory between branches
[19:35] <mhall119> so you can "bzr branch ./my-launchpad-branch/ ./fixing-feature-x" to make a new feature branch
[19:35] <mhall119> then, in your -work checkout directory, run "bzr switch ../fixing-feature-x" to retarget it
[19:36] <mhall119> this lets you mimick git or mercurial branch switching workflows with the same local checkout
[19:36] <mhall119> bzr also lets you assing bug-fix metadata to your commits, so if you are working on Launchpad bug#12345, you can run "bzr commit --fixes lp:12345" and it will store that in the branch history
[19:37] <mhall119> later, when you push your branch to Launchpad, it will automatically associate your new branch with that bug number, so people viewing the bug can see it
[19:37] <mhall119> this also lets Launchpad update the bug if your branch is merged into the development focus branch
[19:38] <mhall119> I said earlier that anybody can submit a branch to a Launchpad project
[19:38] <mhall119> to do this, you simply push your branch to a specific lp: url
[19:38] <mhall119> the format is lp:~<your_lp_name>/<target_project_name>/<unique_branch_name>
[19:39] <mhall119> so for me, it might look something like this:
[19:39] <mhall119> bzr push lp:~mhall119/quickly/fix-bug-12345
[19:39] <mhall119> if you want to push some personal code to Launchpad, but don't have a project, you can substitute the project part with "+junk"
[19:40] <mhall119> so bzr push lp:~mhall119/+junk/my-cool-code
[19:40] <mhall119> everybody on Launchpad has this +junk space for code that doesn't belong to a project
[19:40] <mhall119> any questions about bzr and/or launchpad?
[19:41] <ClassBot> epikvision asked: Can you explain what a "checkout" is?
[19:41] <mhall119> a "checkout" is a copy of the code at a specific version (typically the head of the branch), that is separate from the branch history
[19:41] <mhall119> basically, the branch metadata nd history is all stored in the /.bzr/ directory at the root of the branch
[19:42] <mhall119> the files you see in that directory are the checkout
[19:42] <mhall119> they usually go together, but you can separate them too
[19:43] <mhall119> so, for example, when I work on a Django project, I create a checkout into a directory called "work", where I build my virtualenv and keep my database files
[19:43] <mhall119> but then I can switch the code in that directory between my trunk and feature branches
[19:43] <mhall119> so I can switch between working on feature-x and feature-y, without having to make separate virtualenvs for each
[19:44] <mhall119> alright, next I wanted to talk about the developer portal
[19:44] <mhall119> http://developer.ubuntu.com
[19:44] <mhall119> this is the primary resource for information about writing apps that target Ubuntu
[19:45] <mhall119> here you can find documentation on how to integrate with Unity, Ubuntu One, and other Ubuntu-specific features
[19:45] <mhall119> you can also browse API documentation for the same
[19:46] <mhall119> with the announcement of the Ubuntu Phone, we also posted on the developer portal how to get the new SDK preview and a tutorial on writing apps for the phone
[19:46] <mhall119> and if you want to submit an independent application to the Ubuntu Software Center, you can do that through the MyApps section
[19:47] <mhall119> there is also a blog component to the site, which you can follow for updates on our developer offerings
[19:48] <mhall119> our tutorials are mostly provided by members of the community, so if you have something you think would be useful to others, please let me know and I'll get it added to the site
[19:48] <mhall119> I'm running short on time, so I'll skip right ahead to Quickly
[19:48] <mhall119> Quickly is local project management tool that makes is incredibly easy to start writing an application for Ubuntu
[19:49] <mhall119> it provides a number of commands that cover the entire development life-cycle
[19:49] <mhall119> to get started, you simple run "quickly create <template> <new_app_name>" and it will bootstrap everything for you
[19:50] <mhall119> not only does it provide a code template, but it also starts you with a bzr branch
[19:50] <mhall119> the most common template is currently "ubuntu-application", which is a python2/gtk3 codebase
[19:50] <ClassBot> There are 10 minutes remaining in the current session.
[19:50] <mhall119> while python and gtk are the most widely used, Quickly itself supports templates for any language and toolkit
[19:51] <mhall119> quickly also provides commands for packaging your code, pushing it to launchpad and even uploading it to a PPA, all with a few simple commands
[19:52] <mhall119> there is a video walk-through on http://developer.ubuntu.com/get-started/ that shows the process of using Quickly to create an application
[19:52] <mhall119> and more documentation can be found at https://wiki.ubuntu.com/Quickly
[19:53] <mhall119> alright, 7 minutes left, any questions before I move on?
[19:54] <mhall119> I'm going to very, very quickly list some other resources available to Ubuntu developers
[19:54] <mhall119> The Wiki (http://wiki.ubuntu.com) can be edited by anybody, and contains a massive amount of information about all aspects of Ubuntu and the Ubuntu Community
[19:55] <mhall119> Etherpad (http://pad.ubuntu.com) is also available to anybody to use
[19:55] <mhall119> you need to have a Launchpad account, and also become a member of ~ubuntu-etherpad to get access though
[19:55] <ClassBot> There are 5 minutes remaining in the current session.
[19:55] <mhall119> this was for spam-prevention
[19:55] <mhall119> etherpad is fantastic for remote pair-programming or collaborative debugging
[19:56] <mhall119> it's also used extensively during the Ubuntu Developer Summit to track discussions
[19:56] <mhall119> Pastebin (paste.ubuntu.com) is available if you need to paste text for others to see
[19:57] <mhall119> stgraber has also written a very handy tool called pastebinit which lets you quickly and easily paste files from the command line, or even pipe output from a process directly into it
[19:57] <mhall119> Ubuntu One (http://one.ubuntu.com), it isn't just for personal file storage, you can also get a sharable URL for any file you upload
[19:58] <mhall119> this is handy for sharing screenshots, data files, or whatever else you want
[19:58] <mhall119> AskUbuntu (http://askubuntu.com) is  StackExchange site that is heavily used, you can ask your questions there or help answer others
[19:58] <mhall119> Mailman (http://lists.ubuntu.com) we have many, many mailing lists
[19:59] <mhall119> for ubuntu development, you might want to subscribe to ubuntu-devel and ubuntu-motu
[20:00] <mhall119> LoCo Teams (http://loco.ubuntu.com) while primarily a community thing, it's always fun to hack on code with friends, especially local ones
[20:00] <mhall119> we also have a twice-annual Global Jam, where we encourage people to meet up with Ubuntu users around them and contribute together
[20:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2013/01/29/%23ubuntu-classroom.html
[20:00] <mhall119> Forums (http://forums.ubuntu.com), one of our oldest resources, there is a lot of built-up information there
[20:01] <mhall119> Design (http://design.ubuntu.com) is a newer side, dedicated to providing visual and UX information
[20:01] <mhall119> and of course IRC, besides this classroom channel, we also have #ubuntu-devel, #ubuntu-app-devel, #ubuntu-unity, #ubuntu-phone, and on and on
[20:02] <mhall119> you can run "/msg alis list #ubuntu*" for an extensive list of ubuntu channels
[20:02] <mhall119> and with that I'm one
[20:03] <JoseeAntonioR> Thanks for being here today, we'll have more sessions tomorrow, starting at 15 UTC! See you there!
[20:03] <mhall119> if anybody has any other questions, feel free to ping me on irc, or email me: mhall119 @ubuntu.com
[20:28] <jderose> exit
[20:28] <jderose> hehe, wrong window :P