[00:31] <ysnoi> hello there...
[00:31] <ysnoi> my first time boot here..
[00:47] <codepal> ysnoi, welcome - o/
[00:47] <codepal> !logs
[00:47] <ClassBot> Logs for all classroom sessions that take place in #ubuntu-classroom can be found on http://irclogs.ubuntu.com/
[01:13] <ysnoi> hi codepal...I've been disconnected after I use lernid and XChat at the same time...
[01:13] <codepal> ysnoi, aha - you've learnt something then!
[01:13] <codepal> don't use both at the same time!
[01:13] <codepal> :D
[01:14] <ysnoi> im just curious...1st time here
[01:14] <codepal> ysnoi, if you want to read  what happened in this class this morning you can visit
[01:14] <codepal> !logs
[01:14] <ClassBot> Logs for all classroom sessions that take place in #ubuntu-classroom can be found on http://irclogs.ubuntu.com/
[01:15] <ysnoi> ok thanks...i'll get to it
[01:18] <ysnoi> ah..so it's in html and txt file format...got it
[01:19] <ysnoi> codepal: you have two colors on username...may I know why?
[01:25] <codepal> ysnoi, maybe because when I speak your nickname it changes.
[01:25] <codepal> let's try...
[01:25] <ysnoi> yeah..
[01:25] <ysnoi> +1
[01:26] <ysnoi> can i ask anything here?
[01:26] <ysnoi> like how can I change my username?
[01:26] <ysnoi> on this chat
[01:26] <codepal> - /nick someother
[01:27] <codepal> irc uses '/' to give access to commands
[01:27] <ysnoi> i don't get it
[01:27] <ysnoi> - /ysnoi TheYsNoi
[01:27] <codepal> when u use it correctly with the '/' as  the first thing on a line
[01:27] <codepal> take off the '-'
[01:27] <codepal> and space
[01:28] <ysnoi> - ysnoi TheYsNoi
[01:28] <pleia2> /nick TheYsNoi
[01:28] <pleia2> ^^ just that
[01:28] <ysnoi> haha...
[01:29] <pleia2> and sessions aren't starting again here for several hours, 15:00 UTC (it's 1:30 UTC now)
[01:30] <ysnoi> - /ysnoi TheYsNoi
[01:30] <codepal> pleia2, how'd you do that?
[01:30] <codepal> escaping '/'
[01:31] <pleia2> codepal: using irssi: / /command
[01:31] <pleia2> "/ " escapes commands
[01:31] <codepal> ah, thanks!
[01:31] <TheYsNoi> yes...
[01:31] <TheYsNoi> I got it...
[01:32] <TheYsNoi> thanks pleia2 and codepal
[01:32] <codepal> obviously different for different IRC clients...
[01:32] <codepal> TheYsNoi, in any case, we're glad your getting familiar with IRC
[01:33] <TheYsNoi> thanks a lot codepal
[01:34] <codepal> TheYsNoi, do you want a IRC lessson?
[01:34] <TheYsNoi> i'm using XChat...I was starting to connect to this channel last night but I got connected to mint instead...
[01:35] <TheYsNoi> until I saw freenode and ubuntu-classroom
[01:36] <TheYsNoi> IRC lesson?
[01:36] <deltab> in some you use /say instead
[01:38] <codepal> TheYsNoi, -- http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial -- Take a read, hopefully you'll be able to work out some things for yourself
[01:38] <codepal> using /msg Chanserv help && /msg Nickserv help
[01:39] <TheYsNoi> opening now in browser...i'll take a look on it...
[01:39] <codepal> TheYsNoi, there are many channels on freenode on different topics, just 'remember the rules'
[01:39] <TheYsNoi> thanks codepal
[01:39] <deltab> see also  http://freenode.net/  - especially for the quirks of this network
[01:40] <codepal> yeah, freenode.net needs a web redesign - I hate it
[01:40] <codepal> http://linuxlibrary.org/command-line/irc-internet-relay-chat/ for a quick, basic run down of commands
[01:44] <TheYsNoi> ah...so pidgin has also an IRC support
[01:44] <benonsoftware> Yep
[01:46] <TheYsNoi> ok..i'll try adding an account..
[02:18] <TheYsNoi> hey codepal..
[02:19] <codepal> yeah?
[02:20] <TheYsNoi> I tried registering my nickname on NickServ as TheYsNoi but the username that arrived on my mail is TheYsNoi1? is this normal?
[02:20] <TheYsNoi> I hate having 1 on my nick..
[02:21] <codepal> well maybe you can ignore the registration email ( you don't have to confirm )
[02:22] <codepal> think hard about your nickname - it defines your first impression with many people.
[02:22] <codepal> and try again - you still can retry signing up with TheYsNoi,
[02:22] <codepal> if you want
[02:22] <TheYsNoi> maybe because when I register my nick on Pidgin, i'm also here as TheYsNoi..
[02:23] <codepal> that would be it
[02:23] <codepal> possibly
[02:23] <codepal> you can register in XChat instead
[02:23] <TheYsNoi> if so, I  need to logout here and try again...
[02:23] <codepal> or do that, yeah!
[02:24] <TheYsNoi> or, i will logout on pidgin and register here
[02:25] <TheYsNoi> is this server irc.ubuntu.com?
[02:26] <codepal> it doesn't really matter which server does it?
[02:27] <TheYsNoi> ah ok..i'll try now..
[02:27] <codepal> whenever you log in you can get a different server that's still connected to this network
[02:27] <codepal> lot's of servers make up the freenode network
[02:29] <TheYsNoi> NickServ REGISTER <pass> <email>
[02:29] <TheYsNoi> is that correct syntax codepal?
[02:30] <codepal> yup
[02:30] <codepal> remember, you can find help on most commands using /msg nickserv help command
[02:31] <codepal> or /msg chanserv help command
[02:31] <TheYsNoi> yeah...
[02:32] <TheYsNoi> i learned that today from you...
[02:33] <codepal> you might like a cloak which hides your ip address -- so people don't try hacking you -- in the channel #freenode
[02:33] <codepal> just ask nicely for a cloak
[02:33] <codepal> also you probably want to learn how to connect via SSL (more securely)
[02:33] <TheYsNoi> how?
[02:33] <codepal> which can get complicated....
[02:34] <codepal> ask in #freenode for help or your IRC clients channel
[02:34] <codepal> ie #xchat / #pidgin
[02:34] <codepal> and don't forget you can use www.google.com
[02:35] <TheYsNoi> yeah...may I get to it one day..
[02:35] <TheYsNoi> i'm on familiarization now..
[02:35] <TheYsNoi> it's my rest day today..hehhe
[02:42] <TheYsNoi> yes..i'm done on registration..
[02:44] <ysNoi> test
[02:44] <TheYsNoi> test 2
[03:15] <TheYsNoi> hello
[03:52] <Ravemaste> hmnnn...
[03:54] <Ravemaste> anybody?
[03:56] <benonsoftware> Hello
[04:00] <Ravemaste> hi benon
[04:18] <TheYsNoi> join #ubuntu-release
[05:43] <kanliot111111111>
[05:44] <kanliot111111111>
[05:44] <kanliot111111111>
[05:44] <kanliot111111111>
[05:44] <kanliot111111111>
[12:59] <ysnoi> anybody?
[12:59] <metasansana> what is the link to the timetable again?
[13:01] <metasansana> nevermind
[14:53] <dpm> Everyone ready for the UDW Day 2?
[14:55] <palladin35y> metasansana:  is that you ?
[14:57] <PaoloRotolo> dpm, sure :)
[14:58] <dholbach> Alright my friends! WELCOME TO DAY 2!
[14:58] <dholbach> Again a few organisational bits before dpm takes over the stage...
[14:59] <dholbach> Please make sure you all join #ubuntu-classroom-chat because that's where all the chat and questions go
[14:59] <dholbach> also please make sure you prefix all your questions with QUESTION, ie
[14:59] <dholbach> QUESTION: dpm, how much do you like metal music?
[14:59] <dholbach> you can find the schedule at https://wiki.ubuntu.com/UbuntuDeveloperWeek along with all the logs of the sessions yesterday if you missed them
[15:00] <dholbach> I hope you have a fantastic time today
[15:00] <dholbach> big hugs from me
[15:00] <dpm> (do I really have to answer that question...?)
[15:00] <dholbach> and I pass on the mic to David "dpm" Planella who talks about "Bringing your app to Ubuntu "
[15:00]  * dholbach hugs dpm
[15:00] <dholbach> the stage is yours
[15:00] <dholbach> :)
[15:00]  * dpm hugs dholbach while catching the mike
[15:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[15:01] <dpm> Allright, how's everyone doing?
[15:01] <ryan__> I am doing well.
[15:01] <dtss> good :)
[15:01] <yuvilio> awake
[15:02] <dpm> cool
[15:02] <dpm> ok, awesome
[15:03] <dpm> let's wait a minute for stragglers to come in and then we can start
[15:04] <dpm> I hope you all are enjoying UDW so far...
[15:04] <dpm> dholbach tells me yesterday was awesome!
[15:04] <dpm> Anyway, let's get started
[15:05] <dpm> Hi everyone and welcome to the first session of Ubuntu Developer Week Day 2!
[15:05] <dpm> During the next hour I'll be talking about how to submit your apps to Ubuntu,
[15:06] <dpm> so that they get published in the Software Centre
[15:06] <dpm> to be distributed to millions of users that will surely enjoy your cool software :)
[15:06] <dpm> But it will not be just a talk: I'll  make sure that there is plenty of time for everyone
[15:07] <dpm> to participate and ask their questions at the end. However, feel free to interrupt me during the
[15:07] <dpm> rest of the session if you've got any questions.
[15:07] <dpm> Just remember to prepend them with QUESTION: on the #ubuntu-classroom-chat channel
[15:07] <dpm> Throughout the talk I will be referring to different places in the Ubuntu App Developer site,
[15:07] <dpm> which is the central place for anyone wanting to create and publish their apps in Ubuntu.
[15:08] <dpm> Here's where it lives:
[15:08] <dpm>     http://developer.ubuntu.com
[15:08] <dpm> ... and without further ado ...
[15:08] <dpm> let's get rolling!
[15:08] <dpm>
[15:09] <dpm> Creating your app
[15:09] <dpm> [15:09] <dpm>
[15:09] <dpm> Well, the first step is obvious, you have to create your app,
[15:09] <dpm> which is basically the time when you materialise that cool idea into beautiful software.
[15:09] <dpm> I will not dwell too much on this subject, as it's beyond the scope of the session,
[15:10] <dpm> However, I'll just add a couple of tips for app authors.
[15:10] <dpm> If you're considering writing a new application for Ubuntu, I'd recommend to use
[15:10] <dpm> the standard set of tools available from the Ubuntu archive.
[15:10] <dpm> They are an extremely powerful and versatile bunch of tools
[15:11] <dpm> which will not only put everything you need to write software at your fingertips,
[15:11] <dpm> but also will help you following good development practices.
[15:11] <dpm> And they're all Free Software and also free as in free beer!
[15:12] <dpm> I see we've got a question already, but let me show you something first:
[15:12] <dpm> You've got an overview of our recommendations to write new apps here:
[15:12] <dpm>     http://developer.ubuntu.com/get-started/quickly-workflow/
[15:12] <ClassBot> ryan___ asked: Which programming language do you perfer to use to develop Ubuntu apps?
[15:13] <dpm> as you can see from the table in the link above, we're currently recommending Python
[15:13] <dpm> as a language to write new apps
[15:13] <dpm> What we've also got is a tool called quickly, which puts all those technologies together
[15:14] <dpm> You can learn more about it here, it's got a nice and short video tutorial
[15:14] <dpm> to show you how to write a basic functional template for your app in 3 minutes:
[15:14] <dpm>     http://developer.ubuntu.com/get-started/
[15:14] <dpm> However, if you've already written an application with another set of tools,
[15:15] <dpm> or if you do prefer another choice of toolkit, that's also ok!
[15:15] <dpm> We're providing these recommendations to make it easy for app authors to get started
[15:15] <dpm> and provide a smooth path for publishing their apps.
[15:15] <dpm> However, we acknowledge the diversity of the whole Open Source ecosystem,
[15:16] <dpm> so you can basically submit your apps using your weapon of choice.
[15:16] <dpm> Just remember that our recommendations will make things easier, though!
[15:16] <ClassBot> metasansana asked: why phython?
[15:18] <dpm> we chose quickly because it's an easy to learn high level language, which is open source and it's got first class support in Ubuntu.
[15:18] <dpm> apart from that, it comes with a rich library of functions to do virtually anything you want
[15:19] <dpm> Continuing on this subject,
[15:19] <dpm> also, commercial apps (more on those in a minute) might be written in a completely different set of tools, and we want to be inclusive to them too.
[15:20] <ClassBot> ryan___ asked: does Quickly support the Microsoft Visual Basic programming language?
[15:21] <dpm> quickly just puts together a set of tools, it's not an IDE that supports languages, although conceivably could be extended to support other languages
[15:22] <dpm> however, to answer the question, quickly intendedly only supports python, no Visual Basic
[15:22] <dpm> ok, moving along
[15:22] <dpm>
[15:22] <dpm> Which types of apps qualify
[15:22] <dpm> [15:22] <dpm>
[15:22] <dpm> There are thousands of apps available in the Ubuntu archive already, which usually get in there through other means.
[15:22] <dpm> Many of these fall into the category of system software, or big applications that are part of the Ubuntu platform.
[15:23] <dpm> They are also subject to strict policies to ensure the security and quality of the software,
[15:23] <dpm> as well as to ensure that they are indeed Free Software and can be distributed with Ubuntu.
[15:23] <dpm> So in order to differentiate from these archive applications, I'll call the process  we'll be talking about today, "the app developer process".
[15:24] <dpm> Ultimately though, they are all published through the Software Centre
[15:25] <dpm> So to answer the first question, these are the 3 broad categories under which apps to be submitted through the app developer process fall:
[15:25] <dpm> * Paid for apps
[15:25] <dpm> * Gratis apps with proprietary licenses
[15:25] <dpm> * Gratis apps with Open Source licenses
[15:25] <dpm> Notice that as well as open source, we're also embracing commercial applications
[15:25] <dpm> to give the opportunity to app authors and Canonical to make revenue of application sales.
[15:26] <dpm> This should give you a rough idea, but ultimately you will need to know the whole
[15:26] <dpm> details to see if your app qualifies for the app developer process.
[15:26] <dpm>
[15:26] <dpm> - For paid for and gratis+proprietary apps:
[15:26] <dpm>     http://developer.ubuntu.com/publish/commercial-software-faqs/
[15:26] <dpm> - For gratis+open source apps:
[15:27] <dpm>     https://wiki.ubuntu.com/AppReviewBoard/Review/Guidelines
[15:27] <dpm> Ok, next is where it gets interesting: how to actually submit your app!
[15:27] <dpm>
[15:27] <dpm> 1. Submitting your app
[15:27] <dpm> [15:27] <dpm>
[15:27] <dpm> Ok, so all that cleared up, by this point you've already have a working app you'd
[15:27] <dpm> like the world to see and enjoy.
[15:28] <dpm> The good news is that we've got an easy, streamlined and web-based process
[15:28] <dpm> to make it easy for you to to publish, keep track of, monitor and update your apps.
[15:28] <dpm> For this, we've developed a tool especially for app developers.
[15:28] <dpm> It's called My Apps and you'll find it on the app developer site:
[15:28] <dpm>     https://myapps.developer.ubuntu.com
[15:29] <dpm> You'll see that it's easy and intuitive to use, and the first thing you'll want to do is to sign up for it
[15:29] <dpm> to enter the Ubuntu app developer programme and start using it straight away :-)
[15:29] <dpm> Signing up it's free, and again, it's a matter of a couple of minutes.
[15:29] <dpm> The process is based on Ubuntu's single login,
[15:30] <dpm> so if you've got an Ubuntu SSO account already, it will be even quicker.
[15:30] <dpm> Simply go to https://myapps.developer.ubuntu.com, either click on the "Sign in or register" link at the top right hand side
[15:30] <dpm> or the "Submit a new application" button, and the website will guide you through the process.
[15:30] <dpm> Before you continue the process of submitting the app though, you might want to read the quickstart guide on:
[15:31] <dpm>     http://developer.ubuntu.com/publish/
[15:31] <dpm> It will show you the basic steps you will be following and give you some useful tips along the way.
[15:31] <dpm> Let's go quickly through them:
[15:31] <dpm> 1 - Set up your My Apps account - you've already done that :)
[15:31] <dpm> 2 - Prepare your app's icons and screenshots - you will want your app to be
[15:31] <dpm> appealing to users, so make sure you've got nice screenshots and icons, in all recommended sizes
[15:32] <dpm> 3 - Add your application details - here you'll be describing your app and making it easily
[15:32] <dpm> discoverable in the Software Centre. Make sure the description is clear and use a spell-checker to avoid typos
[15:32] <dpm> 4 - Choose your price - if your app is paid for, you'll have to decide the price in USD at this point
[15:32] <dpm> The minimum price is $2.99
[15:32] <dpm> 5 - Have an archive of your application ready to upload - here's where you upload your actual app to MyApps. More on this in a minute
[15:32] <dpm> 6 - Your app will be reviewed - before it gets into the wild, your app needs to be reviewed and QAd. More on this in a minute too.
[15:33] <dpm> So going back on the step of uploading your app,
[15:33] <dpm> Ideally, you should submit a Debian source package. A Debian source package consists of 3 files (with extensions .dsc, diff.gz, orig.tar.gz), which you should put in a compressed archive (a tarball, zip file, rar...) and upload into My Apps. This will allow reviewers to easily test and publish your app.
[15:33] <dpm> *However*, there are some important caveats:
[15:34] <dpm>  * If your app is commercial or proprietary software: we still recommend uploading a Debian source package, but if you are not experienced in packaging you can also upload either your binary executables and all files needed to run your app in a compressed archive, a binary Debian package (.deb), your source code in a compressed archive, and the commercial packagers will package and publish it for you.
[15:34] <dpm> Very soon we'll have automatic packaging in place, but more details on that when it's all deployed and working
[15:35] <dpm>  * If your app is Free Software and gratis: we recommend using a Personal Packaging Archive (PPA). You can specify the location of your PPA in the 'Any additional notes for the application reviewer' text box in the Overview tab of your app's entry in My Apps. You can also learn more about PPAs in the packaging section of the Ubuntu App Developer Site
[15:35] <dpm> developer.ubuntu.com/packaging
[15:36] <dpm> We've got a few questions coming in, and they're related to reviewing
[15:36] <dpm> Let me talk a bit about review and then answer them
[15:36] <dpm>
[15:37] <dpm> 2. Reviewing your app
[15:37] <dpm> [15:37] <dpm>
[15:37] <dpm> After your application has been submitted, and depending of the type of app, one of two things will happen:
[15:38] <dpm> * If it's a paid for or a gratis+proprietary app, it will be reviewed by the Canonical reviewers team. If necessary, they will package it for you and QA it. Very soon, though, we'll be able to automatically package those.
[15:38] <dpm> * If it's a Free Software+gratis app, it will generally be reviewed by a team of volunteers called the Ubuntu App Review Board (ARB)
[15:39] <dpm> In any case, reviewers will get in touch with you as soon as they start reviewing
[15:39] <dpm> your app, and you will be notified of any app state changes by e-mail.
[15:39] <dpm> For all the exact details of an application's lifecycle in My Apps, check out:
[15:39] <dpm>     http://developer.ubuntu.com/publish/application-states/
[15:39] <dpm> Now onto the questions:
[15:40] <ClassBot> cielak asked: I have been interested in the review process for some time, and I would like to somehow help the ARB team. Is there any way I could participate and help them?
[15:40] <dpm> they'd be delighted to hear that!
[15:40] <dpm> you can jump into the #ubuntu-arb channel and ask how to help, or you can contact the ARB through e-mail
[15:41] <dpm> https://wiki.ubuntu.com/AppReviewBoard
[15:41] <dpm> you'll find all the details there
[15:41] <ClassBot> ryan___ asked: how long does it take after you submit an application to Ubuntu before it shows up in the Ubuntu Software Centre?
[15:43] <dpm> it depends on your application, and if it's easy to review and QA, or if it's a commercial app, if it needs to be packaged and it's easy to do
[15:44] <dpm> it can take from some hours to some days, but it varies on an app by app basis
[15:44] <dpm> You'll find some more details there: http://askubuntu.com/questions/97272/how-long-does-it-take-to-complete-the-review-stages-in-ubuntu
[15:45] <ClassBot> dmj726 asked: How will proprietary apps be reviewed for security?
[15:46] <dpm> apps submitted through the app developer process are not subject to the same security policies of those in the Ubuntu archive
[15:47] <dpm> let me ask davmor2 to provide some more details in a minute
[15:47] <ClassBot> Gontxo-Vitoria asked: If I make a app that is foss, i can't not sell it in ubuntu?
[15:47] <dpm> yes, you can also sell free software apps!
[15:48] <dpm>     http://developer.ubuntu.com/publish/commercial-software-faqs/ covers that too
[15:48] <ClassBot> pawel_st asked: As an app author, am I obliged to support all currently supported Ubuntu releases, or can I target a specific (latest) Ubuntu release with my app?
[15:49] <dpm> we recommend you to support as many releases for the sake of making your app more widely available, but we do not enforce you to do it
[15:49] <ClassBot> dmj726 asked: I've seen magazine issues and books in the Ubuntu Software Center.  How would one publish something like that through Ubuntu?
[15:50] <dpm> I'm not sure I understand the question, we already publish them in Ubuntu, which means making them available in the Software Centre!
[15:50] <dpm> I've got some more details on the security question from davmor2:
[15:50] <dpm> dmj726 asked: How will proprietary apps be reviewed for security?  reference to this, you are currently limited to which directories you can write to.  However security is strictly the responsibility of the application developer and it is they that become liable for any breach of these ref the developer contracts
[15:51] <ClassBot> There are 10 minutes remaining in the current session.
[15:51] <ClassBot> pawel_st asked: What are acceptance criteria for commercial apps? Is acceptance process transparent? Is this only about packaging quality etc., or are there other criterias such as conformance to patents etc.? Can I get an early draft of my application reviewed against acceptance criteria before investing time and effort into its further development?
[15:53] <dpm> if it's not covered on http://developer.ubuntu.com/publish/commercial-software-faqs/, then it's on an app-by-app basis. I'd recommend submitting the draft of your application and then reviewers will get in touch with you
[15:53] <dpm> cwayne asked: how long will an app stay in 'pending review' state for?
[15:54] <dpm> you can find the details here: http://askubuntu.com/questions/97272/how-long-does-it-take-to-complete-the-review-stages-in-ubuntu
[15:54] <dpm> any more questions?
[15:55] <ClassBot> dmj726 asked: Are commercial apps vetted for any sort of quality to avoid malicious apps?
[15:55] <ClassBot> There are 5 minutes remaining in the current session.
 dmj726: so there is a developer review and qa steps to pick up on obviously broken/unistallable apps as for malicious this again falls to the liability of the app developer.
