[00:08] hi there [00:15] checking === ysnoi is now known as TheYsNoi [00:36] exit [01:25] red green [01:25] green red [01:36] #ubuntu-irc [01:37] aah i am sorry command command problem ,really sorry [02:11] Anyone here mind helping me out with my hardware acceleration? I still can't get it working. Ubuntu 11.04, Intel HD 3000 and nVidia GeForce 520M, both controlled via Optimus. I've tried this https://github.com/Bumblebee-Project/Bumblebee/wiki/Troubleshooting and https://github.com/Bumblebee-Project/Bumblebee/wiki/Upgrading-on-Ubuntu , and after resetting numerous times I still have no luck. === dduffey is now known as dduffey_afk [03:55] lunch break.. === muthusuba_ is now known as muthusuba === AndrewMC is now known as SpockVulcan [04:59] installing hoN [05:00] What is BTW? [05:01] *this === liquid is now known as Guest24219 [05:39] by the way? === warp11 is now known as warp10 === Partyschaum^away is now known as Partyschaum [09:42] ? === zyga_ is now known as zyga-xchat === yofel_ is now known as yofel === manishrw is now known as manish_rw [12:33] h [12:34] me wiki [12:34] whois [12:34] WHOIS [12:34] nick Pritam_chaingang [12:35] Pritam_chaingang: may i help you ? here this channel is for classroom session [12:40] quit [12:40] Quit [12:46] yes yes [12:46] i am not able to enable my wireless in ubuntu [12:46] how do i do that [12:47] it was working before [12:48] Pritam_chaingang, please ask your questions about Ubuntu in #ubuntu [12:56] quit [12:57] lol [13:03] CHAT [13:05] when is the class [13:15] Pritam_chaingang: see topic [13:16] thanks === SpockVulcan is now known as AndrewMC [14:12] Hello [14:15] . [14:20] . [14:25] :P === dduffey_afk is now known as dduffey === metasansana is now known as serious_sam_the_ === serious_sam_the_ is now known as sstmtp [14:51] hey [14:52] Heya! :) [14:54] l [14:55] Welcome everybody to day 3 of Ubuntu Developer Week! [14:56] Before I hand over to seb128, here a few organisational bits [14:56] If you haven't joined #ubuntu-classroom-chat yet, please do it [14:56] it's where we chat and ask questions [14:56] and if you do ask questions, please prefix them with QUESTION:, ie: [14:56] QUESTION: What should be the default language in Ubuntu? [14:57] also, check out https://wiki.ubuntu.com/UbuntuDeveloperWeek because we added logs for all the sessions which happened yesterday and the day before [14:57] and tomorrow morning I'll go and add session logs for today [14:57] How has UDW been for you up until now? :) [14:59] I'm glad at least one person is answering in #ubuntu-classroom-chat ;-) [14:59] you all have 2 minutes left to wake up or get something to drink before my good friend Sébastien seb128 Bacher takes over [14:59] enjoy! :) [14:59] oh, drink! [14:59] * seb128 grabs a glass for water [15:00] dholbach, hey btw, how was *your* 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: Fixing Desktop bugs - Instructors: seb128 [15:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/02/%23ubuntu-classroom.html following the conclusion of the session. [15:00] ok, it's time to start [15:00] thanks everybody for joining [15:01] I'm Sebastien Bacher and working in the Ubuntu Desktop Team [15:01] I will show you a bit of what you do in the desktop team today [15:01] first some infos, you can find us on #ubuntu-desktop on this IRC channel [15:02] or that mailing list: https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop [15:02] feel free to join to ask question, participate to discussion or help doing work ;-) [15:02] so let's get started, what we do in the desktop team is basically keeping the desktop in shape === Tachyons is now known as tachyons [15:02] which means [15:03] - keeping the components updated [15:03] - fixing bugs [15:03] - looking to your bug reports [15:03] - talking to our upstreams (GNOME, Debian, dx, etc) [15:03] you can find some pointers and documentation on https://wiki.ubuntu.com/DesktopTeam/ [15:04] I will first walk you through a backport of an upstream GNOME git commit to one of our packages [15:04] note that the desktop team packages use a different workflow for most part than the "UDD" new standard workflow [15:05] the reason are basically that it works better for us still and we wait for a few extra issues to get sorted with UDD (mostly quilt handling and download times) [15:05] you can read https://wiki.ubuntu.com/DesktopTeam/Bzr to get some details on our workflow [15:05] so [15:05] let's start by fetch a source [15:05] we will use gnome-control-center in that example [15:05] for that you usually want to use "debcheckout " [15:06] $ debcheckout gnome-control-center [15:06] in this case [15:06] which should give you something around those lines [15:06] bzr branch http://code.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu gnome-control-center ... [15:06] then it's downloading the source for you [15:07] wait a bit for that to be done and you should get that: [15:07] $ ls [15:07] gnome-control-center [15:07] gnome-control-center_3.2.2-2ubuntu5.debian.tar.gz [15:07] gnome-control-center_3.2.2-2ubuntu5.dsc [15:07] gnome-control-center_3.2.2.orig.tar.bz2 [15:07] the first one is a checkout of the vcs directory [15:07] the other files are the source package from the archive [15:07] [15:08] let's have a look to the dir [15:09] hum, demo effect, that didn't do what I wanted today on precise [15:09] will have to look into that [15:09] so what it should have done and what I'm doing now it's what it wrote [15:09] which is basically [15:10] bzr branch lp:~ubuntu-desktop/gnome-control-center/ubuntu g [15:10] bzr branch lp:~ubuntu-desktop/gnome-control-center/ubuntu [15:10] ok, now I got what I wanted ;-) [15:10] let's visit that directory [15:10] cd ubuntu [15:10] $ ls [15:11] debian [15:11] so you get a debian dir there, it's where we will do our work [15:11] to continue you will need the bzr-builddeb and the build-depends of gnome-control-center [15:11] so assuming that you have the deb-src for oneiric or precise enable you can type those commands [15:12] sudo apt-get install bzr-builddeb [15:12] sudo apt-get build-dep gnome-control-center [15:12] the second one will install all the Build-Depends for gnome-control-center, i.e what you need to build it [15:13] now you should be set [15:13] so we are in the debian directory [15:13] rather in the ubuntu dir [15:13] bzr bd-do will give you a shell environement where you can do changes [15:14] whatever change you do that in the debian directory will be applied to the vcs checkout you did when you exit 0 [15:14] if you exit with something else than 0 you will not get the changes copied over [15:16] let's assume for the exercice than we want to backport the fix from http://git.gnome.org/browse/gnome-control-center/commit/?h=gnome-3-2&id=81fb28de5cf8708932224f482a8923322191b00f [15:16] ie http://git.gnome.org/browse/gnome-control-center/patch/?id=81fb28de5cf8708932224f482a8923322191b00f [15:16] so you did bzr bd-do and are in an unpacked source of gnome-control-center [15:18] let's save the content of that commit in a file, name it git_backport_printer_fix.patch [15:18] new you do [15:18] quilt import git_backport_printer_fix.patch [15:19] Importing patch git_backport_printer_fix.patch (stored as git_backport_printer_fix.patch) [15:19] [15:19] the patch is imported [15:19] let's check that it applies well [15:19] $ quilt push [15:19] Applying patch git_backport_printer_fix.patch [15:19] patching file panels/printers/cc-printers-panel.c [15:19] Now at patch git_backport_printer_fix.patch [15:19] [15:19] it does [15:19] let's refresh it [15:19] $ quilt refresh [15:19] Refreshed patch git_backport_printer_fix.patch [15:20] so all good [15:20] There are 10 minutes remaining in the current session. [15:20] we have our patch, it applies to our package and we refresh it [15:20] we are happy about it [15:20] we can exit [15:20] $ exit 0 [15:20] it bring you back to your vcs dir [15:21] let's see where we stand [15:21] $ bzr statusmodified: [15:21] debian/patches/series [15:21] unknown: [15:21] debian/patches/git_backport_printer_fix.patch [15:21] ok [15:21] so the series got updated, and we have a new file [15:21] $ bzr diff [15:21] === modified file 'debian/patches/series' [15:21] --- debian/patches/series 2012-01-25 16:38:52 +0000 [15:21] +++ debian/patches/series 2012-02-02 15:18:21 +0000 [15:21] @@ -25,3 +25,4 @@ [15:21] 93_change_window_role_on_panel_change.patch [15:21] 94_git_adding_shortcuts.patch [15:21] 95_git_ctrlw_shortcut.patch [15:21] +git_backport_printer_fix.patch [15:21] [15:21] the patch got added to the serie [15:21] we need to add the file to the vcs, that was not done for us [15:21] so we use [15:22] $ bzr add debian/patches/git_backport_printer_fix.patch [15:22] adding debian/patches/git_backport_printer_fix.patch [15:22] at this point we are mostly good [15:22] we need still to update the changelog [15:22] type [15:22] dch -i [15:22] and write a changelog entry [15:22] * backport fix from git (lp: #...) for example [15:22] then you can bzr diff again [15:22] you get a new revision with a backported patch ready to test! [15:22] now to test it's easy, run bzr bd [15:23] it will build the new version for you [15:23] if you don't have a gpg key matching your changelog email don't worry, it will warn you about that, that's ok [15:23] your deb are in ../build-area after the build [15:23] you can go there, sudo dpkg -i *.deb and try the new version [15:24] if you are happy with the change go back to the ubuntu dir [15:24] $ bzr commit [15:24] to commit you work [15:24] then [15:24] $ bzr push lp:~yourlaunchpadid/gnome-control-conter/my-fix [15:24] $ bzr lp-submit to do a merge proposal [15:25] and wait for us to review your work ;-) [15:25] [15:25] There are 5 minutes remaining in the current session. [15:25] ok, that was basically it for a patch backport, 5 minutes left [15:25] questions? [15:25] dholbach asked: Will Wanda the Fish ever come back? [15:26] dholbach, it's still in gnome-panel upstream, you can "free the fish" in the dash but it's not as cool as the vuntz' version I've been told and will not go around you screen ;-) [15:26] jincreator asked: I tried debcheckout but only get debian folder, not having ,dsc, .debian.tar.gz, .orig.tar.bz2. [15:27] jincreator, that's probably better, seems the tools changed behaviour in precise which confused me [15:27] you probably got the equivalent of my second command [15:27] [15:27] ali1234 asked: don't you need to export QUILT_PATCH_DIR? [15:27] good point, I'm sorry about that [15:27] it's one of those suboptimal thing you have to do, I did it years ago and forgot :p [15:28] you need to "export QUILT_PATCHES=debian/patches" [15:28] put that in your environement then you can forget about it like me :p [15:28] [15:28] ali1234 asked: what if the package doesn't use quilt but something else? [15:28] I couldn't cover all the patch systems there [15:29] you can use edit-patch (great tool that mvo wrote) than wrap around the different patch systems [15:29] it will do the quilt magic for you, or call cdbs-edit-patch or similar [15:29] [15:29] one minutes left and no question [15:29] seems we are good ;-) === 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: Triaging Desktop bugs - Instructors: om26er [15:30] Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/02/%23ubuntu-classroom.html following the conclusion of the session. [15:31] Hey! should we start [15:31] Hello! my name is Omer Akram. I have been in Ubuntu since mid 2009 and have been active in the community since then. I am a Ubuntu BugSquad and Bug control member. I also am a Bug Triager for Unity and the related projects. I had my first ever date yesterday <3 [15:32] So in this session I am going to discuss about how to triage desktop bugs efficiently. We receive hundreds of Bug reports in Ubuntu daily. There are basic two types of Bugs. 1 functionality problem 2 Crash :-) [15:32] the crash are the dangerous ones and are mostly hard to fix [15:33] A bug in a software is a fault that creates problems for people using it, it could be visual, functional etc [15:33] The role of Ubuntu bugsquad is to complete bug reports. i.e. to add any missing information, clear up the description of the bug report and make the report clean and simple so that the developers spend more time in fixing the issue then looking through bugs. [15:34] I have in bugsquad long enough I believe, we always get new contributors some who really do triage like crazy for so many hours [15:34] Bugs with proper steps to reproduce are the one's that really are USEFUL bugs or if they have a proper crash stacktrace. [15:35] the steps to reproduce are really very important [15:35] there are like 90000 bugs logged in launchpad and I believe there are many of those useless [15:35] i.e. the reporters didn't care to report enough details etc [15:36] lets say for example this bug https://bugs.launchpad.net/ubuntu/+source/unity/+bug/904348 === ublinx is now known as jmarc [15:36] the reporter reported the bug and did not bother to mention the problem really [15:37] its totally not related to Unity and needs to be relocated to some other package, he didnot mention detailed when the problem started [15:37] so our (BugSquad [15:37] responsibility here is that we should inquire the reporter to send more information about the issue so that the bug can be triaged easily [15:38] We do not handle questions in Bug reports so please people don't ask questions in Bug reports we have an answers section in launchpad for that. [15:39] the above was one example of useless bugs ;) [15:39] Sometimes people throw a bunch of issues into one single bug report that is really not a good thing when reporting a bug. [15:39] thats another type [15:39] our most beloved type is ofcourse called the RANT type :p [15:40] so to talk business, if you are want to start help Ubuntu Bug triage could be a good entering point [15:41] since you learn alot while triaging bugs, a bit about branches and stuff [15:41] If you are starting/thinking to start helping in Ubuntu bug triage you should join the Ubuntu BugSquad that is the team to handle bug reports in Ubuntu. [15:41] Most of the bugs in Ubuntu are Upstream [15:41] whats upstream? [15:42] actually every software have an upstream :P [15:42] upstream means the developers the people writing the software [15:42] SO out bugs need to be sent to the package's upstream [15:43] Empathy for example our chat client in Ubuntu have the nice batch of developers, who are really helpful and quick to response. [15:44] bugs reported by Ubuntu users in Launchpad for empathy need to be sent to bugzilla.gnome.org where the empathy upstream project is hosted [15:44] (oh boy I feel I am typing quite fast, never really typed that much) [15:45] the upstream developers would fix bugs which they understand so if people report useless bug reports you should not send the report straight upstream you should first try to get a good set of information from the reporter in launchpad and then send the bug to Bugzilla so that the developers don't get headaches ;-) [15:46] we really need to keep our upstreams happy [15:47] I actually think if someone, A Ubuntu user really wants to help Ubuntu he/should just go to software-properties and enable the -proposed repository and help test the proposed bug fixes [15:47] this is a very useful guide about how to triage: https://wiki.ubuntu.com/Bugs/HowToTriage/ [15:48] I read it quite a lot when I was applying for Ubuntu bug control [15:48] so who are Bug Control [15:49] well they are the next step after bugsquad, bug control people are those who set importance to bug reports, and assign bugs to developers and nominate bug for any specific release [15:50] There are 10 minutes remaining in the current session. === ANDRES is now known as Guest38400 [15:51] We use stock responses for bug reports for example If a bug report is missing its steps to reproduce I would not just go and say "you are missing the steps to reproduce the problem" [15:51] but we choose a more respectful approach and use the stock responses for Bugs https://wiki.ubuntu.com/Bugs/Responses [15:52] so for this specific case of missing steps we use: [15:52] Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions: [15:52] * Is this reproducible? [15:52] * If so, what specific steps should we take to recreate this bug? [15:52] This will help us to find and resolve the problem. [15:53] I remember a few of the initial bugs I reported in Ubuntu so the response came very humble from seb128 that the issue was upstream one and I should report it there... [15:54] I really was like these are good people they respect.. this is what I got the first reply for my very intial bug report [15:54] . [15:54] Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its st [15:54] atus. Thanks in advance. [15:55] There are 5 minutes remaining in the current session. [15:55] that thanks 2 times really inspired me, these Ubuntu people are so kind. so these responses really matter [15:57] in summary, a useful bug report is the one that is reprodueable with steps [15:57] a useful bug report have a visual attached i.e. a screenshot or video to show the problem [15:57] a good bug report is easy to understand [15:57] Now a good BugTraiger is the one who is patient [15:58] since the reporters can sometime really be Pain in... :D [15:58] Desktop bugs needs YOU [15:58] Ubuntu needs You :) [15:58] new contributors are always welcome === fenris is now known as Guest60985 [15:59] look at me I only triaged bugs and now I am a Ubuntu Member, Gnome Foundation member and Work for Canonical [16:00] (well contract for canonical :p) === 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: Simple Lenses with Singlet - Instructors: mhall119 [16:00] I guess the time is ending [16:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/02/%23ubuntu-classroom.html following the conclusion of the session. [16:00] thanks om26er [16:01] bug triaging really helps developers keep up, and anybody can do it [16:01] alright, welcome everybody [16:02] so what is Singlet? [16:02] well, it's a python library for writing Unity lenses [16:03] but Lenses are just DBus and GObject, they don't *need* a dedicated python library [16:03] in fact, many community lenses are already being written in python withut Singlet [16:03] so then, why Singlet? [16:04] because as a Python developer, I hate GObject and DBus [16:04] it's not that they're bad technologies, it's just that they're not "pythonic" [16:04] so using them in python feels unnecessarily complicated [16:05] I wrote my first 2 Unity lenses using them, and Singlet developed out of that [16:06] so Singlet itself works to hide all of those non-pythonic bits from you, so as a developer you get a nice, clean, simple interface [16:06] Singlet does this with a combination of traditional object-oriented abstraction, and a bit of Python meta-class programming [16:06] http://mhall119.com/2011/12/writing-unity-lenses/ gives an introduction and has some example source code [16:07] whoops, wrong link [16:07] http://mhall119.com/2012/01/simplified-unity-lens-development-with-singlet/ [16:07] that one [16:07] if anybody here has done any Django programming, it should look familiar to you [16:08] that's because I borrowed heavily form the way Django used simple Python classes as models, and from there can automatically do a lot of the boiler-plate work for you [16:08] Singlet does the same, you give it a little meta-data to describe your lens [16:08] define some categories [16:08] and then implement the search() method [16:09] and behind the scenes it's instantiating the GObject classes you'll need and connecting everything to DBus for you [16:10] Singlet also includes helper commands for running your Lens as a daemon process, and generating the .lens and .service files needed to install it, all from the meta-data you provide [16:10] any questions so far on what Singlet is? [16:11] alright, moving along [16:11] the example given in http://mhall119.com/2012/01/simplified-unity-lens-development-with-singlet/ shows how to make a simple Lens with one built-in Scope [16:12] if you attended davidcalle and mhr3's Lens session on Tuesday, you'll know that they can either exist in the same code, or separate code [16:12] In Singlet 0.1, which only works on Oneiric, this was all it could do [16:13] but Singlet 0.2, which was upgraded for Precise, introduces the ability to separate them [16:13] http://mhall119.com/2012/01/singlet-part-0-2/ [16:13] Singlet 0.2 is being packaged for Precise, and will be available in the default repositories [16:14] this means you can write lenses and scopes that use Singlet, and make them easily installable [16:15] Now you don't *have* to use Singlet to write a Python lens, but it cuts the amount of code you need to write to get one started in half [16:15] and it also means that you have a compatibility layer between your code and any possible API changes [16:15] for example, in the move from Unity 4(Oneiric) to Unity5(Precise), the Lens API changed [16:15] but Singlet's API didn't [16:16] so a Lens written for Singlet 0.1 on Oneiric would be able to run without modification on Singlet 0.2 on Precise [16:18] As for packaging, sometime soon we will have a Quickly template for writing Singlet lenses and scopes [16:18] for anybody not familiar with Quickly, it's a tool for rapid application development [16:19] it'll create any files and directories you need to get started on a specific kind of project (like command-line program, desktop app, or Unity lens) [16:19] it also provide packaging files for you, so that your app can be uploaded to the Ubuntu Software Center [16:19] there are already a handful of Unity lenses and scopes in the Software Center [16:20] There are 10 minutes remaining in the current session. [16:20] and with Singlet + Quickly, we'll open the door for opportunistic developers to put together lenses that will feed their desired content directly into the Unity dash [16:21] Lenses are one of the most exciting and unique features for extending Unity, and I expect to see a large number of them being developed for Ubuntu 12.04 [16:21] and, hopefully, a large number of them will be doing it with Singlet [16:21] alright, any questions before I'm out of time? [16:23] alright, thanks to those you attended [16:24] anybody interested can get the project and code from https://launchpad.net/singlet [16:24] and the above blog entries will serve as a tutorial for writing Singlet lenses and scope, at least until I can put a more formal tutorial together [16:25] There are 5 minutes remaining in the current session. [16:27] alright, I guess I'll turn things over to tumbleweed then [16:27] * tumbleweed waves [16:28] I was still writing some notes, but no reason not to start a couple of minutes early :) [16:28] Hi everyone, [16:28] Some of you may have been at the session I took yesterday afternoon, on working with Debian [16:28] For everyone else, hi, I'm Stefano Rivera, an Ubuntu MOTU and Debian Developer [16:28] I'm here to talk to you about building packages locally with pbuilder [16:28] If you followed Daniel Holbach's introduction on Tuseday, you'll have already set up pbuilder, using pbuilder-dist. https://wiki.ubuntu.com/MeetingLogs/devweek1201/DevEnvironmentSetup [16:28] If you haven't, install ubuntu-dev-tools and pbuilder right now, and run "pbuilder-dist precise create" (it'll take quite a while) [16:29] Maybe you'll be done by the end of the session... :) [16:29] As you can imagine from its name, pbuilder is a tool for building Debian packages [16:30] (Ubuntu packages aren't any different) === 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: Building locally with pbuilder - Instructors: tumbleweed [16:30] Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/02/%23ubuntu-classroom.html following the conclusion of the session. [16:30] aha, we've officially started now [16:30] If you haven't used pbuilder before, you make wonder what the point is: Anyone can just build a source package by extracting it and running debuild, right? [16:31] Well, you need all the build dependencancies installed, so you're machine will quickly end up with lots of packages that you don't really need installed. [16:31] Your machine will have packages installed in it that the official build machines don't [16:31] All packages in the main archive are built in restricted build environments on buildds (build machines) [16:32] so, just building locally with debuild may give different results [16:32] (with well behaved packages it doesn't, but we probably spend more time on the badly behaving ones, right? :) [16:32] The buildds run a program called sbuild to do the builds. It installs the build dependencies in a minimal chroot, builds the package, and then throws away the chroot [16:32] We'd like to have a similar environment for testing builds [16:33] Something we can use to find likley build failures before we upload [16:33] (you do test before uploading, right?) [16:33] and to help us debug failures [16:33] Launchpad has PPAs, using the same build systems an the primary Ubuntu archives, why do you need to build things locally? [16:33] Well, there are a few reasons: [16:33] Launchpad's PPA builders can get rather backed up, sometimes the queue gets as long as a few days (currently they are quite short, though: https://launchpad.net/builders ) [16:34] Your machine is probably faster than some of the buildds (at least mine is :P ) [16:34] You don't have to bump the version every time you want to try a build [16:34] You can log into the build environment and debug things, when they go wrong [16:34] ^ That one is the killer feature [16:34] So, we want to set up a reproducable minimal build environment locally, that we can use for testing package builds and debugging them [16:34] You could use sbuild, like the buildds, or you could use pbuilder, which is simpler and easier to customise. [16:35] ere's also cowbuilder, which is a "faster pbuilder", but I won't bother going into that, if you're reaching the limits of pbuilder, I suggest also looking at sbuild [16:35] err "There's" [16:36] Personally, I build everything with sbuild, but I'm here to talk about pbuilder, so that's what I'm doing :P I used to use it, there's nothing wrong with it [16:36] now seems to be a good time to see if I've actually got an audience [16:36] anyone currently building a pbuilder chroot? [16:36] anyone run into trouble already? [16:37] So, details: [16:37] What pbuilder does: [16:37] When you create a chroot, it debootstraps a clean install into a directory (debootstrap is a very low level tool for minimal Debian/Ubuntu installs) [16:37] It then packs up that directory into a tarball. [16:37] Whenever you do a build, it upacks that tarball, chroots into the unpack directory, and does the build. [16:37] The directory can be deleted afterwards [16:38] (It's worth noting that sbuild used to be far more complicated, using LVM, but these days it supports overlay filesystems, so it's totally reasonable to set it up locally) [16:38] So, how come I'm talking about pbuilder when I told you to run "pbuilder-dist" ? [16:38] Well, it turns out that pbuilder is very flexible, but doesn't come with all the features you'd want, out the box [16:38] It assumes that you are building everything for a single distribution and release (which makes some sense in Debian, but less so in Ubuntu) [16:38] So, we have a wrapper around pbuilder in ubuntu called pbuilder-dist [16:39] All it does is call pbuilder with a bunch of command line options (you can see that with a ps x) [16:39] It also puts the chroot tarbals and built files into a friendly ~/pbuilder/ rather than /var/cache/pbuilder/ [16:39] before pbuilder-dist, most people used to use complicated pbuilder configuratino files that did all of that for them [16:39] figuring out what release to build for, from environment variables [16:40] e.g. https://wiki.ubuntu.com/PbuilderHowto#Multiple_pbuilders [16:40] pbuilder-dist makes it a lot quciker for you to get started [16:40] Right, so, if you have a working pbuilder, you can test building something in it [16:41] grab a package that'll build quickly, here's one I can think of, beautifulsoup: [16:41] $ pull-lp-source -d beautifulsoup [16:41] $ pbuilder-dist precise beautifulsoup_3.2.0-2build1.dsc [16:42] and it should build... [16:42] coolbhavi asked: How to get pbuilder log files? [16:42] pbuilder will store a log file next to the build output [16:43] so, next to the debs, you should see a file called beautifulsoup_3.2.0-2build1_amd64.build [16:43] (or i386, if you use i386) [16:44] Next up: pbuilder maintainance [16:44] it's not very useful to build in last week's development environment, Ubuntu development releases move fast [16:44] you always want to build with current packages [16:45] so, every now and then (say, when you start working on something for the first time in the day, run pbuilder-dist update precise) [16:45] (you may set up a cronjob for that if you do this a lot) [16:45] coolbhavi asked: I heard about pbuilder and pdebuild whats the difference between them? [16:46] right, pdebuild is like "debuild" for pbuilder [16:46] you can run it inside an extracted source package, and it'll build the source package, and pass it to pbuilder [16:46] unfortunetly, we don't have a pdebuild for pbuilder-dist (there's a bug requesting one) [16:46]