[04:32] can anyone tell me if I can set this up to log the classes tomorrow? [04:34] Gillfish: you're all set for tomorrow :) [04:35] Gillfish: logs will be available after the sessions [04:35] thanks. I have to attend this for A college class [04:35] no worries === Solumus is now known as SolLog === SolLog is now known as SolLogger === SolLogger is now known as Solbot === Solbot is now known as dustubot [08:12] hello === Emil is now known as Guest11244 === Guest11244 is now known as emil- [09:51] is it started? === maverick is now known as Guest89749 === me is now known as Guest75390 [12:46] Hi all..? [13:00] hello [13:01] djones_, this is Official Channel , If you want help please do at #ubuntu [13:02] no dont need help just saying hello waiting for the discussions to start [13:03] please join at #ubuntu-classroom-chat [13:50] Does this channel will host the Ubuntu Developer week today's session? [13:53] yes [13:53] xkernel, [14:23] About an half hour remaining :) [14:23] *a [14:26] still waiting! [14:26] Hey there friends... [14:26] Just to be clear, join #ubuntu-classroom-chat for the regular smalltalk :P [14:36] j/ #ubuntu-classroom-chat === rose is now known as Guest94908 [14:48] s [14:50] 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] what's coming up on the schedule? [14:52] quequotion, https://wiki.ubuntu.com/UbuntuDeveloperWeek/ :) [14:52] dholbach: hi [14:53] * quequotion runs date -u [14:54] 6min and counting :) [14:55] oh.... Unity's not for another 4 hours... too bad I have work early tomorrow morning.... [14:55] * mohamedalaa98 is waiting [14:55] quequotion: we'll have logs of everything [14:55] QUESTION: Will there be logs of the session cause i toohave to work :) [14:56] logs aren't as good as partcicipation :( [14:57] 2mins [14:57] 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] dholbach, true, but I hope i'll find as effective an opportunity to give my opinions as well. [15:00] WELCOME EVERYBODY TO A GREAT UBUNTU DEVELOPER WEEK! :-) === 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 Development - Instructors: dholbach [15:01] 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] 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] First a few organisational bits and pieces: [15:01] - There will be logs after the sessions. We will link them from the timetable on https://wiki.ubuntu.com/UbuntuDeveloperWeek/ [15:02] - If you have questions, please do ask! But please ask in #ubuntu-classroom-chat - if you're not there, please join now. [15:02] - When you ask questions, please prefix them with QUESTION: - ie: QUESTION: What is jcastro's favourite electronic music artist? [15:02] This way the questions will stand out and the bot can pick them up easily. [15:03] All right - with that... let's get started. :-) [15:04] 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] We'll have two hours to get you introduced to Ubuntu Development and get your development environment set up. [15:05] 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] 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] jierro asked: What is jcastro's favourite electronic music artist? [15:06] It's deadmau5 or however the mau5 is spelled and he mentions him at least once a day to me. :-) [15:06] Let's see if we get more Ubuntu development related questions though next. ;-) [15:07] 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] 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] 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] 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] tuxfan_ asked: will this session have to do with quickly and python specifically? [15:09] 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] 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] jincreator asked: Due to some problems, currently my environment is precise. Is it can be problem to follow sessions? [15:10] jincreator, yes, should be fine - we'll get back to the question in about an hour :) [15:10] 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] 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] Any more questions so far? [15:11] Ok, cool - let's talk a bit more about how we put together releases then. [15:12] 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] 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] 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] 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] tuxfan_ asked: What do you mean by freeze date? [15:13] 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] 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] 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] maxi_ asked: freature freeze is is always the first freeze? [15:15] We have some deadlines before, like "Feature Definition Freeze" where the plans for the release need to be ironed out. [15:16] (More on the planning aspect in a bit.) [15:16] And "Debian Import Freeze" which means that we stop automatically importing changes from Debian. (More on that in a sec too.) [15:16] But yes, Feature Freeze, is the first big, notable, one. [15:16] 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] tuxfan_, yes. [15:17] This also determines what kind of things Ubuntu developers, volunteers and enthusiasts work on. [15:17] 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] mohamedalaa98 asked: what is the most important programming languages that should be learned to start development in ubuntu? [15:18] 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] 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] All right, since it came up earlier, let's talk a bit about feature planning. [15:20] 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] 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] 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] xkernel asked: If I want to develop a feature or solve a bug say in Unity, how do I test it? [15:22] 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] 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] johnhamelink, great question! :-) [15:22] We'll have some sessions on Automated Testing this week. [15:22] Tomorrow 18:00 UTC - Testing with autopilot -- balloons [15:23] Thursday 15:00 UTC - Automated Testing in Ubuntu -- pitti [15:23] 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. === Jim_Lahey is now known as bobweaver [15:24] 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] 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] 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] 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] 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] 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] These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it. [15:27] 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). [15:27] QUESTION : I'm a C/C++ developer new to ubuntu where shall I start with ? [15:28] 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] Lionthinker asked: are derivatives the only downstreams for Ubuntu? [15:29] 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] tuxfan_ asked: So you are saying that through Upstream 3rd party apps bugs are fixed by ubuntu team? [15:30] 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] everestt asked: What is a downstream? [15:31] everestt, Imagine software being written somewhere, then distributed by somebody else, then this is used by somebody else. [15:32] 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] dutchguy asked: Are you not afraid of beginner developers introducing bugs into a project? [15:33] dutchguy, We have a very good review process for new contributors, which I'll talk about in a bit. [15:33] 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] 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] 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] 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] 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] 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] 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] 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] Maybe with this example you can imagine how multiple teams can work in similar but different directions because of different timelines. [15:39] 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] 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] 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] tuxfan_ asked: But will ver1.1 be updated in the allready released ubuntu version? [15:41] 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] a rewrite of the font rendering (as in the example above) won't constitute a serious bug fix though :) [15:42] maxi_ asked: why sometimes near the release are added visual characteristics? [15:42] maxi_, sometimes teams are late and they get freeze exceptions from the release team :) [15:42] 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] 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] also many Ubuntu developers are actively involved in other projects (wear multiple hats) [15:43] 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] 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] a rewrite of the font rendering (as in the example above) won't constitute a serious bug fix though :)" [15:44] 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] Niraj_, see above [15:44] it's because every change we introduce in a stable release might break functionality for millions of users [15:45] we have to be very very conservative with stable releases [15:45] CodeRed asked: what skills are required for ubuntu kernel development ? [15:45] CodeRed, C skills will be necessary and https://wiki.ubuntu.com/KernelTeam might be a good start [15:45] 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] 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] if it's a small bug, we can forward it first and then get it from upstream in the next release [15:46] 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] already answered [15:46] 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] I think this kind of question is sufficiently answered now. [15:47] It's also quite relevant that maintaining several stable releases at the same time is a serious burden in terms of work. [15:47] 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] 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] nep1x asked: What does "backported" mean? [15:49] 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] tuxfan_ asked: Does conservative mean that non LTS releases are "equipped" mostly with non stable app versions? whilst LTS with stable ones? [15:50] tuxfan_, no [15:50] 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] There are 10 minutes remaining in the current session. [15:50] tuxfan_, we had "obvious one line fixes" which broke functionality for users or some of our users [15:50] jincreator asked: I heard about MicroReleaseException. What is required that package become on MRE? [15:51] jincreator, https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases [15:51] Lionthinker asked: how will a rolling release schedule change development? [15:51] 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] I'll quickly get back to the "Introduction to Ubuntu Development". :-) [15:52] So let's say we want to fix a bug in Ubuntu. [15:52] 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] 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] 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] After a while, when you've built a good track record of good contributions, you can apply for upload rights yourself. [15:53] This whole process is quite straight-forward. [15:54] jincreator asked: Why we need freeze for even translating? [15:54] jincreator, If strings in packages change very late, translators will have to re-do their translations. [15:54] 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] 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] There are 5 minutes remaining in the current session. [15:55] 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] Lionthinker asked: a developer with upload rights is a MOTU, right? [15:55] no, MOTUs are just one team with upload rights - more on that in a bit. [15:56] 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] Additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream. [15:56] 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] 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] jincreator asked: Why there is freeze that affect even translators? I mean, something like (non)languagetranslationdeadline. [15:59] 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] 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] See you in 2-3 mins. === 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 Started with Ubuntu Development - Instructors: dholbach [16:00] 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] All right my friends - we're back! [16:04] And we'll kick off "Getting set up for Ubuntu Development" in just a sec. [16:05] 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] To get every little bit set up, I'll refer you to some really nice documentation later on. [16:05] Hope that meets your agreement. :-) [16:06] First of all we'll install some packaging-related software. This includes: [16:06] - Ubuntu-specific packaging utilities [16:06] - Encryption software so your work can be verified as being done by you [16:06] - Additional encryption software so you can securely transfer files [16:07] 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] 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] 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] 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] $ sudo apt-get install packaging-dev [16:09] (without the $) [16:09] For users before Ubuntu 11.10 “Oneiric Ocelot”: [16:10] $ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file [16:10] tuxfan_ asked: Does that mean that we have to always have the latest Ubuntu installed (e.g on a VM)? [16:10] 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] Installing the packages is going to take a while, depending on your internet connection. So let's crack on. [16:11] nuragussuryoko asked: need to confirm, is "current development version of Ubuntu" == 13.04 ? [16:11] nuragussuryoko, yes. 13.04 aka raring ringtail :) [16:12] So what we're installing now is going to give us: [16:12] - gnupg – GNU Privacy Guard contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad. [16:12] - pbuilder – a tool to do reproducible builds of a package in a clean and isolated environment. [16:12] - ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier. [16:12] - bzr-builddeb (and bzr, a dependency) – distributed version control with Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each other’s work. [16:12] - apt-file provides an easy way to find the binary package that contains a given file. [16:13] Next we'll set up pbuilder. A very nice tool you're soon going to love. :-) [16:14] pbuilder allows you to build packages locally on your machine. It serves a couple of purposes: [16:14] - 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] - There is no need to install all necessary build dependencies locally [16:14] - You can set up multiple instances for various Ubuntu and Debian releases [16:14] Setting pbuilder up is very easy, simply run: [16:14] $ pbuilder-dist create [16:14] where 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] For now you might want to just run: [16:15] $ pbuilder-dist raring create [16:15] tuxfan_ asked: pbuilder works kinda like a sandbox?or didn't i get it right? [16:16] 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] 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] 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] 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] quequotion asked: Are the dependencies different for later releases (12.04+)? [16:19] quequotion, Yes, dependencies of packages change, just as the code changes over different releases. === nuraguss_ is now known as nuragussuryoko [16:19] epikvision asked: Can pbuilder serve as a temporary replacement for not running development release? [16:20] 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] Lionthinker asked: Whats a translation in coding speak? [16:21] Lionthinker, In gedit the first menu point says "File" when I try to click on it. That's "Datei" in German. :-) [16:21] quequotion asked: What about multilib packaging, and specifically amd64 with i386? [16:21] quequotion, Yeah what about it? :) [16:22] I guess you're referring to multiarch? I'm not sure what your question is about. [16:22] 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] retnan asked: Is it possible to do development on github and having changes updated on launchpad [16:23] 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] quequotion asked: sorry, by dependencies I meant the build environment dependencies; has anything changed since 11.10? [16:23] quequotion, yes, a lot - running a more recent Ubuntu in a VM will make development easier [16:24] 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] Next let's tell some of the development tools who we are. [16:25] Please open your ~/.bashrc in a text editor and add something like this to the bottom of it: [16:25] export DEBFULLNAME="Bob Dobbs" [16:25] export DEBEMAIL="subgenius@example.com" [16:25] If you do not use the default shell, which is bash, please edit the configuration file for that shell accordingly. [16:25] Now save the file and either restart your terminal or run: [16:26] $ source ~/.bashrc [16:26] Ok... did this work all work out for everyone? Any questions? Any catastrophes? [16:27] phoenix_firebrd asked: what is the difference in using pbuilder-dist and pbuilder [16:28] 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] with plain pbuilder you will have to edit a configuration file, etc [16:28] nuragussuryoko asked: sorry n00b one. I'm using 12.10 and was disconnected. Shall I follow-through, or install 13.04 first? [16:29] 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] phoenix_firebrd asked: what is the difference in using pbuilder-dist and pbuilder [16:29] ah yes, had that one already [16:29] epikvision asked: We only need to run pbuilder once? [16:29] epikvision, pbuilder-dist create [16:29] yes, just once [16:30] quequotion asked: do i need "export"? [16:30] quequotion, yes [16:30] 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] x86_, ls ~/pbuilder/ [16:30] anish1307i asked: can we use pbuilder to create package in running system and then test it on VM? [16:30] anish1307i, yes, you can simply copy them over [16:30] phoenix_firebrd asked: Is there a way to set the release to example raring or unreleased in bashrc [16:31] phoenix_firebrd, hum - do I assume correctly that you're talking about the default for the release name in debian/changelog entries? [16:32] 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] 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] sorry [16:35] nep1x asked: do we have to run pbuilder-dist right now? which release? can i get an environment different than the release I ve alredy installed? [16:36] nep1x, yes, that's possible - please run: "pbuilder-dist raring create" [16:36] all right, we have around 20 minutes left, so get's get to a quick example of Ubuntu development [16:36] in my tea break earlier, I deliberately broke a package :) [16:37] we are going to fix it now :) [16:37] I pushed my work to lp:~dholbach/ubuntu/raring/hello/crazy-change - to get the branch, simply run: [16:37] $ bzr branch lp:~dholbach/ubuntu/raring/hello/crazy-change [16:37] Now simply: [16:37] $ cd crazy-change [16:38] If you run "ls debian" now, you will set a list of files which are relevant to the packaging. [16:39] 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] Until somebody mentions it in #ubuntu-classroom-chat I'll talk a bit about what debian/control is all about. [16:40] 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] The second one is about the resulting binary package, so the .deb package you would install after a build. [16:40] install-infooooooooo [16:40] x86_ got it right. :-) [16:40] The broken line is this one: [16:40] Depends: ${shlibs:Depends}, dpkg (>= 1.15.4) | install-infoooooooooooooo [16:41] It specifies the dependencies of the "hello" package after a build. [16:41] "${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] This is determined automatically during the build. [16:42] If we built the package as it is right now, it'd mean that it would refer to a non-existing package. [16:42] Please go ahead and change "install-infoooooooooooooo" to "install-info". :-) [16:42] And save the file. [16:43] Next please run "dch -i". [16:43] 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] 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] 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] 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] that's very important, especially if you go back and try to figure why something was changed half a year ago [16:46] and you should try to have separate bullet points for separate things :-) [16:46] so for something as simple as fixing the dependency, we could write something like: [16:47] * debian/control: fixed dependency: changed "install-infoooooooooooooo" to "install-info". [16:47] Or something along those lines. [16:48] jincreator asked: Where can I find list of variables used in making debian file such as {shlibs:Depends} ? [16:50] {shlibs:Depends} is probably the most important one, especially if you deal with shared libraries and linked code. [16:50] There are 10 minutes remaining in the current session. [16:50] 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] johnhamelink asked: If there was a bug report, what would the debian/changelog look like? [16:51] johnhamelink, good question :) [16:51] So let's say there was Launchpad bug report 12345678 about the problem I created earlier. [16:51] In that case you'd simply add (LP: #12345678) to the end of the line [16:51] this would get the bug report automatically closed as soon as the fix lands in Ubuntu [16:52] So, to build the package, please run: [16:52] $ bzr bd -- -S [16:52] This will generate a source package from the branch (which is just a directory with the source code history in it). [16:53] The source package is a format we use to upload changes to Launchpad and build the binary packages from. [16:53] If you now run "ls ../hello_*", you will see these files listed: [16:54] ../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] They make up the source package. [16:54] 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] EagleScreen asked: as the same way you use (LP: #12345678), is there a expecific syntax to reference Debian bug reports? [16:55] Yes, it's "Closes: #123456" [16:55] maxi_ asked: debsign: gpg error occurred! Aborting.... debuild: fatal error at line 1278: running debsign failed bzr: ERROR: The build failed. [16:55] There are 5 minutes remaining in the current session. [16:56] 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] (which will not sign the package) [16:56] The build will take a while, but afterwards you can run "ls ~/pbuilder/raring_result/" [16:57] and you will see some shiny .deb packages - probably the first ones you ever built :-D [16:57] and hopefully not the last! [16:57] 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] We have documentation, and it's available at http://developer.ubuntu.com/packaging/ [16:58] currently it's available in English and Spanish [16:58] 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] 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] Please bookmark http://developer.ubuntu.com/packaging/ [16:59] 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] thanks dholbach :) [17:00] Next up is coolbhavi with "Introduction to patch systems". === 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 Patch Systems - Instructors: coolbhavi [17:00] yup :-) [17:00] 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] Hi All and welcome to my session on introduction to patch systems and why are patch systems used in general [17:01] 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] So lets get started: [17:02] 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] == What is a patch? === [17:02] Patch in its simplest form means a code change introduced in the program to fix an existing bug in general [17:03] == Why to use patch systems at the first place? == [17:03] 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] == Ok, now we know the general idea of what a patch means but what are the different systems present in ubuntu/debian? == [17:04] There are/were different patch systems present in ubuntu/debian namely: [17:04] dpatch which had patches defined in a path called debian/patches/00list with extension .dpatch which is deprecated now [17:05] 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] 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] Any questions? [17:06] So lets move on: [17:07] == What is quilt patch system in general? == [17:07] 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] Niraj_ asked: Why does ubuntu use different patch system than linux, which uses git diff? [17:10] 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] kix_ asked: using diff is a problem in general? [17:12] 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] so moving on [17:13] 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] The order of patches to apply is kept in debian/patches/series as said earlier. [17:14] more information is available in /usr/share/doc/quilt/quilt.pdf which is available when quilt is installed. [17:14] == How does quilt work? == [17:15] 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] phoenix_firebrd asked: can the series file be edited manually ? [17:17] 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] And source the file to apply the new export: [17:17] $ . ~/.bashrc [17:18] By default all patches are applied already to UDD checkouts or downloaded packages. You can check this with: [17:18] $ quilt applied === P is now known as Guest32652 [17:18] 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] bhavani@bhavani-spagetti-monster:~/mobile/mobile-broadband-provider-info-20130121$ quilt applied [17:18] update_3_UK_secondary_dns.patch [17:19] If you wanted to remove the patch you would run pop: [17:19] $ quilt pop [17:19] in my example: [17:19] $ quilt pop [17:19] Removing patch update_3_UK_secondary_dns.patch [17:19] Restoring serviceproviders.xml [17:19] No patches applied [17:20] And to apply a patch you use push: [17:20] $ quilt push [17:20] Applying patch update_3_UK_secondary_dns.patch [17:20] patching file serviceproviders.xml [17:20]