[15:56] <dpm> so if there are no more questions for now, just a quick reminder on how to get help or get in touch
[15:56] <dpm>
[15:56] <dpm>  Getting help
[15:56] <dpm> [15:56] <dpm>
[15:56] <dpm> If you need any help or if you've got any questions, be it during or before the
[15:56] <dpm> publishing step, there is an awesome, awesome community of app developers out
[15:56] <dpm> there just like you, willing to lend a hand
[15:56] <dpm> Check out:
[15:57] <dpm> http://developer.ubuntu.com/community/
[15:57] <dpm> From there, I'd like to highlight:
[15:57] <dpm> Real-time chat: http://webchat.freenode.net/?channels=ubuntu-app-devel
[15:57] <dpm> i.e. the #ubuntu-app-devel IRC channel on Freenode
[15:57] <dpm> Askubuntu: http://www.askubuntu.com/questions/ask?tags=application-development
[15:58] <dpm> For all your app development related questions
[15:58] <dpm> Mailing list: https://lists.ubuntu.com/mailman/listinfo/ubuntu-app-devel
[15:58] <dpm> Also for all your questions and longer discussions
[15:58] <dpm> And finally, here's an overview on how to stay up to date:
[15:58] <dpm> http://developer.ubuntu.com/2011/11/building-the-ubuntu-app-development-community-i-communication-channels/
[15:59] <ClassBot> PaoloRotolo asked: If you have uploaded an app without packaging, after the packaging by review board, can you ask to download the packaged app?
[16:00] <dpm> For Free Software gratis apps, we currently recommend packaging your application yourself and put it in a PPA
[16:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[16:00] <coolbhavi> thanks dpm :)
[16:00] <coolbhavi> Hi all I am Bhavani Shankar a 24 year old ubuntu developer from India and I am going to take you through the process of upgrading packages in the ubuntu archive
[16:01] <coolbhavi> Before we start a bit of dev environment preparation; Make sure you have packaging-dev package installed if you are running on oneiric :) or please go through the session logs of dholbach's session yesterday :)
[16:01] <coolbhavi> So lets start :)
[16:01] <coolbhavi> Upgrading a package generally means upgrading a package to the latest upstream version in the ubuntu archive
[16:02] <coolbhavi> normally, we would get the update from debian in the form of a merge or a sync, but there are cases when we don't, like for example if debian is in a freeze, or the package is orphaned, or its a native ubuntu maintained package
[16:02] <coolbhavi> or we simply need it urgently (in case of a RC bugfix, for instance), and then pass the result back to debian
[16:03] <coolbhavi> So assuming there are no doubts lets move on :)
[16:03] <coolbhavi> so, we now know we have a new upstream version, first thing to do is to get it
[16:03] <coolbhavi> We can either download it using wget or uupdate <path to orig tarball>
[16:04] <coolbhavi> Or if we have a watch file under debian directory in the current package, we can use that giving the command "uscan" at the source tree root
[16:04] <coolbhavi> (More on debian/watch here http://wiki.debian.org/debian/watch)
[16:04] <coolbhavi> uscan --verbose would say a bit more about what we are trying to do (in fact uscan calls upon uupdate :) more on uupdate: please see man uupdate)
[16:05] <coolbhavi> finally, there could be a get-orig-source target in debian/rules that we can use
[16:05] <coolbhavi> by executing "make -f debian/rules get-orig-source" in the source tree
[16:06] <coolbhavi> A check here: be careful to read the previous entries of debian/changelog as the previous packager could have mentioned something he did with the previous version of the upstream tarball (like for instance repacking the tarball) which comes in detail later in the session
[16:07] <coolbhavi> ok, now that we have an upstream tarball, we need to rename it in accordance to our policy foo-1.1.tar.gz will become foo_1.1.orig.tar.gz
[16:07] <coolbhavi> In the simplest case is if there are no changes to packaging and no changes outside of debian
[16:08] <coolbhavi> Just untar your tarball, copy the old debian dir to the new source tree, Add a changelog entry and Build the package :)
[16:08] <coolbhavi> I wish all the updates were so simple :)
[16:09] <coolbhavi> (Previously prior to dpkg-source version 3.0 if the the previous packager made inline changes instead of using a patch system, (you could check this by checking the old diff.gz), Just making changes inside the debian directory would'nt be enough, you needed to run the patch the present version of the package manually and there you would experience some pain in some changes being obsolete and couldnt apply anymore or you would run uup
[16:09] <coolbhavi> date ../foo_2.orig.tar.gz in the old version src tree to automate the whole manual process.)
[16:10] <coolbhavi> But now thanks to dpkg-source version 3.0 which generates a debian-changes-* file while building if there are any changes outside the debian directory and wrt policy 3.9.2 throws out a lintian warning too :)
[16:10] <coolbhavi> ( More about dpkg-source version 3.0 here: http://wiki.debian.org/Projects/DebSrc3.0)
[16:11] <coolbhavi> A more complex scenario of updating a package would involve the following checks normally:
[16:11] <coolbhavi> Checking licenses of all the files in the tarball (licensecheck -r --copyright command)
[16:11] <coolbhavi> Checking if all the patches in the previous version are perfectly applicable or obsolete
[16:12] <coolbhavi> Checking if there are new dependencies required for the new version of the package (this is usually reported in upstream ChnageLog, but sometimes you only discover it by looking at upstream autoconf files (or Makefile))
[16:12] <coolbhavi> Checking if the package installs files in a different manner for instance, any change in file locations (We may need to change our packaging then)
[16:13] <coolbhavi> Checking if the package has a man page, desktop file, icons et al and we may want to install those or for ex. there is a .desktop file already existing we may want to validate the same. (desktop-file-validate)
[16:13] <coolbhavi> sometimes upstream changes few things which need you to change compilation flags
[16:14] <coolbhavi> if upstream is a library particular care has to be taken
[16:14] <coolbhavi> checking if API/ABI change is reflected in SONAME/version (More on SONAME here: http://en.wikipedia.org/wiki/Soname)
[16:15] <coolbhavi> (check-symbols command can help you in that)
[16:15] <coolbhavi> you may need a library transition, which involves perhpas rebuilding many packages already in the archive
[16:16] <coolbhavi> Perhaps at this point its better to go through a simple example for us to get started hands on :)
[16:16] <coolbhavi> I hope I am not speeding up the session
[16:17] <coolbhavi> Okay  lets get started with our hands on :)
[16:18] <coolbhavi> The package I am using as an example is my own debian package mobile-broadband-provider-info (Which I havent updated in quite sometime due to my schedule of things lately)
[16:19] <coolbhavi> Type in a terminal mkdir m-b-p-i && cd m-b-p-i &&  dget -x https://launchpad.net/ubuntu/+archive/primary/+files/mobile-broadband-provider-info_20111113-1ubuntu1.dsc
[16:19] <coolbhavi> Which will download the latest available version in ubuntu i.e 20111113-1ubuntu1 (Note: I'm not using apt-get source mobile-broadband provider info as it will download the respective SRU versions for oneiric,natty,maverick or lucid)
[16:20] <coolbhavi> I ll wait for sometime now for those who are downloading the package
 QUESTION: I'm getting an error Validation FAILED!!
[16:22] <coolbhavi> obounaim, please do gpg --recv-keys <the key ID due to which package is failing to validate>
[16:22] <coolbhavi> and retry  dget -x https://launchpad.net/ubuntu/+archive/primary/+files/mobile-broadband-provider-info_20111113-1ubuntu1.dsc
[16:23] <coolbhavi> or simple one pull-lp-source  mobile-broadband-provider-info
[16:25] <coolbhavi> so assuming everything is fine lets move on
[16:26] <coolbhavi> now if you do a cd mobile-broadband-provider-info-20111113/ and look in you will find a debian directory and most of our work is concentrated in around the debian directory normally
[16:27] <coolbhavi> now if you look inside the debian directory you will see a changelog control mobile-broadband-provider-info.docs copyright rules watch files and a source directory
 QUESTION: bzr branch lp:ubuntu/mobile-broadband-provider-info  will work?
[16:29] <coolbhavi> yes it will but m not explaining distributed devel method herr :)
[16:30] <coolbhavi> its a more conventional explanation here for a start off :)
[16:31] <coolbhavi> obounaim, QUESTION: i don't have the mobile-broadband-provider-info-20111113/ directory ?
[16:31] <coolbhavi> Please make sure you extracted the source properly
[16:34] <coolbhavi> ok so now moving on, inside the source directory you will find a file called format which contains something as "3.0 (quilt)" which specifies that this is a dpkg-source version 3.0 package
[16:34] <coolbhavi> Now if you look at the watch file it states that its a dummy watch file (which I created to satisfy lintian as the package is maintained and updates are pushed into git and no orig tarball is available for same for a dynamic update (once in 1 month, 2 months))
[16:35] <coolbhavi> Now since the debian/watch file is unavailable if you take a look at debian/rules file you can see that we have defined a get-orig-source target.
[16:37] <coolbhavi> Now to parse through the get-orig-source rule you saw in debian/rules, you need to install automake and git-core packages as specified in the debian/rules file
[16:39] <coolbhavi> assuming there are no doubts at this point, lets move on
[16:41] <coolbhavi> So, running make -f debian/rules get-orig-source inside mobile-broadband-provider-info-20111113/ directory will download the latest version of the changes in git-head and converts the same to a  tarball mobile-broadband-provider-info-20120201 and untars it creating a directory mobile-broadband-provider-info-20120201 going by the sequence of commands under get-orig-source in debian/rules
[16:42] <coolbhavi> Now since there are no changes or patches outside the debian directory copy the debian directory from mobile-broadband-provider-info-20111113/ to mobile-broadband-provider-info-20120201/
[16:43] <coolbhavi> Once done navigate to the debian directory in the new source tree and type dch -i and give a version as 20120201-0ubuntu1 (-0ubuntu1 since this version is not present yet in debian but in ubuntu) targetted to precise since that is the devel version presently
[16:46] <coolbhavi> (Looks something like mobile-broadband-provider-info (20120201-0ubuntu1) precise; urgency=low)
[16:46] <coolbhavi> And update the changelog as * Merging upstream version 20120201 from git and make a list of upstream changes mapping the LP bugs closed in the changelog (Changelog writing will be taken up as a seperate topic by myself tomorrow where I'm going to explain changelog writing specifics)
 QUESTION: I heard about fakeroot. What's difference between fakeroot debian/rules ~ and make -f debian/rules ~ ?
[16:50] <ClassBot> There are 10 minutes remaining in the current session.
[16:50] <coolbhavi> jincreator1, make -f uses make command on debian/rules as a file (see man make) and  fakeroot runs the same command in a env faking root previlages for execution
[16:50] <coolbhavi> as per my understandingf
[16:51] <coolbhavi> Once done, Save the file and then type debuild -S -sa (Which builds the package along with the new tarball included)
[16:51] <coolbhavi> Some steps to gain additional points :)
[16:52] <coolbhavi> After that a dsc and a changes file will be generated. Use pbuilder to test build the generated dsc file in a pristine environment (A session is coming up on the same tomorrow by tumbleweed)
[16:53] <coolbhavi> And then do a diff between the old source tree and the new source tree for example bhavani@bhavani-desktop:~/m-b-p-i_1$ diff -Nurb mobile-broadband-provider-info-20111113 mobile-broadband-provider-info-20120201 > m-b-p-i.diff and attach the diff and the new source tarball to the new upstream request bug in LP. (my preferred way as a sponsor!)
[16:54] <coolbhavi> Once done, Please subscribe the ubuntu-sponsors team to evaluate the same :)
[16:55] <coolbhavi> Once evaluated the package will be uploaded and a new upstream version lands in ubuntu archives
[16:55] <ClassBot> There are 5 minutes remaining in the current session.
[16:55] <coolbhavi> Any more questions?
[16:56] <coolbhavi> Thanks all of you for turning up :) Please feel free to hang out at #ubuntu-motu or #ubuntu-devel for any questions.
[16:57] <coolbhavi> You can also catch me up on<EMAIL_ADDRESS>or facebook.com/bshankar
[16:57] <coolbhavi> Thanks all again! Thats it from my side :) See you tomorrow!
[17:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[17:01] <m_3> hi all
[17:01] <m_3> I'm Mark... and I'm a <borat>CharmingGuy</borat>
[17:01] <m_3> so I'd like to cover:
[17:02] <m_3> - basic intro to juju and service orchestration
[17:02] <m_3> - anatomy of a charm
[17:03] <m_3> rather than concentrate on a single charm, I'll give examples from several different charms for common services that most will be familiar with
[17:04] <m_3> I'll be chatting here, and using a juju-classroom in ec2 to show examples
[17:09] <m_3> argh!
[17:09] <m_3> sorry, conference wifi just cut me off
[17:10] <m_3> ok, so I was saying you can see examples with either a browser or ssh... lemme paste the url:
[17:10] <m_3> ec2-107-21-156-68.compute-1.amazonaws.com
[17:10] <m_3> you can go there in a browser and log in with guest/guest
[17:11] <m_3> or ssh directly there w/ same user/pass
[17:11] <m_3> ok, so juju is a new set of devops tools baked into ubuntu server
[17:11] <m_3> it's a fundamentally new paradigm in devops
[17:11] <m_3> it's not concerned with just configuring machines or automating that process
[17:12] <m_3> it takes it to the next level of looking at your entire infrastructure as a set of services
[17:12] <m_3> services with varied lifecycles that interact with each other
[17:13] <m_3> examples of services... applications, load balancers, databases, monitors, storage, caches, etc
[17:13] <m_3> the list goes on and looks different for different people
[17:14] <m_3> well juju's about maintaining stacks of services within your infrastructure
[17:14] <m_3> take a simple example
[17:15] <m_3> gimme a sec to get reconnected to it
[17:15] <m_3> ok, now in the ec2 instance, you can see a simple stack of services
[17:15] <m_3> this is what the end-user's view of juju will be
[17:16] <m_3> juju bootstrap
[17:16] <m_3> juju deploy [options] service
[17:16] <m_3> juju add-relation service1 service2
[17:16] <m_3> juju expose service
[17:17] <m_3> the last step exposes the service to the outside world (you typically want this to happen ina gated manner)
[17:17] <m_3> that's a stack that deploys a mongo database, a node.js app, and relates the two
[17:18] <m_3> there's some additional stuff commented out that hints at where we can go next with this
[17:18] <m_3> adding extra services and then scaling service units out
[17:18] <m_3> but that's the basic process
[17:18] <m_3> bootstrap, deploy, relate, expose
[17:18] <m_3> so the way juju represents services is through templates we call charms
[17:19] <m_3> there are charms for all sorts of standard services
[17:19] <m_3> mongo, ganglia, mediawiki, mysql, etc etc
[17:19] <m_3> the list is growing every day
[17:20] <m_3> so these charms "distill" the best-practices of the devops peeps that've been working with those services
[17:20] <m_3> some charms are simple package type installations
[17:21] <m_3> some charms are really complex sets of packages, pulls from repos, and templated code
[17:21] <m_3> so these charms "distill" the best-practices of the devops peeps that've been working with those services
[17:21] <m_3> sorry, paste-barf
[17:21] <m_3> the most complex example I can think of at the moment is openstack
[17:22] <m_3> we've got charms built (nod to adam_g) that deploy openstack on bare-metal clusters using juju
[17:22] <m_3> we'll start with simple ones in a bit
[17:23] <m_3> so juju orchestrates services
[17:23] <m_3> represented as charms
[17:23] <m_3> it's essentially a low-level eventing framework as we'll see
[17:24] <m_3> take a look at a more mature stack for a sec (ec2 example)
[17:25] <m_3> this is a more realistic infrastructure than most examples you deal wth
[17:26] <m_3> we're going to delve into the anatomy of charms in some detail, but the big picture is that these charms can be combined into larger stacks of services
[17:26] <m_3> ok, so next is anatomy of a charm
[17:27] <m_3> I'll pause for questions on juju in general before we do that though
[17:27] <m_3> #question
[17:27] <m_3> hmmm... ok, that's not it... I'll check out #ubuntu-classroom-chat
[17:28] <m_3> I got a "this is going to be over our heads"
[17:28] <m_3> and a question "what is juju built on"
[17:29] <m_3> totally not over your heads... wait til you see the charms themselves
[17:29] <m_3> they can be written in any language
[17:29] <m_3> and it's got a really great learning curve
[17:29] <m_3> juju's a basic eventing framework
[17:29] <m_3> uses twisted in the agents
[17:30] <m_3> and uses zookeeper to keep track of it all
[17:31] <m_3> yeah, it's communicating through ssh using std key-injection for most cloud providers
[17:31] <m_3> it runs on ec2, hpcloud, openstack, almost eucalyptus, lxc, bare-metal
[17:32] <m_3> so single-server installs are possible
[17:32] <m_3> just depends on your resources
[17:33] <m_3> an example... I was just developing more on the mongo-node app
[17:33] <m_3> typical production stack for that would be haproxy head, dozen node instances, and a 4-instance mongo replset
[17:33] <m_3> on my local machine, I'll just run a single mongo and a single node instance
[17:34] <m_3> we'll see how the charms scale out ina sec
[17:35] <m_3> ok, so great questions
[17:36] <m_3> let's look at the anatomy of a charm and I think it'll be a little clearer how the events work
[17:36] <m_3> so think about the configuration for a typical service
[17:36] <m_3> there' stuff you gotta do to just get it installed on the box
[17:37] <m_3> sometimes that's super-simple
[17:37] <m_3> (example)
[17:37] <m_3> the 'open-port' is a juju primitive
[17:37] <m_3> sometimes installation isn't so simple
[17:38] <m_3> juju lets you install services on ubuntu service from packages, of course
[17:38] <m_3> but it also lets you easily install using other methods
[17:38] <m_3> like npm
[17:39] <m_3> or gems
[17:39] <m_3> if your app needs a version of django or rails that isn't in the repos
[17:39] <m_3> then you can install it
[17:39] <m_3> of course you can shoot yourself in the foot
[17:40] <m_3> we take pains to insure the shared charms in the charmstore are somewhat safe
[17:40] <m_3> cryptographically verified payloads, peer reviews, tests
[17:41] <m_3> but ultimately, pretty much anything goes in a juju charm
[17:41] <m_3> so a charm for a service is just a handful of hooks
[17:41] <m_3> (see example)
[17:42] <m_3> install, start, stop, upgrade-charm
[17:43] <m_3> the hooks in this example are all shell script
[17:43] <m_3> but they can be written in anything you'd like
[17:43] <m_3> just need an interpreter/runtime on the instance
[17:43] <m_3> heck, you could even write them in clojure
[17:44] <m_3> you just have to make sure the first "install" script bootstraps that executable env
[17:44] <m_3> binary hooks are cool too
[17:44] <m_3> although for the official ones in the charm store, we'd need transparency
[17:45] <m_3> now each service relates to other services
[17:45] <m_3> this is specified in the metadata for the charm
[17:46] <m_3> what sort of services can plug in to this one... is specified in the provides and requires interfaces
[17:46] <m_3> they have to match
[17:46] <m_3> mysql provides a db:mysql interface
[17:47] <m_3> other services such as mediawiki consume this with a requires section
[17:47] <m_3> juju uses these interface definitions (they're loose, you can make up your own) to wire service units together
[17:48] <m_3> and there are hooks to be called when that happens
[17:48] <m_3> so let's go over basic lifecycle...
[17:49] <m_3> juju spins up mysql (juju deploy --repository ~/charms local:mysql)
[17:49] <m_3> juju spins up mediawiki (..)
[17:50] <m_3> for each of these services... juju spins up a new instance, calls the "install" and "start" hooks in the respective charms
[17:50] <ClassBot> There are 10 minutes remaining in the current session.
[17:50] <m_3> next, we 'juju add-relation mysql mediawiki' and then the magic begins
[17:51] <m_3> ok, so it's not magic... it's just juju calling the relation hooks for each of those services
[17:51] <m_3> it also lets these relation hooks talk to each other
[17:51] <m_3> that's the real win IMO
[17:52] <m_3> think of the stuff you have to do to set up a service
[17:52] <m_3> juju separates this into the stuff you have to do for installation
[17:52] <m_3> and the stuff you have to do for relation
[17:52] <m_3> it's typically quite isolated... I'm learning
[17:52] <m_3> installing mediawiki
[17:52] <m_3> installing mysql
[17:53] <m_3> but _relating_ them is just:
[17:53] <m_3> create a new db on mysql
[17:53] <m_3> hand over the creds to access this db to the other service
[17:53] <m_3> that's all they really have to know about each other
[17:53] <m_3> (example)
[17:54] <m_3> ok, that's more detail than we need
[17:54] <m_3> simpler example... pgsql
[17:55] <m_3> there that's it
[17:55] <m_3> create a user/passwd/db
[17:55] <ClassBot> There are 5 minutes remaining in the current session.
[17:55] <m_3> and then "relation-set" is a juju primitive that lets this hook hand the info over to the other end of the relation (mediawiki in this case)
[17:57] <m_3> mediawiki will have corresponding 'relation-get's where it just saves that out to /etc/mediawiki/...
[17:57] <m_3> ok, heading to ubuntu-classroom-chat for questions
[17:59] <m_3> also, if you look at nothing else with juju... totally check out the 'juju debug-hooks' command
[17:59] <m_3> it opens a tmux session on the service unit and spawns a new session for each hook as it execs (with the hook's exec env)
[17:59] <m_3> it's cool!
[18:00] <m_3> so there's juju.ubuntu.com/Charms to see these in detail
[18:00] <m_3> yikes... outta time
[18:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[18:00] <m_3> thanks for your attention!
[18:00] <Effenberg0x0> Hi everyone, It's a pleasure to be at UDW. Thank you all for being here! My name is Alvaro Leal (my user name is Effenberg0x0). As you are (probably) aware, we'll be talking about runing the Development Release: Ways to do it, common pitfalls, some tips, how stable it is right now, etc.
[18:01] <Effenberg0x0> So, let me introduce myself first. I have been working in IT for 50% of my life (I'm 32, so that's somewhat relevant for me!). My first job was with Solaris (later SunOS) and I got to try Linux by using Conectiva Linux (later Mandrake/Mandriva) for some years, until I tested Ubuntu in 2005 (Hoary) and never left it. Regarding development, work has requested me to focus on HTML+PHP, C+WinAPI (I've been a Dev-C++ user for a long time) and s
[18:01] <Effenberg0x0> ome (unnecessarily large) shell (mainly Bash) scripting (prototyping).
[18:01] <Effenberg0x0> My current job involves providing market intelligence services to some of the largest global IT companies and, in parallel, coordinating tests and developing for research databases analytic software. I've been active in many Linux and general IT forums in my country (Brazil) but, for the last two cycles, I have focused exclusively in UbuntuForums and its Ubuntu+1 area. So, long story short, that's how I got to testing Ubuntu. It's my firs
[18:01] <Effenberg0x0> t time hosting a session so, please, be nice :)
[18:01] <Effenberg0x0> Also joining us is Cariboo907, a Forum Admin and Forum Council Member at UbuntuForums. He's been active in the forums for a long time and specifically in the U+1 area for most of the last development cycles. He's here to help and will be answering questions too, so don't feel shy and ask everything you want (relevant to using the development release, please!).
[18:01] <cariboo907> Hi everyone, I'm sure most of you know me, or of me
[18:02] <cariboo907> Welcome
[18:02] <Effenberg0x0> So I have mentioned UbuntuForums and U+1. What is the U+1 area of UbuntuForums? It's a place where a growing group of regulars join to post their perceptions, doubts and workarounds regarding every update to the development release of Ubuntu.
[18:02] <Effenberg0x0> From day one of every development cycle,  these guys test the installation of the ISOs (Ubuntu flavors - Ubuntu, Kubuntu, Lubuntu mostly and x86/x86_64) and update their OSs many times a day, reporting back to the forum when something goes wrong. Hopefully, the others can help in reproducing the reported behavior and finding out the origin of the problem (sometimes even a workaround).
[18:03] <cariboo907> !q
[18:03] <Effenberg0x0> One of the contributions of this team is that they can provide the community with higher value-added and more precise Launchpad bug reports, which potentially makes the work of developers easier. We're also open for receiving specific test tasks from developers and the QA team. And we're ready to provide help to any of you if you happen to encounter any specific problem when using the development releases of Ubuntu.
[18:03] <Effenberg0x0> I'd like to talk a little about the importance of testing the development release. It's a huge contribution to the community and something mostly anyone can do, as it requires no specific knowledge. The Testing Team has a wiki at https://wiki.ubuntu.com/Testing.
[18:04] <Effenberg0x0> The activities include ISO Testing, Stable Release Testing, Feature Testing, General Testing, Application Testing, Automated Testing, Laptop Testing and, of course, reporting bugs found during this processes in Launchpad and following up with them. So there are activities for all tastes and skill levels.
[18:04] <Effenberg0x0> Each activity is not hard or time consuming but, as you can see, all these activities together compose a great load of work, so help is welcomed.
[18:04] <Effenberg0x0> So, PLEASE :) Be a part of it.
[18:05] <Effenberg0x0> Among all these activities of the Testing Team, I'd like to mention ISO Testing. As we approach a CD Release (Alpha, Beta, RCs, etc) it is really important to do the ISO testings. There are instruction on ISO Testing procedures at https://wiki.ubuntu.com/Testing/ISO/Procedures and a Testcases Wiki is hosted at https://wiki.ubuntu.com/Testing/ISO/Procedures.
[18:05] <Effenberg0x0> If all of you could dedicate a couple minutes to go through these links and give some consideration to supporting the Test Team, I would mean a lot to the community.  It's great way to get involved.
[18:06] <ClassBot> metasansana asked: Effenberg0x0 can you slow down a bit please?
[18:07]  * Effenberg0x0 will slow down, as requested by ubuntu-classroom users :)
[18:09] <Effenberg0x0> Enough with the introduction part of it: Let's get down to the business at hand, which is running the development release. I'll be posting a lot of information we prepared and then we'll open for questions. As you know, logs will be available online, so there's no need to take note of URLs, commands or anything right now.
[18:10] <Effenberg0x0> Ok, lets proceed. We know there's a focus on getting more people into developing software for Ubuntu (see http://developer.ubuntu.com/ and http://www.ubuntu.com/community/get-involved/developers). And considering the growing popularity of this platform, many developers are coding for it now. One of the concerns we see among this group is how they can run the development release without facing serious bugs and breakages.
[18:11] <Effenberg0x0> Let me start by saying that there is a consensus about the overall stability in the Precise Pangolin cycle.  From its start (with the upload of the toolchain in Oct 13th) to now, only a few users have faced serious breakages that lead to a lockout / reinstall. This is no coincidence. On Nov. 2011, a list of priorities and specs for the Development Releases was created and it included one important rule: Keep releases usable from day to da
[18:11] <Effenberg0x0> y (see https://blueprints.launchpad.net/ubuntu/+spec/other-p-plusonemaint-priorities and  https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Specs/Priorities).
[18:12] <Effenberg0x0> So, as you can see, these specs try to make sure you'll have a installable system and buildable packages at any given moment.  So, as developers, you'll also want to take those guidelines under consideration.
[18:13] <Effenberg0x0> Of course, it is not bulletproof and we do face some updates that eventually break this or that . But, most of the time,  PP has been succeeding into keeping the system viable enough for its use and test. While this is ***absolutely not recommended at all***, many users are working with PP in their production machines.
[18:14]  * Effenberg0x0 is running it right now: xchat, vmware-player x 4 VMs, Eclipse Juno, about 20 firefix tabs, rhythmbox, Nixnote, Thunderbird and everything is fine (uptime is more than 5 days)
[18:14] <Effenberg0x0> firefix=firefox :)
[18:14] <Effenberg0x0> Then what are the options to use PP safely? We'll discuss a few as every user/developer will generally choose what fits its preferences best. They are numbered from 1 (less risky) to 5 (more risky).
[18:15] <Effenberg0x0> Some are obvious to most people, some are not. But it's important to mention them.
[18:16] <ClassBot> kanliot asked: I'm used to lubuntu.  is the PP testing, and reporting the same for Lubuntu?  Or is the schedule a little differnt?]
[18:17] <cariboo907> Seeing as Lubuntu is now an official part of the Ubuntu family reporting and scheduling is the same
[18:17] <cariboo907> for all versions, except for kubuntu which has it's own bug tracker
[18:18] <Effenberg0x0> kanliot, they host a page with specific info for testing Lubuntu: https://wiki.ubuntu.com/Lubuntu/Testing
[18:19] <Effenberg0x0> So, proceeding with the common ways to test Ubuntu and its flavors:
[18:19] <Effenberg0x0> 1) Separate PC: Considering you have an extra PC that fits the specs to run the development release (see https://wiki.ubuntu.com/DesktopExperienceTeam/UnityHardwareRequirements and https://wiki.edubuntu.org/DemystifyingUnityGraphicsHardwareRequirements) this is the safest choice. You can run your favorite IDE in your main PC, remotely access the test machine via Samba, SSH, FTP, NFS, Git, SVN, or any other protocol and even run remote GDB
[18:19] <Effenberg0x0>  sessions. There's extensive documentation in doing all of those in the Ubuntu Online documentation. In the case of PP Server, you can also consider using a Cloud Service Provider.
[18:20] <Effenberg0x0> This is the "ideal" way, of course. But not everyone has extra machines at their disposal.
[18:20] <ClassBot> There are 10 minutes remaining in the current session.
[18:20] <Effenberg0x0> 2) Virtual Machines: During the last two cycles many people have adopted VirtualBox and VMWare-Player as platforms for testing the development release. There's some discussion as to how valid these tests are, since the Operating System is actually accessing virtualized (and not real) hardware. But, if you, as a developer, does not need to access hardware in a low level (and that's generally the case), you can test using a VM just fine.
[18:20] <Effenberg0x0> ABout VMs:
[18:20] <Effenberg0x0> A Virtual Machine with  1 or 2 GB of RAM and about 30GB of dynamic disk space is more than enough to test both Unity and unity-2D desktops, as well as the other flavors such as Lubuntu and Kubuntu. Installing VirtualBox is easy, as all you have to do is sudo apt-get install virtualbox. In the case of VMWare-Player, you need to download the VMWare-Player bundle (a binary file) from VMWare website, chmod it +x and run its install procedure.
[18:20] <Effenberg0x0>  VMWare does have some problems compiling its Kernel modules in the 3.2.x kernel series. But I have made patches available to it, as well as instructions on how to use these patches, and they are posted at UbuntuForums U+1 area. Just search for +Effenberg0x0 +VMWare +Patch and apply the patches if you need to. I can help anyone that falls into trouble installing VMWare-Player on Kernel 3.2.0, just post something at that thread @ UbuntuFor
[18:20] <Effenberg0x0> ums..
[18:21] <ClassBot> obounaim asked: do you i always need to download the last ISO to test or doing updates will be fine ?
[18:21] <Effenberg0x0> And also its important to mention test drive
[18:21] <Effenberg0x0> obiwlan, DOing the updates is fine for testing instalation, applications.
[18:21] <Effenberg0x0> BUt if you want to test the ISO itsef, you have to download it
[18:21] <Effenberg0x0> Something that not everybody knows: Ubuntu has its own testing application, named TestDrive. It is available via Software Center. You can install it using sudo apt-get install testdrive. It downloads/syncs the requested Ubuntu release ISO and starts a Qemu / VirtualBox VM so you can test the latest Ubuntu in an easy and safe way. I recommend using VirtualBox for a single reason: It is capable of OpenGL acceleration. So, it allows you test
[18:21] <Effenberg0x0>  Unity. Running Qemu and VMWare Player will only allow you to run Unity-2D in the VMs. Ubuntu has great documentation for all these options. Check https://help.ubuntu.com/community/VirtualBox, https://help.ubuntu.com/community/VMware/Player and https://launchpad.net/testdrive.
[18:22] <Effenberg0x0> Test drive can actually download the images, sync them to the latest, and create the testing VM for you.
[18:22] <Effenberg0x0> just sudo apt-get install testdrive to try it
[18:23] <Effenberg0x0> 3)  Separate HDD: Also one of the safest options. We all know it's easy to install Ubuntu to a secondary drive, which can be an internal / external HDD and even an USB/eSATA unit. Ubuntu setup is very easy and clear in how to do this, but information is also available in the documentation. See https://help.ubuntu.com/community/InstallingANewHardDrive for example.
[18:23] <Effenberg0x0> 4) Separate HDD Partition: This means you'll have your standard OS installed to /dev/sda1 and PP installed to /dev/sda3 (for example). Same as when using a separate HDD, it should be dealt properly by Ubuntu install. There's no mystery to it.
[18:23] <ClassBot> metasansana asked: what about kvm for virtulisation?
[18:23] <Effenberg0x0> These two ways above have absolutely no mystery: Ubuntu default install handles it normally. But of course, they are ore risky than runing it in a separate PC or VM.
[18:24] <cariboo907> kvm or any of ther vms work well
[18:24] <Effenberg0x0> metasansana: You can use KVM too, but if you'd like to see Unity effects, AFAIK, you have to use VirtualBox, as it provides some hardware acceleration.
[18:25] <ClassBot> There are 5 minutes remaining in the current session.
[18:25] <Effenberg0x0> 4) Separate HDD Partition: This means you'll have your standard OS installed to /dev/sda1 and PP installed to /dev/sda3 (for example). Same as when using a separate HDD, it should be dealt properly by Ubuntu install. There's no mystery to it.
[18:25] <Effenberg0x0> oops
[18:25] <Effenberg0x0> Another important tip: Few people are familiar with ZSync. It allows you to sync your current image file to the new daily ISO at every time. Only the changed parts of the image will be downloaded, saving time and bandwidth. All the info on how to use ZSync is at https://help.ubuntu.com/community/ZsyncCdImage .  It really helps a lot. RSync can also be used, and the URL above has the (easy) instructions on how to do it in a single command.
[18:26] <Effenberg0x0> This is actually what most people do, as you can save a lot of time and bandwidth for downloading the daily ISOs
[18:26] <Effenberg0x0> (and it's how testdrive works too - syncyng the ISO)
[18:27] <Effenberg0x0> Ok, I'll post now some of the main tips we have for running the development release. We're almost out of time, so excuse for pasting it relly quick. It will be available in logs for you on those who cuoldn't be here today.
[18:27] <Effenberg0x0> We'll answer questions in the ubuntu-classroom-chat channel after this session.
[18:27] <Effenberg0x0> 1. The most important thing: Backup. Always. And do it to a safe and external media. Backing up data to the same partition in use in the installation is too risky. Use an external HDD, a USB drive, a separate partition, a network drive, anything. But NEVER forget to backup. It doesn't really matter if you use dejadup, backintime, or tar and rsync, as long as you manage to keep your important data safe. I have created my own bash script to
[18:28] <Effenberg0x0>  backup stuff I find relevant and rsync it to a network storage, and added it to a cron schedule. But the tools I mentioned have GUI options that allow anyone to easily create a proper backup config and schedule.
[18:28] <ClassBot> kanliot asked: so i could install lubuntu from the image every day, and use it?
[18:28] <cariboo907> oops
[18:29] <cariboo907> kanilot you could if you wanted to
[18:29] <cariboo907> but there really is no need just do daily updates using the software center synaptic of the command line
[18:30] <cariboo907> or the command line
[18:30] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[18:30] <cariboo907> thanks everyone
[18:30] <tumbleweed> Hi everyone, I'm Stefano Rivera, an Ubuntu MOTU and Debian Developer
[18:31] <tumbleweed> I live in South Africa, and have been actively working on Ubuntu & Debian for 3 years or so
[18:31] <tumbleweed> I'm here to talking to you about Working with Debian
[18:31] <tumbleweed> This is a short session (30 mins) so I've prepared some notes and will go fast. Maybe there'll be time for examples at the end, probably not
[18:31] <tumbleweed> Laney will take a second session on doing work for Ubuntu *in* Debian, later tonight
[18:31] <tumbleweed> Reminder to please ask any questions in #ubuntu-classroom-chat, and start them with QUESTION:
[18:31] <tumbleweed> In fact, if you're listening, please wave in #ubuntu-classroom-chat, so I know how full the room is :)
[18:32] <tumbleweed> == Why work with Debian? ==
[18:32] <tumbleweed> err
[18:32] <tumbleweed> Right, that's the formalities, let's get moving
[18:32]  * tumbleweed waves to Kerbero, from my LoCo team :)
[18:32] <tumbleweed> If you followed dholbach's introductory sessions yesterday, you'll know that Ubuntu is largely (~75%) unmodified Debian source packages, rebuilt
[18:32] <tumbleweed> We like to keep it this way, because we don't actually have that many developers (~170 with upload rights, compared to Debian's ~900), and it makes sense to avoid duplicating work
[18:33] <tumbleweed> You may not think of yourself as a Debian user, and you probably want to spend your time improving Ubuntu, not Debian, but improving Debian improves Ubuntu.
[18:33] <tumbleweed> So, where possible, when issues affect both Debian and Ubuntu, we like to get them fixed in Debian and let the fix flow to Ubuntu
[18:34] <tumbleweed> If it's too urgent for that in Ubuntu, we can fix it directly in Ubuntu, until the next Debian version brings the fix
[18:34] <tumbleweed> Or if bringing in the next Debian version would bring in some undesired bits (e.g. after Feature Freeze, bring in new features), we can apply the fix directly in Ubuntu, and get the new version from Debian next cycle
[18:34] <tumbleweed> debian and ubuntu don't have synchronised release cycles, so this kind of thing happens quite often
[18:35] <tumbleweed> have I  convinced everyone why you should care about debian, and submit patches there (or even upstream, when possible)?
[18:35] <tumbleweed> I hope so
[18:35] <tumbleweed> == Maintainership ==
[18:35] <tumbleweed> That's the motivation, now for a little discussion on the differences in culture between Debian and Ubuntu
[18:36] <tumbleweed> In Debian, every package has a maintainer who (hopefully) cares for it. The maintainer gets e-mail for all the bugs filed against the package, and is responsible for looking after it
[18:36] <tumbleweed> In Ubuntu, we don't have strong maintainership, anyone can upload any package without having to ask anyone else (except for some core packages, where we have people / teams that know them really well and probably want to talk to you first)
[18:36] <tumbleweed> (ok, obviously you need upload rights to upload in debian or ubuntu, but both distributions have sponsorship proceses for new developers without upload rights. And we all started there)
[18:37] <tumbleweed> Debian also has some teams (they are becoming more common), but every package will also have a human maintaining it
[18:37] <tumbleweed> You can see who maintains a package by looking it up in the Package Tracking System (PTS) (or by doing an apt-cache showsrc)
[18:37] <tumbleweed> The PTS URL is http://packages.qa.debian.org/SRC_PACKAGE_NAME
[18:37] <tumbleweed> I'm referring to source packages everywhere, because that's what developers deal with. Source packages build binary packages, we fix the bugs in the source packages.
[18:38] <tumbleweed> e.g. here are some packages I maintain:
[18:38] <tumbleweed>  http://packages.qa.debian.org/beautifulsoup
[18:38] <tumbleweed>  http://packages.qa.debian.org/pypy
[18:38] <tumbleweed> You can see links to the equivalent Ubuntu pages in Launchpad, in the Ubuntu box on the right: http://pad.lv/u/beautifulsoup http://pad.lv/u/pypy
[18:39] <tumbleweed> any questions about that? anyone never come across source packages before?
[18:40] <ClassBot> kanliot asked: i've never submitted a patch to a maintainer.  what do i need to put in the email
[18:40] <tumbleweed> right, good question
[18:40] <tumbleweed> it depends a little on what the patch is for
[18:40] <tumbleweed> if it's a packaging change, you should say why it's necessary
[18:41] <tumbleweed> if it's an issue that only affects Ubuntu, not Debian, you should probably say so, and mark the bug minor/wishlist (the maintainer has no obligation to care about Ubuntu :P )
[18:42] <tumbleweed> generally, it should asy everything that a good bug report usually says (google for how to write a good bug report)
[18:42] <tumbleweed> what causes the problem, what the problem is, how you propose fixing it
[18:42] <ClassBot> obounaim asked: where can i find packages to maintain?
[18:42] <tumbleweed> if you want to take over maintainance of packages yourself, you can look at the list of orphaned packages
[18:43] <tumbleweed> http://wnpp.debian.net/
[18:43] <tumbleweed> packages which are "O" are orphaned
[18:43] <tumbleweed> "RFH" is a request for help, such as help triaging bugs
[18:43] <tumbleweed> or help co-maintaining it
[18:43] <tumbleweed> almost all big packages need help like that, all the time
[18:44] <tumbleweed> "RFA" is request for adoption. The current maintainer would like to hand it over to someone, but still cares enough, not to orphan it
[18:44] <tumbleweed> and of coures, anyone can propose to bring in new packages, and maintain them
[18:44] <tumbleweed> see the debian new maintainers guide for more details on that bit
[18:45] <ClassBot> Ceno asked: I'm developing a free software application and intend to directly support Ubuntu by providing a PPA. Should I register as a maintainer and put together a package and publish for debian first and then somehow create a PPA where I treat my software as an external, upstream project?
[18:45] <tumbleweed> Ceno: I don't see how that's directly relevant to working with Debian
[18:45] <tumbleweed> but if you want to get your package into Ubuntu eventually (rather than just keep it in a PPA)
[18:46] <tumbleweed> then getting into debian is a very good idea
[18:46] <tumbleweed> Debian is generally a better distribution for maintaining ones onwn packages (the strong maintainership I mentioned)
[18:46] <ClassBot> metasansana asked: Are there any copyright or legal issues to be aware of when becomming the maintainer for a package?
[18:46] <tumbleweed> metasansana: You are effectively the person responsible for it
[18:47] <tumbleweed> it's up to you as the maintainer to review that everything within the package meets the Debian Free Software Guidelines
[18:48] <tumbleweed> I've never heard of anyone being sued for screwing up there, but packages certainly get removed fro containing non-free bits
[18:48] <tumbleweed> (the ftp-masters do a licencing check, but it's only a check)
[18:48] <tumbleweed> hope that answers that
[18:48] <ClassBot> obounaim asked: What about Ubuntu where can i find packages to maintain?
[18:48] <tumbleweed> most packages in Ubuntu could use some love
[18:49] <tumbleweed> pick something that has lots of open bugs, and go through them
[18:49] <tumbleweed> harvest.ubuntu.com is a great place to find things
[18:49] <tumbleweed> subscribes to bugs from packages that you care about
[18:49] <tumbleweed> *subscribe
[18:49] <tumbleweed> ok, let's press on
[18:49] <tumbleweed> == Debian's Bug Tracker ==
[18:49] <tumbleweed> If you look at the top right hand corner of a PTS page, you'll see a bugs box, this gets you to the right bit of Debian's Bug Tracking System (BTS)
[18:49] <tumbleweed> they're broken down into totals by severity
[18:50] <tumbleweed> most packages have very few bugs, so the "all" link is what you want
[18:50] <tumbleweed> You can also go directly to http://bugs.debian.org/src:SRC_PACKGAGE_NAME or http://bugs.debian.org/BUG_NUMBER
[18:50] <tumbleweed> Unlike Launchpad (although it also has e-mail support), the BTS is driven *entirely* by e-mail
[18:50] <tumbleweed> You don't have to register for anything
[18:50] <ClassBot> There are 10 minutes remaining in the current session.
[18:50] <tumbleweed> you don't need any special permissions
[18:50] <tumbleweed> you can just e-mail any bug
[18:50] <tumbleweed> Each bug is filed by sending a specially formated to e-mail to the BTS, and all comments are just replies to the bug's e-mail address.
[18:51] <tumbleweed> Here's an example: http://bugs.debian.org/505442
[18:51] <tumbleweed> You can see that I replied to the bug and included some commands to modify the bug (and I CC-ed a special address that parses those commands)
[18:51] <tumbleweed> You can find out more about the gorey details here: http://www.debian.org/Bugs/ or in last year's UDW session by Rhonda: https://wiki.ubuntu.com/MeetingLogs/devweek1103/GettingYourFixesIntoDebian
[18:51] <tumbleweed> most of the time, you don't need the fancy bits, and can just reply to e-mail
[18:52] <tumbleweed> Debian users report bugs with the "reportbug" tool. You should probably use that, or our "submittodebian" tool (in ubuntu-dev-tools)
[18:52] <tumbleweed> To modify bugs, you may want to use the "bts" tool (in devscripts) (and, if you use mutt, bts show -m is pure awesome)
[18:52] <tumbleweed> You'll need to set up a way for these tools to send e-mail
[18:52] <tumbleweed> The first time you run submittodebian, it'll set up a working .reportbugrc that sends directly to the BTS, but you may want to edit that to use your normal SMTP server...
[18:53] <tumbleweed> == Examples! ==
[18:53] <tumbleweed> OK, that was the high level overview. Let's squeeze in an example, and any last questions
[18:53] <tumbleweed> bug 840709:
[18:53] <tumbleweed> pah, there's no ubottu here
[18:53] <tumbleweed> http://pad.lv/840709
[18:53] <tumbleweed> This bug is just a fix for some spelling errors in a package description.
[18:54] <tumbleweed> If we fixed that directly in Ubuntu, we'd have to carry that change, and merge it into new versions of the package whenever they came from Debian
[18:54] <tumbleweed> That takes effort, and isn't really worth it in this case
[18:54] <tumbleweed> So, what the submitter did, was to forward the bug to Debian
[18:54] <tumbleweed> He downloaded the package source, made the change, and then ran submittodebian
[18:54] <tumbleweed> This automatically generated a debdiff, and fired up reportbug
[18:55] <tumbleweed> It's a very handy tool! :)
[18:55] <tumbleweed> Once he had the bug number (you get it by e-mail), he linked the debian bug to the Ubuntu one, to ease tracking
[18:55] <ClassBot> There are 5 minutes remaining in the current session.
[18:55] <tumbleweed> Now we wait for the debian maintainer to apply that patch, and we'll get it for free :)
[18:55] <tumbleweed> last questions?
[18:56] <tumbleweed> (you can see the link to the forwarded bug, at the top, it's an extra bug task on "conduit (Debian)"
[18:57] <tumbleweed> OK, hope that wasn't too fast and people were able to learn something
[18:58] <tumbleweed> if you need any help in dealing with Debian, as an Ubuntu Developer / contributor, stick your nose into #debian-ubuntu on irc.oftc.net (Debian's IRC network)
[18:58] <tumbleweed> there are a fair number of people who know Debian & Ubuntu in there
[18:58] <tumbleweed> also, most of #ubuntu-motu can probably help out
[18:58] <ClassBot> kanliot asked: if this is as easy as you say, how come its so damn hard for me
[18:58] <tumbleweed> ^ I love that question!
[18:59] <tumbleweed> everything is probably quite hard the first time one does it
[18:59] <tumbleweed> it gets easier :)
[18:59] <tumbleweed> I can't really say much more without details, but I'm happy to help, if you ask me afterwards
[18:59] <ClassBot> metasansana asked: you mentioned ~75% so what would be the main diff between ubuntu and debian software
[19:00] <tumbleweed> IIRC about 10% is minor changes (e.g. small bug fixes or dealing with the slightly different environment)
[19:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[19:01] <barry> hello everyone.  welcome to today's class on ubuntu distributed development (udd).  this is an hour-long class so hopefully we'll be able to get to everyone's questions.  i'll start here in just a minute.  don't forget to join #ubuntu-classroom-chat to ask your questions, prefaced with QUESTION:
[19:03] <barry> okay, let's get started
[19:03] <barry> first a little bit of background
[19:03] <barry> here is the online documentation for udd. note however that it's slightly out of date at the moment.  i just merged a branch that updated a lot of information we're going to cover today, but it hasn't hit the web yet
[19:04] <barry> http://developer.ubuntu.com/packaging/html/index.html
[19:04] <barry> hopefully it will very soon now, but you can always grab the ubuntu packaging guide branch and build the html yourself.  ask a question in #u-c-c if you want details on that
[19:05] <barry> i'm not really planning on covering packaging basics, hopefully you are all familiar with that.  i'm also not going to cover the traditional "apt-get source" way of doing packaging.  it's not strictly necessary that you know about that, but it might help for mapping the traditional way with the udd way.
[19:05] <barry> if not, don't worry, you can pretty much do everything in udd these days
[19:06] <barry> okay, so what is udd?
[19:07] <barry> udd uses launchpad and the bazaar dvcs to do package development.  it has many advantages over the traditional apt-get source way (imho), and while there are still a few warts in the process, the tools are really fantastic these days thanks to the great bzr and lp teams
[19:08] <barry> i'll also mention that most of what i'll discuss will be focused on using precise as the dev platform.  you can use oneiric, but you will want to get the latest bzr and bzr-builddeb packages from the bzr ppa if you do.  precise has some really great improvements that will make your life easier
[19:08] <barry> so...
[19:09] <barry> as you probably know, launchpad keeps bzr branches for all the packages in the ubuntu archive, and also all the packages in the debian archive.  we call these 'source branches'
[19:10] <barry> lp runs a package importer process so whenever someone uploads a new version of a package, the importer will grab that and update the source branch for the package.  it works in 98% or so of cases.  the importer has some problems with a few packages, but at least now the tools will tell you if that's the case (and then you can drop down to the traditional way for those small number of problematic cases)
[19:10] <barry> launchpad has source branches not just for the current in-development version of ubuntu and debian, but also for most older versions as well.  e.g. oneiric, lucid, squeeze, etc.
[19:11] <barry> note that these source branches are distinct from any upstream branches lp may be tracking.  the source branches have the full unpacked source of the upstream as it exists in the ubuntu archive, along with the debian/ directory that is the packaging goodness.
[19:12] <barry> the source branches also have the full history of the package, both in individual bzr revisions, and as bzr tags for easier access.
[19:13] <barry> udd then is using these source branches to fix bugs, update to newer upstream versions, merge in new debian versions, build source packages for uploading, etc.  i.e. we now do everything with bazaar
[19:13] <barry> any questions so far?
[19:14] <barry> okay then
[19:15] <barry> so let's say you want to fix a bug in tomboy using udd.  let's start by grabbing the source branch for tomboy in precise
[19:16] <barry> i always find it useful to do my work in a bzr shared repo.  this amortizes the cost of doing the initial branching.  i personally like a shared repo per package
[19:16] <barry> so, cd to someplace where you're going to do your work and then type `bzr init-repo tomboy`
[19:16] <barry> then cd into the tomboy directory
[19:17] <barry> bzr has a very nice shortcut for accessing the source branches for any package in the in-development version of ubuntu (i.e. precise).  just do this to grab the tomboy source branch:
[19:17] <barry> bzr branch ubuntu:tomboy precise
[19:18] <barry> you will end up with a `precise` directory containing the source branch
[19:18] <barry> as the branching happens, notice two very useful things:
[19:18] <barry> Most recent Ubuntu version: 1.8.0-1ubuntu1.2
[19:18] <barry> Packaging branch status: CURRENT
[19:18] <barry> bzr prints both those lines to your console
[19:19] <barry> what that is telling you is that the most recent ubuntu version of tomboy (i.e. in precise) is 1.8.0-1ubuntu1.2 *and* that the packaging branch is up-to-date with the state of the archive
[19:19] <barry> this is great because it means we can use udd to do our development
[19:20] <barry> remember above i mentioned that the package importer sometimes has problems?  you would see a different message above if the tomboy branch was out of date
[19:21] <ClassBot> jincreator asked: In common package, is maintainer the only one who can edit package?
[19:22] <ClassBot> kanliot asked: i think i know what a bzr repo is, but what's a shared repo?
[19:23] <barry> kanliot: a shared repo is just a parent directory that contains all the bazaar revision metadata.  it's nice to use because let's say you want to make a change to tomboy as described above.  when you do that in a shared repo, 99.9% of the revisions are going to be shared by your two branches.  all that shared metadata lives in the parent directory's .bzr directory.  so using a shared repo makes it super cheap to branch and merge
[19:24] <barry> kanliot: hopefully that answers your question.  if not ask again, and i can dig up some bzr docos that explain it better
[19:24] <barry> okay, depending on your bandwidth, you hopefully have the precise source branch for tomboy
[19:25] <barry> i'll just mention a couple of things.  notice we used the ubuntu: prefix?  well, there's also a debianlp: prefix which can get the current debian version of the package (in wheezy, a.k.a. the in-development version)
[19:25] <barry> if we wanted to get the lucid version of a package we would use
[19:25] <barry> ubuntu:lucid/tomboy or abbreviated ubuntu:l/tomboy
[19:26] <barry> abbreviations don't work for debian branches, but you can still do things like
[19:26] <barry> debianlp:squeeze/tomboy to get the squeeze version of the package
[19:27] <barry> okay, let's get back to our example
[19:27] <barry> we've got the precise version of tomboy and now we want to create a branch to work on our fix.  let's say we're working on bug 12345.  we might do something like this:
[19:27] <barry> bzr branch precise bug-12345
[19:27] <barry> that should go really fast in a shared repo
[19:28] <barry> go ahead and cd into bug-12345 and ls
[19:28] <barry> you will see all the upstream source code, plus a debian directory
[19:28] <barry> the debian dir contains all the packaging stuff of course
[19:29] <barry> if we did nothing else, we could build a source package for local building and testing, by doing this:
[19:29] <barry> bzr bd -S
[19:29] <barry> this is roughly equivalent to debuild -S
[19:29] <barry> we can also do normal package development stuff like
[19:29] <barry> dch -i
[19:29] <barry> and so on
[19:29] <barry> a quick word about package systems
[19:30] <barry> er, s/package/patch/
[19:30] <barry> if you're an experienced packager you know that in general, we prefer to provide fixes to packages using a patch system, quilt being the most popular and recommended these days
[19:31] <barry> the important thing to remember is that source branches already have all the patches applied
[19:31] <barry> so once you get a source branch, you're ready to dig right in
[19:31] <barry> it's equivalent to having already done `quilt push -a`
[19:31] <barry> this generally makes things much nicer, but there are a few small gotchas we'll hopefully have time to get to
[19:32] <barry> inside your bug-12345 branch, do this: quilt applied
[19:32] <barry> that will show you that all the quilt patches in tomboy are already applied
[19:32] <barry> let's say bug 12345 just described a typo in the debian/control file.  okay, this is easy to fix
[19:32] <barry> you use your favorite editor to fix the typo
[19:33] <barry> then you use dch -i to add an entry to debian/changelog
[19:33] <barry> if you're happy with the change, you can then do:
[19:33] <barry> bzr commit
[19:34] <barry> what's nice about this is that your commit message will be taken from your changelog entry, so generally you can just use that directly
[19:34] <barry> once you've committed your change, build your source package:
[19:34] <barry> bzr bd -S
[19:34] <barry> in the shared repo (i.e. the parent of bug-12345), you'll have the .dsc .orig.tar.gz and so on
[19:34] <barry> you can test and upload these as normal
[19:34] <barry> before you upload though, do one other thing:
[19:34] <barry> bzr tag
[19:35] <barry> (with no options).  this will add a tag matching the new changelog entry version number.  super easy!
[19:35] <barry> you can then merge this back into the source branch by doing this:
[19:35] <barry> cd ../precise
[19:35] <barry> bzr merge ../bug-12345
[19:35] <barry> bzr commit
[19:36] <barry> bzr push :parent
[19:36] <barry> that last bit pushes your updates back to launchpad (assuming you have permission to do so, i.e. you have upload rights on the package)
[19:36] <barry> note that you'll still need to dput the package
[19:36] <barry> what if you don't have upload rights?
[19:37] <barry> in that case, you submit a merge proposal so that a package maintainer or sponsor can help you get your changes uploaded
[19:37] <barry> in that case
[19:37] <barry> stay in the bug-12345 directory.  after you've committed and tagged, do the following:
[19:37] <barry> bzr push lp:~barry/ubuntu/precise/tomboy/bug-12345
[19:37] <barry> substituting your own lp id for ~barry of course
[19:38] <barry> the last path component is up to you.  i like naming it after the bug i'm fixing
[19:38] <barry> once the branch is pushed, do the following:
[19:38] <barry> bzr lp-propose
[19:38] <barry> that will create a merge proposal with all the right details, and open your browser to that page
[19:39] <barry> a sponsor can then review your changes, work with you to ensure they are correct, and help you get your changes uploaded
[19:39] <barry> i'll pause a moment for questions
[19:40] <barry> okay.  the next topic i'd like to cover is merging updates from debian or upstream using udd
[19:41] <barry> let's say upstream tomboy releases a new version and you'd like to get that into ubuntu.  for whatever reason, you're going to do this without going through debian first
[19:41] <ClassBot> fjrodriguez asked: What are upstream branches?
[19:42] <barry> fjrodriguez: by "upstream branches" we can mean a couple of things.  because debian is an upstream of ubuntu, we could mean the version of the package in debian.  more typically though, we mean the code from the upstream project itself, although these will generally be tar.gz files or similar and not actual dvcs branches
[19:42] <barry> (or non-d vcs branches)
[19:43] <barry> i.e. when tomboy makes a new release, we're going to call the new  .tar.gz file the "upstream" version
[19:43] <barry> does that make sense?
[19:44] <barry> so let's say that tomboy releases version 2.0 and we want to put this in ubuntu (the following commands likely won't work since this is a hypothetical situation)
[19:45] <barry> if the source branch, i.e. ubuntu:tomboy has a working debian/watch file, and we're lucky, we should just be able to do the following:
[19:45] <barry> bzr merge-upstream
[19:46] <barry> this command will grab the upstream tarball from the web, do a bunch of magic <wink>, and leave you with a branch of uncommitted changes that include an updated source code, and new debian/changelog entries for the new upstream version
[19:46] <barry> everyone know what a debian/watch file is?
[19:47] <barry> if the debian/watch file doesn't work, you can provide more options to bzr merge-upstream to help it along.  do `bzr merge-upstream --help` for details.  i'm going to skip ahead 'cause we have only 15 minutes left
[19:47] <barry> kanliot: a debian/watch file contains a url pattern for how to find the upstream released tarball
[19:48] <barry> the uscan command reads debian/watch and this can be used to find the latest released tarball (by checking version numbers).  `bzr merge-upstream` uses uscan under the hood to download that tarball
[19:49] <barry> more common than getting a new upstream version into ubuntu is merging a new debian version of the package into ubuntu
[19:49] <barry> jincreator: yes, debian/watch is packaging basics and not specifically udd related.
[19:50] <ClassBot> There are 10 minutes remaining in the current session.
[19:50] <barry> so let's say debian wheezy has tomboy 1.9 while ubuntu has tomboy 1.8.0.  we want to merge the debian version into the ubuntu version
[19:50] <barry> in this case, let's assume that launchpad has the latest debian source branch
[19:51] <barry> we can create a new local branch of ubuntu:tomboy, e.g.
[19:51] <barry> bzr branch precise mergedeb
[19:51] <barry> then cd in mergedeb and do this
[19:51] <barry> bzr merge debianlp:tomboy
[19:52] <ClassBot> kanliot asked: what are some specific scenarios where i would need bzr?  would it help if the debian source is downstream of an upstream source on sourceforge.net?
[19:53] <barry> kanliot: one of the primary reasons for using bzr is if you want to work on packages for which you don't have upload rights.  by creating branches, pushing them to lp, and submitting merge proposals, you can gain street cred for your fixing, ubu devel, and packaging skills, and a sponsor can help you with the last little bit of getting your changes uploaded
[19:53] <barry> does that make sense?
[19:54] <barry> kanliot: lp is abbreviation for launchpad
[19:54] <barry> it's the central hub for all ubuntu development
[19:54] <barry> kanliot: correct.  bzr can be used in some cases for debian, but it's not as universal as it is for ubuntu
[19:55] <ClassBot> There are 5 minutes remaining in the current session.
[19:55] <barry> and debian has a different culture and workflow for package development, which i can't go into here ;)
[19:55] <ClassBot> jincreator asked: Why Most recent Debian Version is "MISSING" when I merge from debian?
[19:55] <barry> jincreator: that's an artifact of launchpad not knowing exactly what's in the debian archive.  i believe there is a bug open on this to try to improve that message
[19:56] <barry> for now, you'll always get it when referring to debianlp: branches
[19:57] <barry> well, i was hoping to get to using udd to work with quilt patches, because there's some really fantastic new stuff in precise about this, but there really isn't time.  i'll stick around #ubuntu-classroom-chat if you want to talk about that or you can always ping me on #ubuntu-devel
[19:57] <barry> and the url for the packaging guide will have much better and simpler instructions on this soon
[19:57] <ClassBot> benonsoftware asked: WHat CVS does Debian use Git, SVN, etc? (Sorry if I missed this part as I just came in :P)
[19:58] <barry> benonsoftware: that's a little outside the scope of today's class, but different teams use different things.  e.g. the python packaging teams typically use svn
[19:59] <barry> any other questions in our last 2 minutes?  my apologies for going so quickly and/or cutting things short due to time
[19:59] <barry> let me add in closing that there are lots of places to learn about udd, ask questions, get help etc.
[19:59] <barry> there is a udd mailing list<EMAIL_ADDRESS>[20:00] <barry> i am always on #ubuntu-devel
[20:00] <barry> #bzr can also be very helpful
[20:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[20:00] <Laney> Hi there!
[20:01] <Laney> Thanks barry (also for reminding me that I need to remember to update Tomboy in Precise :P)
[20:01] <Laney> My name is Iain and I'm an Ubuntu Developer and also a Debian Developer. I've been around these parts for a few years now.
[20:02] <Laney> I'm going to tell you a bit today about how you can contribute directly to the Debian project.
[20:03] <Laney> There's a /lot/ (really) to know in this area, way more than I could cover in a 30 minute session, so I'll mainly be trying to give you a feel of what exists and where you can go for help. I'll provide links wherever I can.
[20:04] <Laney> As you've been told in other sessions, Ubuntu is what's known as a Debian derivative. This means that most of the software that Ubuntu users use comes in from the Debian project's packages.
[20:05] <Laney> We generally take what's in Debian, modify it if we need to, recompile it and then make it available to the users of Ubuntu. This process is more or less automatic depending on where we are in the cycle and depending on the particular package concerned.
[20:06] <Laney> In the majority case (for Universe at least), packages are copied ("synced") automatically from Debian at the start of every Ubuntu release cycle. After this automatic period ends, developers can request copies to be performed by using a simple script.
[20:07] <Laney> This https://merges.ubuntu.com/universe-now.png is an image I like to link to which shows that the majority of packages in Universe are unmodified Debian packages (the Unmodified and Needs Sync) sections.
[20:08] <Laney> The Modified and Needs Merge sections are Debian packages which Ubuntu developers have modified for one reason or another. We try to keep this to a minimum as far as possible, as every Ubuntu change adds a small piece of manual maintenance.
[20:08] <ClassBot> ryan___ asked: Is Ubuntu still considered a full Debian derivative even though Ubuntu uses its own shell for GNOME (Unity)?
[20:09] <Laney> Hi ryan__, that's a good question. Ubuntu has always selected its own 'default' experience, even when we were shipping a more-or-less vanilla GNOME desktop.
[20:09] <Laney> There will always be cases when it is necessary for Ubuntu to diverge from Debian, but the default remains that we take our packages from there, and our processes are set up for this.
[20:10] <Laney> I want to outline a couple of reasons why you might want to contribute your work to Debian directly
[20:11] <Laney>  - Debian is upstream to a large number (http://wiki.debian.org/Derivatives and more) of derivatives, of which Ubuntu is just one. By working up there your work will have a larger impact; you'll reach all users of Debian /and/ all derivatives.
[20:11] <Laney>  - You'll also be able to benefit from Debian's QA infrastructure, not all of which Ubuntu has just yet (although we are moving more in this direction)
[20:12] <Laney>  + Regular archive rebuilds to catch build failures that may have cropped up since the initial upload
[20:12] <Laney>  + Automated installation and upgrade tests (http://piuparts.debian.org/)
[20:12] <Laney>  + Automated build log scanning for common detectable problems (https://buildd.debian.org/~brlink/)
[20:13] <Laney>  + The Package Tracking System (PTS), which is a handy dashboard that is personalised to each package. Here's the page for the 'mono' package: http://packages.qa.debian.org/m/mono.html
[20:14] <Laney> You can see that there are links to details about the maintainers, automatically detected problems (as mentioned above), an overview of the bug situation and much more information. It's a really handy tool that I genuinely use all the time when checking out Debian packages (set up a browser keyword for it)
[20:14] <ClassBot> ryan___ asked: Since Ubuntu is a Debian derivative, does Ubuntu contain packages that Debian doesn't currently contain?
[20:15] <Laney> That's right. Being a derivative implies that a lot of the packages are the same, but not all. Some packages (e.g. unity) are so-called Ubuntu local packages meaning that they are not in Debian yet.
[20:15] <Laney> The goal is to get this number as close to zero as possible, but for various reasons this isn't always so easy.
[20:16] <Laney> --
[20:17] <Laney> A key difference (possibly the one which has the most implications) is that of maintainership. In Ubuntu every single package is maintained by a team (either the Core Developers or the MOTUs). In Debian each package has its own maintainer. This may be one or more individuals or it may (increasingly commonly) be an organised packaging team (http://wiki.debian.org/Teams#Packaging_teams).
[20:18] <Laney> This means that you always (actually only usually, as we'll see later) have a point of contact for each package, who is supposed to be an expert on that package.
[20:18] <Laney> It may also be a slight disadvantage in that this person can 'block' progress if they are unresponsive for one reason or another.
[20:19] <Laney> Teams are becoming increasingly common, and are a great way of finding people with a shared interest. One excellent way to get involved with Debian development is to find a team that interests you from the link above and join their IRC channel or mailing list.
[20:20] <ClassBot> There are 10 minutes remaining in the current session.
[20:20] <Laney> For example, if you have a Haskell package, you could post about it to the Debian Haskell Group's mailing list and you'll receive help from exactly those people who have the most knowledge about Haskell packaging. This information is, imho, much more accessible to a newcomer than the corresponsing information in Ubuntu.
[20:21] <ClassBot> ryan___ asked: Are there package teams in the Ubuntu project?
[20:22] <Laney> There's not so much a culture of having formal teams in Ubuntu as there is in Debian. What you might tend to find is some individuals have an interest in a package (which you can usually discover by searching the changleog)
[20:22] <Laney> There are some teams though, for example the desktop team takes care of some packages and the server team some other.
[20:23] <Laney> The difference, as I said, is that even though the teams exist, they do not have exclusive control of their packages. Any developer is free to develop them. This isn't really the case in Debian, where you usually have to work with the Maintainer.
[20:23] <Laney> --
[20:23] <Laney> Since we've only got a few minutes left I'll quickly give you some links
[20:24] <Laney> One useful document is the Debian developers' reference (devref), which describes the expectations that debian has of its maintainers and how to use some of the services available to them
[20:24] <Laney>
[20:25] <ClassBot> There are 5 minutes remaining in the current session.
[20:25] <Laney> http://www.debian.org/doc/manuals/developers-reference/ (some iof this is only applicable to DDs)
[20:25] <Laney> The New Maintainers' guide is also interesting both as a packaging guide and an introduction to the social dynamics in Debian
[20:25] <Laney> http://www.debian.org/doc/manuals/maint-guide/
[20:26] <Laney> The Debian Bug Tracking System (BTS) is an extremely important tool which is quite difficult to grasp at first (due to its email driven nature)
[20:26] <Laney> http://www.debian.org/Bugs/Reporting and there are other documents linked fro http://bugs.debian.org
[20:26] <Laney> reportbug is also a great tool for reporting bugs in debian, and `bts' in the devscripts package
[20:27] <Laney> There are many mroe resources available from http://www.debian.org/devel/
[20:27] <Laney> If you've got questions when getting involved with development in Debian, try contacting either the Debian mentors team (http://mentors.debian.net /<EMAIL_ADDRESS>/ #debian-mentors @ OFTC)
[20:28] <Laney> there are many friendly people there who will be able to help you out
[20:28] <Laney> another very useful resource is the Derivatives Frontdesk http://wiki.debian.org/DerivativesFrontDesk
[20:28] <Laney> This was set up to help collaboration between Debian and its derivatives. Members can be contacted on<EMAIL_ADDRESS>/ #debian-ubuntu @ OFTC
[20:29] <Laney> This is /extremely useful/ if you're an Ubuntu contributor having trouble figuring out how something in Debian is supposed to work (or need help finding a sponsor, or anything similar).
[20:29] <Laney> Right, out of time. I had some more to say
[20:29] <Laney> But I've made a little primer and put it up on the wbe here: http://people.debian.org/~laney/working-in-debian.html
[20:30] <Laney> Feel free to email me or grab me on IRC if you have any questions.
[20:30] <Laney> Happy Debianing :-)
[20:30] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[20:30] <benonsoftware> Hello and welcome to Starting with HTML/CSS
[20:31] <benonsoftware> If you have any questions at all perface them with QUESTION: You question here? in #ubuntu-classroom-chat
[20:31] <benonsoftware> Today I'll be teaching the basics of HTML and CSS and hopefully moving up
[20:32] <benonsoftware> Ok, first if you have a look at any webpage soruce by right clicking then selecting View Soruce
[20:32] <benonsoftware> It may look it bit scary at first but its easy to understand
[20:33] <benonsoftware> First all webpages should have a DOCTYPE at the start of it to tell you its a X/HTML 4.0/4.1/5 type of page
[20:34] <benonsoftware> Most newer websites are using <!DOCTYPE html> for their webpages as it is the HTML 5 doctype
[20:34] <benonsoftware> I would just like to note 2 things, 1. You can ask questions any time in #ubuntu-classroom-chat
[20:35] <benonsoftware> and 2. I am the website team leader for TouchLay and a website dev for SII
[20:35] <benonsoftware> Now after the <!DOCTYPE html> there should be <html>
[20:36] <benonsoftware> Now everything inside <html> or <p> is called a tag
[20:37] <benonsoftware> and all tags must be closed:
[20:37] <benonsoftware> Say if I have a <p> tag to close it (stop it) I would type </p>
[20:37] <ClassBot> ryan___ asked: Is the web page title inside <title> a tag?
[20:38] <benonsoftware> ryan__: Yes, inside <html> is a <head> which desribs the page and the tag <title> its in there
[20:38] <benonsoftware> So for example:
[20:38] <benonsoftware> <!DOCTYPE html>

[20:39] <benonsoftware> Now inside the <head> tag is usally lots of things to help out with Search Engines and the like
[20:39] <benonsoftware> Lets move onto <body>
[20:40] <benonsoftware> Now the <body> tag is usally what everyone else sees on the page, so all of the text and images are inside here
[20:40] <benonsoftware> So usally after the start of <body> is usally the page heading inside the <h1> tag
[20:41] <benonsoftware> Now was the <hx> tag it can go up from <h1> to <h6> with <h1> being the biggest heading and <h6> being the smallest heading
[20:42] <ClassBot> ryan___ asked: Is the page background color/image also in <body>?
[20:43] <benonsoftware> ryan__: There is 3 ways, inside <body>, inside <head> (with CSS) and using a CSS style sheet
[20:44] <benonsoftware> I would just like to note that if I do not cover eveything here I am free for questions afterwards and I'll do another session at a later time
[20:44] <benonsoftware> Images:
[20:44] <benonsoftware> Now to inseart a image into a HTML file you do:
[20:44] <benonsoftware> <img alt=" " src="slice_0_0.jpg" style="width: 180px;  height: 173px; border-width: 0px;"></td>
[20:45] <benonsoftware> Sorry, remove the final </td> tag as it will not work with just that :)
[20:45] <ClassBot> ryan___ asked: I may have a lot of questions, so  instead of asking them here, do you have an email address I could email you at?
[20:46] <benonsoftware> ryan__: I sure do, anyone can contact me at benny @ ubuntu.com
[20:46] <benonsoftware> Now where <img alt=" " inside the " " you have to write a one or two words about the image in case of people using screen readers or cannot view the image
[20:47] <benonsoftware> and inside src="slice_0_0.jpg" you have to replace slice_0_0.jpg with your image name
[20:48] <benonsoftware> Usally people place their images inside a images sub folder so you would then do, images/image1.png for src=" "
[20:48] <benonsoftware> Now with <p>;
 is where most people's content goes.
[20:49] <benonsoftware> So if I wanted to write Web dev is great! on a webpage I would use:
Web dev is great!</p>

[20:50] <benonsoftware> means paragraph
[20:50] <ClassBot> There are 10 minutes remaining in the current session.
[20:50] <benonsoftware> So if you close it then open another <p> tag there would be a one line space inbetween
[20:51] <benonsoftware> But if you just want to start a new line then you would use:

[20:51] <benonsoftware> or <br />
[20:51] <benonsoftware> Please note that the line break tags do NOT close
[20:52] <ClassBot> isgjevori asked: Do we have to close the <img> tag ?
[20:53] <benonsoftware> isgjevori: In the img tag example I showed you, you can see at the end of it the is ">, that closes it
[20:53]  * benonsoftware is not talking about the </td> tag there
[20:53] <benonsoftware> palladin35y asked: What is CSS?
[20:54] <benonsoftware> palladin35y: CSS stands for Cascading Style Sheets and they help you desribe how your webpage should look with colours and the like
[20:54] <benonsoftware> I will if there is enough interest run a session on but CSS in a few weeks time
[20:55] <benonsoftware> With a few minutes left any questions?
[20:55] <ClassBot> There are 5 minutes remaining in the current session.
[20:57] <benonsoftware> Next session is Fixing small bugs in Unity with Trevinho and andyrock
[20:57] <ClassBot> isgjevori asked: Can we put tags like <img> or <blink> ect in a Css file?
[20:58] <benonsoftware> isgjevori: From what I have read no
[20:58] <ClassBot> fjrodriguez asked: What software do you use to create html pages?
[20:58] <ClassBot> nava asked: (please write some article of basic html and css and put it on web to others can download and learn fast) do u teach css 3 and html 5 in next weeks ?
[20:58] <benonsoftware> fjrodriguez: I just use any old notepad program and save the file as .html
[20:59] <benonsoftware> Page if you Google around there is some good What you see is what you get editors
[20:59] <benonsoftware> nava: Well I may in the next month or two but some things about CSS and HTML on my website at www.benonsoftware.com and I might teach about CSS in the next month too
[21:00] <benonsoftware> Also everything covered here in HTML5 too
[21:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html following the conclusion of the session.
[21:01] <Trevinho> Hello all
[21:01] <andyrock> hey all! :)
[21:01] <Trevinho> To begin let's introduce ourselves...
[21:01] <Trevinho> We were two Unity Community hackers
[21:02] <Trevinho> that after hacking on the unity and nux code get contracted by Canonical
[21:02] <Trevinho> to develop unity for 12.04
[21:03] <andyrock> Now we're working on bug fixing
[21:04] <Trevinho> This describes our work, anyway we're two Italian guys... That's why we're often called "The Italians" on our team
[21:04] <andyrock> and to implement small features
[21:06] <Trevinho> We're getting here thanks to the work that we started as community guys, lead by the passion on the free software development
[21:09] <andyrock> So as by description, this session is about Unity and after bug fixing in Unity
[21:09] <Trevinho> First of all...
[21:09] <Trevinho> Why contributing to unity?
[21:10] <Trevinho> Well... The first reason can be simple... As it's a quite new software with a very important role and as every software is not bug free
[21:11] <Trevinho> so... We need to squash them out
[21:11] <Trevinho> to make unity and so the main ubuntu interface to rock
[21:11] <Trevinho> Then personally, you can enjoy to work on a big piece of software
[21:12] <Trevinho> that will be used by millions of users
[21:12] <andyrock> From my point of the view, contributing to unity (and open source software in general) can be an opportunity to learn a lot of cool stuff
[21:13] <Trevinho> Also... If unity doesn't fill exactly to your needs maybe you can work on it to improve it.. That's the main reason I joined at the beginning
[21:14] <andyrock> instead of criticizing without doing anything :)
[21:16] <Trevinho> Or finally, you can just join the development to be welcomed by Jorge in a such way, once you're at the UDS: http://www.flickr.com/photos/trevi55/5701699276/in/photostream
[21:16] <Trevinho> ;)
[21:17] <Trevinho> Ok... I think you got what we meant...
[21:18] <Trevinho> By the way if you're here, maybe the main thing you want is start doing something for our beautiful shell
[21:18] <Trevinho> So... Let's start
[21:19] <Trevinho> First of all... Talking about unity we talk about an (united) ecosystem... So Unity is just one of the projects that makes the "unity experience" possible
[21:19] <Trevinho> The main launchpad branches you should start to branch and look are
[21:19] <Trevinho> lp:bamf - for the Windows /applications matching and management
[21:20] <Trevinho> lp:nux as the widget library
[21:20] <Trevinho> lp:libunity
[21:20] <Trevinho> and then
[21:20] <ClassBot> nava asked: what basics we should know to help in unity project (i mean programming language) ?
[21:20] <Trevinho> lp:unity
[21:20] <andyrock> nava, basic c++
[21:21] <Trevinho> Yes, nux and untiy are in C++
[21:21] <Trevinho> while bamf is in C and libunity in Vala
[21:22] <andyrock> autopilot in pythong
[21:22] <Trevinho> So, I was listing the projects... lp:unity is anyway the "core" of our shell... Basically is a compiz plugin that gets loaded when compiz runs, but to do many patches this shouldn't worry you
[21:22] <andyrock> without the g :)
[21:23] <Trevinho> So.. To get started on development, first of all, we suggest to always stay up-dated to the last ubuntu version
[21:23] <Trevinho> *development version*
[21:23] <Trevinho> so precise, now
[21:24] <Trevinho> Then, to install the main dependencies you can use the unity-team staging ppa
[21:24] <Trevinho> that is at https://launchpad.net/~unity-team/+archive/staging
[21:24] <Trevinho> and you can get the needed dependencies by doing something like
[21:24] <Trevinho> sudo apt-get build-dep unity
[21:24] <andyrock> keep in mind the staging ppa can break your pc :)
[21:24] <Trevinho> yes, that's the coolest part :)
[21:25] <andyrock> most of the time, you'll need to play with nux
[21:25] <andyrock> so it can be useful
[21:25] <andyrock> sudo apt-get build-dep nux
[21:26] <andyrock> btw to build unity from trunk read here http://askubuntu.com/questions/28470/how-do-i-build-unity-from-source
[21:27] <andyrock> now that we know how to build unity, let's talk about what bugs we can solve :)
[21:27] <Trevinho> Now... If you want to start, you'd maybe remember the famous "bitesize list"... Well that's still valid and you can check it at https://bugs.launchpad.net/unity/+bugs?field.tag=bitesize
[21:27] <andyrock> But if you want to be really useful you can fix the "backlog bugs"
[21:28] <andyrock> https://bugs.launchpad.net/unity/+bugs?field.tag=backlog
[21:28] <Trevinho> All these bugs are also listed in this more useful page: http://people.canonical.com/~platform/design/upstream.html
[21:28] <Trevinho> that shows the bugs that have more design priority
[21:29] <andyrock> A bitesize bug is a really simple to solve bug (or at least is should be easy to solve)
[21:29] <andyrock> Let's talk about the backlog bugs
[21:30] <andyrock> What is a backlog bug?
[21:30] <Trevinho> You can also subscribe to the unity bugs at https://bugs.launchpad.net/unity
[21:31] <andyrock> A backlog is a feature that needs to be implemented
[21:31] <andyrock> a feature or an improvement to a feature
[21:32] <andyrock> as you can see we have a quite long backlog list :/
[21:33] <andyrock> So the first step is: "Decide what bug do you want do solve"
[21:33] <Trevinho> Once you've decided... You just need to branch unity (or the project you want to fix)
[21:33] <Trevinho> So for example, considering unity
[21:33] <Trevinho> just do
[21:34] <Trevinho> bzr branch lp:unity
[21:34] <andyrock> then
[21:34] <andyrock> cd unity
[21:34] <andyrock> mkdir build
[21:34] <andyrock> cd build
[21:34] <Trevinho> cmake .. -DCMAKE_BUILD_TYPE=Debug -DCOMPIZ_PLUGIN_INSTALL_TYPE=local -DCMAKE_INSTALL_PREFIX=/usr
[21:34] <Trevinho> this will configure your branch to be compiled
[21:34] <Trevinho> ensuring that you've all the dependencies needed
[21:34] <Trevinho> At this point the hardest thing begings
[21:35] <Trevinho> that's coding your feature
[21:35] <Trevinho> now... If you need some documentations for the libraries we mostly use
[21:35] <Trevinho> you can go to http://developer.ubuntu.com/resources/platform/api/
[21:38] <andyrock> So let's say we want to fix this bug
[21:38] <andyrock> he document that andyrock just linked is another useful tool you can use to understand how unity is made
[21:39] <andyrock> sorry :)
[21:39] <andyrock> http://www.google.it/url?sa=t&rct=j&q=alt%20%2B%20f4%20dash&source=web&cd=1&ved=0CCsQFjAA&url=https%3A%2F%2Fbugs.launchpad.net%2Fbugs%2F891818&ei=6LApT52gI8jc4QSr_bzYAw&usg=AFQjCNFLgM3TIF4Q5cR-2yTt7uWI_6rxgw&sig2=3e3RioCBKXjA-b4MgZFDxA
[21:39] <andyrock> sorry again :)
[21:40] <andyrock> https://bugs.launchpad.net/bugs/891818
[21:40] <andyrock> Dash - dash is not closed with alt+f4
[21:41] <andyrock> The first thing to do so is to study
[21:41] <andyrock> and the first question is: "What is the best way to solve this bug"
[21:42] <andyrock> Maybe we can just intercept the alt+f4 key and the close the dash
[21:42] <andyrock> but there is a best way...
[21:43] <andyrock> intercept a WM_DELETE_WINDOW message
[21:44] <andyrock> that is send from the windows manager when you press alt+f4
[21:44] <Trevinho> You can get this by using xev for example
[21:44] <Trevinho> an useful tool to understand what's going on an X window...
[21:44] <Trevinho> if you run it on a terminal and you do Alt+F4
[21:44] <andyrock> Why this is the best wat to do this?
[21:45] <Trevinho> you get an output:
[21:45] <Trevinho> ClientMessage event, serial 36, synthetic YES, window 0x6400001,
[21:45] <Trevinho>     message_type 0x13a (WM_PROTOCOLS), format 32, message 0x138 (WM_DELETE_WINDOW)
[21:45] <andyrock> Why this is the best wat to do this?
[21:45] <andyrock> because it's easy to test
[21:46] <andyrock> and because if you change the key binding to close a window
[21:46] <andyrock> the code will continue to work :)
[21:46] <ClassBot> kedde asked: Is it possible to set up a breakpoint in an IDE?
[21:47] <andyrock> kedde, yes, but you need to do it using gdb
[21:47] <andyrock> from another tty
[21:47] <andyrock> so alt+ctrl+f1
[21:47] <andyrock> login
[21:47] <andyrock> then
[21:48] <andyrock> DISPLAY=:0 unity --advanced-debug
[21:48] <andyrock> or
[21:48] <andyrock> DISPLAY=:0 gdb --args compiz --replace
[21:49] <andyrock> Let's return to our bug...
[21:50] <ClassBot> There are 10 minutes remaining in the current session.
[21:50] <andyrock> so what we want to do is to intercepet that event
[21:51] <andyrock> you should know that the dash has an associated X window
[21:51] <andyrock> so we'll use that window to receive the event
[21:52] <andyrock> but we have a little problem :)
[21:52] <andyrock> we should add the support in nux
[21:52] <andyrock> to send the event to unity
[21:54] <andyrock> and this is the tricky part of this bug :)
[21:54] <andyrock> Now've not the time to go into the details
[21:55] <ClassBot> There are 5 minutes remaining in the current session.
[21:55] <Trevinho> Yes.. Anyway in that case basically you need to make nux get that event and to emit to a BaseWindow
[21:55] <Trevinho> then on the Unity side you only have to connect to that event and close the window
[21:55] <Trevinho> Now, in Precise we're also focusing a lot on testing
[21:56] <Trevinho> and on quality
[21:56] <Trevinho> so, tetsing can be another way to contribute to the project
[21:56] <Trevinho> We have many ways to test...
[21:56] <andyrock> Google test for example
[21:56] <andyrock> http://code.google.com/p/googletest/
[21:56] <Trevinho> They mostly depends on what you should test
[21:57] <Trevinho> so, we use google test when we have to just check a data structure, for example
[21:57] <Trevinho> or we use Autopilot https://wiki.ubuntu.com/Unity/QA/Autopilot to autogically move unity and check if it's doing the right thing
[21:57] <Trevinho> Give a look to Autopilot, it could be fun to test with it
[21:58] <Trevinho> So, we slightly shown the process we generally follow when doing something for unity
[21:58] <Trevinho> what we can say is that it's not that hard
[21:59] <Trevinho> if you know a little the language and you can use grep, you can just start to scratch your itches from now
[21:59] <Trevinho> fixing the bugs the most are breaking your head
[21:59] <Trevinho> Just branch unity, and have fun
[22:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-classroom.html
[22:00] <Trevinho> If you want, you can also check to our branches to see how to do things https://code.launchpad.net/~3v1n0/unity and https://code.launchpad.net/~andyrock/unity
[22:00] <andyrock> thank you guys
[22:01] <Trevinho> Thank you all
[22:01] <Trevinho> Hope to see your code in launchpad, and to review it! ;)
[22:03] <benonsoftware> That was a fast hour :P