[01:50] <greg-g> pleia2: cna you update the -chat channel topic, it says UDW is over
[01:50] <greg-g> which is why some people are confused, I believe
[01:52] <nhandler> That better greg-g ? And it said Ubuntu *Open* Week is over ;)
[01:52] <greg-g> nhandler: whatever :)
[01:52] <greg-g> but yes, thanks buddy
[03:20] <openweek1> date -u
[06:27] <trinium> date -u
[06:35] <trinium> hello please, what is time of the ubuntu developer week??
[06:37] <ulysses__> 16:00 UTC
[06:38] <ulysses__> http://timeanddate.com/worldclock/fixedtime.html?month=8&day=31&year=2009&hour=16&min=0&sec=0&p1=0
[06:58] <Rish> Good mornin folks!
[06:59] <ulysses__> good morning Rish
[07:00] <Rish> ulysses__: hows' your day? ubuntu dev week starting from today eh?
[07:00] <ulysses__> yes
[07:00] <Rish> i'm exited :)
[07:01] <ulysses__> also:) i want to contribute more in Ubuntu
[07:01] <Rish> it's my dream to be an ubuntu developer! I wish the day would come one day!!
[07:01] <ulysses__> :)
[07:01] <Rish> btw, where r u from?
[07:01] <ulysses__> Hungary
[07:01] <Rish> great! what's the local time there?
[07:02] <ulysses__> 08.02
[07:02] <Rish> me from India, it's 11.32 here!
[07:02] <ulysses__> great:)
[07:02] <Rish> what u do? a developer?
[07:03] <ulysses__> no, i write hungarian documentations, and translate kubuntu docs to hungarian
[07:03] <Rish> well, you already contributing by translating ubuntu docs! God bless you!
[07:04] <ulysses__> thanks:)
[07:04] <Rish> ok, gotta go for college now. Nice talking. will see you in dev class today! byee
[07:04] <ulysses__> bye:)
[07:38] <hackoo> so developers week is starting from 16:00
[07:38] <hackoo> ?
[07:38] <hackoo> I read in browser
[07:39] <ulysses__> yes
[07:39] <ulysses__> http://timeanddate.com/worldclock/fixedtime.html?month=8&day=31&year=2009&hour=16&min=0&sec=0&p1=0
[07:39] <hackoo> ulysses__: but topic has time 21:00
[07:40] <dholbach> hackoo: that's a different session
[07:40] <dholbach> hang on
[07:40] <hackoo> ulysses__: so is there some other channels too for the developers week?
[07:41] <dholbach> hackoo: https://wiki.ubuntu.com/UbuntuDeveloperWeek/JoiningIn
[07:41] <dholbach> hackoo: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Rules
[07:41] <dholbach> so there's #ubuntu-classroom (for the session itself) and #ubuntu-classroom-chat (for asking questions and chatting)
[07:41] <hackoo> dholbach: thanks
[07:41] <dholbach> no worries :)
[07:43] <hackoo> dholbach:  ok its good arrangement, I am so excited to learn things, I have never worked for development and using linux for only 4-5 months
[07:43] <dholbach> awesome - UDW is going to be fantastic
[07:43] <dholbach> just writing up a blog entry about today
[07:43] <qwebirc57037> hi
[07:44] <ulysses__> that's other
[07:45] <dholbach> http://daniel.holba.ch/blog/?p=491
[07:48] <openweek2> what is this?
[07:49] <dholbach> openweek2: did you read  https://wiki.ubuntu.com/UbuntuDeveloperWeek ?
[07:49] <dholbach> or the brochure linked from there?
[07:49] <openweek2> yeah
[07:49] <openweek2> some sort of classes are going on here tomorrow
[07:50] <dholbach> which specific questions do you have? :)
[07:50] <openweek2> well im new using ubuntu
[07:50] <openweek2> i want to learn more about it
[07:51] <dholbach> it'll be a great opportunity :)
[07:51] <openweek2> yeah
[07:51] <openweek2> i wont miss it
[07:51] <dholbach> only around 9 more hours to go :)
[07:51] <openweek2> so how would it be like?
[07:51] <openweek2> is it chat
[07:51] <openweek2> or
[07:51] <openweek2> video
[07:51] <dholbach> chat
[07:52] <dholbach> the session will be on #ubuntu-classroom
[07:52] <dholbach> questions can be asked and general chat can happen on #ubuntu-classroom-chat
[07:52] <openweek2> thats cool
[07:53] <dholbach> you can follow the links on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Previous to see what those sessions have been like
[07:54] <openweek2> thanks
[08:18] <hackoo> dev`: hello
[08:19] <dev`> hackoo: hi how are you
[10:05] <anni-jasmin> 'till 1700
[10:55] <AnxiousNut> so this should start after 5 minutes right?
[12:04] <tordek-san> hi
[12:04] <DKcross> hi
[12:30] <DKcross> hello
[12:31] <DKcross> some person know about the problem with splashy
[13:14] <irj> hi... anyone home
[14:00] <zubin71> 3 hours to go!
[14:00] <zubin71> i cant wait!
[14:00] <zubin71> :-)
[14:01] <tavish> will the channel be logged on irclogs.ubuntu.com
[14:02] <pleia2> tavish: yes
[14:03] <tavish> thats good
[14:04] <dholbach> hey pleia2
[14:04] <pleia2> dholbach: g'day dholbach!
[14:04] <dholbach> how's life? :)
[14:04] <pleia2> going good :) and you?
[14:05] <dholbach> very good - thanks :)
[14:05] <qwebirc70095> Hello
[14:05] <dholbach> I'm very excited :)
[14:05] <alourie|vm> hi dholbach
[14:06] <alourie|vm> I decided to join to your lecture :-)
[14:06] <dholbach> alourie|vm: there's going to be a bunch of great sessions today :)
[14:06] <alourie|vm> dholbach: I know, but it will be too late for me. And yours really interests me
[14:07] <alourie|vm> :-)
[14:07] <dholbach> good thing is they'll all be logged
[14:07] <dholbach> so you can dive into what happened tomorrow :)
[14:21] <EagleScreen> any problem following sessions with karmic?
[14:21] <dholbach> EagleScreen: not at all
[14:56] <andi> hi everybody! are u ready for a noob question?
[14:57] <qwebirc12876> is that the noob the noob question?
[14:57] <dholbach> andi: just ask
[14:57] <andi> i see o ne is ready^^, sry
[14:57] <ikt_> ?
[14:58] <nalioth> andi: you really should be asking in #ubuntu
[14:58] <andi> is this the channel where the ubuntu-dev session will be?
[14:58] <dholbach> andi: yes
[14:58] <dholbach> kicking off in ~2h
[14:58] <ikt> how many hours till the first one?
[14:58] <ikt> rah
[14:59] <andi> sry i'm using irc the 1st time
[14:59] <dholbach> no worries
[14:59] <ikt> 2am~ est
[14:59] <andi> ah, ok
[14:59] <ikt> I go through the logs so cheers in advance dholbach and other teachers/mentors :)
[15:00] <dholbach> ikt: it's great to have you here!
[15:00] <andi> i read about the developers week but it took me a while to realize thats an irc-session^^
[15:00] <ikt> :)
[15:00] <NutCobbler> The instructions for the chat say there is a second channel for talking!?
[15:00] <andi> hi daniel!
[15:01] <dholbach> NutCobbler: yes, #ubuntu-classroom-chat
[15:01] <dholbach> later on I expect this channel to be a lot more quiet
[15:02] <dholbach> so the logs of the session are more readable
[15:02] <andi> ubuntu-classroom-chat is for disscussion i think
[15:02] <openweek3> i am pretty sure that the workshop is in here, in like 2 hours
[15:02] <dholbach> questions and chatter will go into #ubuntu-classroom-chat
[15:02] <dholbach> yes
[15:02] <NutCobbler> Odd.
[15:02] <dholbach> NutCobbler: mh?
[15:46] <trinium> hello
[15:48] <Kamusin> hi
[15:48] <trinium> good, veru good, preparative  ready for ubuntu developed :D
[15:49] <maik_haack> 11 minutes to go
[15:49] <msp301> tis not for another hour :(
[15:50] <msp301> but #ubuntu-classroom-chat is meant to be for general talk
[15:50] <trinium> 1 hour and 10 minutes :)
[15:54] <Kamusin> yep
[15:57] <VictorLobo> date -u
[15:58] <thiebaude> what time does this start?
[15:58] <msp301> Mon Aug 31 14:58:17 UTC 2009 ... at 16:00 UTC
[15:59] <thiebaude> msp301, thanks mate
[15:59] <msp301> tis alright :)
[15:59] <thiebaude> 11am eastern time
[16:36] <rubial> hey
[16:36] <rubial> is it going to start at 9:30 IST
[16:36] <rubial> ?
[16:36] <ulysses> 16:00 UTC
[16:36] <dholbach> rubial: yes
[16:37] <rubial> dholbach: thnks
[16:37] <rubial> letme bring some ciggiartes then
[16:37] <rubial> i have time
[16:37] <syedam> ;)
[16:38] <AnxiousNut> after how many hours this will start?
[16:38] <jacob> AnxiousNut: 22 minutes.
[16:38] <AnxiousNut> this is the first one? "getting started"?
[16:39] <jacob> AnxiousNut: yes
[16:43]  * nealmcb gets a head start by learning about couchdb -  http://couchdb.apache.org/docs/intro.html - coming to the desktop via ubuntu one, and used in quickly
[16:43] <nealmcb> I like the idea of a "RESTful" database - programming for fun on the couch :)
[16:44] <mhall119|work> nealmcb: I think it's also going to be used by gwibber 2.0
[16:44] <devin122> im on my couch right now. So i can wath the chat on my 52"
[16:44] <devin122> *watch
[16:44] <msp301> lol
[16:44] <nealmcb> https://launchpad.net/gwibber
[16:44] <nealmcb> so much to learn :)
[16:45] <penguin42> does anyone know of any good docs on the hibernate process and how things hook it ?
[16:45] <naresh> it hasn't started right?
[16:45] <syedam> 15 more mins
[16:45] <jacob> naresh: not yet, 15 minutes
[16:45] <ulysses> 15 minutes
[16:45]  * jacob grabs breakfast
[16:45] <naresh> cool
[16:46] <nealmcb> mhall119|work: so what would gwibber do with couchdb?  contacts?  synced with something else?
[16:47] <mhall119|work> nealmcb: it looks like they'll use it to store account settings instead of gconf
[16:47] <nealmcb> ahh
[16:47] <mhall119|work> I only just installed 2.0 a couple days ago, so I'm not really sure
[16:48] <kblin> interesting, but not quite today's topic :)
[16:49] <Karmic> kblin: Live and let live!
[16:49] <nealmcb> kblin: this is the unconference, preceeding the conference :)
[16:49] <msp301> yep
[16:50] <nealmcb> leverage the great minds here....
[16:50] <msp301> questions are gonna be held on #ubuntu-classroom-chat
[16:50] <kblin> Karmic: notice the smiley up there :)
[16:51] <nealmcb> msp301: good point - don't get used to just barging in like this after we get officially started
[16:51] <der_maik> 9 minutes to go
[16:51] <msp301> oh the anticipation :P
[16:52] <kblin> nealmcb: I'm genuinely interested in that couchdb thing. it might make syncing data across a couple of systems easier :)
[16:52] <nealmcb> kblin: thanks to didrocks in #quickly :)
[16:55] <rish> hi, class started?
[16:55] <mhall119|work> what exactly is today's topic?
[16:55]  * mhall119|work lurks in here 24/7
[16:55] <Karmic> mhall119|work: https://wiki.ubuntu.com/UbuntuDeveloperWeek
[16:55] <msp301> mhall119|work: an introduction to ubuntu development
[16:57] <EagleScreen> class start at 16:00 UTC, in 3 minutes
[17:00] <dholbach> WELCOME EVERYBODY TO UBUNTU DEVELOPER WEEK!
[17:00] <dholbach> Who's all here for Ubuntu Developer Week?
[17:00] <the-dude> \o/
[17:00] <andol> o/
[17:00]  * penguin42 raises a flipper
[17:00] <andi> +
[17:00] <shwnj> hello :)
[17:00]  * devin122 raises hand
[17:00] <msp301> me :)
[17:00] <Narodon> <-
[17:00] <syedam> hi
[17:00] <trothigar> :)
[17:00] <raji> hi
[17:00] <medi> hi
[17:00] <EagleScreen> me, hello
[17:00] <_Fauchi95_> +
[17:00] <juanje> \o/
[17:00] <papapep> :D
[17:00] <slicingcake> \o/
[17:00] <Oreste> Hi all
[17:00] <norax> hi
[17:00] <codeanu> hello :-)
[17:00] <James147> hi :)
[17:00] <robbbb> heyyy
[17:00] <rish> o/
[17:00] <anurag213> hy there
[17:00] <Karmic> kudos!
[17:00] <ulysses> \o/
[17:00] <Ker__> Hey
[17:00] <d3tr01t> sup
[17:00] <ahe> hi
[17:00] <aalcazar> hi
[17:00] <bptk421> hi
[17:00] <HobbleAlong> hi
[17:00] <svij> heyy
[17:00] <haveMercy> hi
[17:00] <marvinlemos> hi
[17:00] <Gvorr> hi
[17:00]  * arualavi .-D
[17:00] <kamikalo> hi
[17:00] <tdapple> howdy
[17:00] <soyrochus> hola
[17:00] <riot_> hi daniel
[17:00] <_Fauchi95_> hi
[17:00] <sligocki> g'day
[17:00] <jcastro> woo!
[17:00] <julian_sda> hi
[17:00] <qwebirc16121> hi
[17:00] <jacob> \o/
[17:00] <czambran_> hi
[17:00] <randomaction> hi
[17:01] <yo1991> hi
[17:01] <jango6> :D
[17:01] <ScottTesterman> hi
[17:01] <mhall119|work> wow
[17:01] <tordek-san> hi
[17:01] <anurag213> so lets begin
[17:01] <syedam> \ o /
[17:01] <rish> class started!! good
[17:01] <anurag213> yup...
[17:01] <Orphey> hi
[17:01] <dholbach> HELLO MY FRIENDS!
[17:01] <c_korn> me, too
[17:01]  * nealmcb \o/
[17:01] <rubial> :)
[17:01] <troxor> \o
[17:01] <qwebirc47321> howdy
[17:01] <frandieguez_> hi to all!
[17:01] <jacob> quite the turnout
[17:01] <shwnj> hello everyone :)
[17:02] <danbhfive1> hi
[17:02] <thowland> yo
[17:02] <ililias> :)
[17:02] <dholbach> My name is Daniel Holbach... any questions after the session, ideas for improvement, pieces of advice, nice comments and cheques please to dholbach at ubuntu dot com.
[17:02] <dholbach> I'll be your host for the first two sessions which will be all about "Getting Started with Ubuntu Development".
[17:02] <credobyte> & me
[17:02] <rish> ok, dholbach let's start
[17:02] <rubial> dholbach: funny name
[17:02] <dholbach> so let's first dive into a bit of organisational stuff
[17:02] <rubial> go go go
[17:03] <dholbach> I noticed a bunch of people I already know but there's a lot of new "faces" here too
[17:03] <codeanu> ya
[17:03] <dholbach> We're around 300 people in here already, which is why ALL QUESTIONS and ALL CHATTER go to #ubuntu-classroom-chat instead of #ubuntu-classroom
[17:03] <dholbach> else the logs will be totally unreadable afterwards
[17:04] <Panikos> and me +
[17:04] <the-dude> will logs be saved?
[17:04] <tiax> won't you set +m?
[17:04] <dholbach> the-dude: yes
[17:04] <dholbach> so if you're not in #ubuntu-classroom-chat yet, please join the channel now
[17:04]  * popey hugs dholbach 
[17:05] <dholbach> in #ubuntu-classroom-chat please prefix your questions with "QUESTION: "
[17:05] <dholbach> ie: "QUESTION: Do you like doing Ubuntu Development?"
[17:05] <dholbach> also for those not fluent in English, we have irc channels where you can ask questions in your language, they will be translated into English for you
[17:05] <dholbach>  - Catalan: #ubuntu-classroom-chat-ca
[17:05] <dholbach>  - Danish:  #ubuntu-nordic-dev
[17:05] <dholbach>  - Finnish: #ubuntu-fi-devel
[17:05] <dholbach>  - German:  #ubuntu-classroom-chat-de
[17:05] <dholbach>  - Spanish: #ubuntu-classroom-chat-es
[17:05] <dholbach>  - French:  #u-classroom
[17:06] <dholbach> if there's other channels for other languages, please announce them in #ubuntu-classroom-chat
[17:06] <dholbach> Alright... another piece of advice:
[17:06] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek lists the timetable and links to a beautiful brochure that has more information
[17:07] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions should tell you if you need to prepare for any session
[17:07] <dholbach> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/glossary has some useful glossary for abbreviations and stuff
[17:08] <dholbach> alright... that should be everything organisational for now... just bookmark https://wiki.ubuntu.com/UbuntuDeveloperWeek and you'll be fine for this week :-)
[17:08] <dholbach> so let's get the session started
[17:08] <qwebirc71751> hey
[17:08] <qwebirc71751> lets get it started
[17:09] <dholbach> qwebirc71751: chatter and questions please in #ubuntu-classroom-chat
[17:09] <MaNU__> lets start
[17:09] <rish> will you all stop talking and let dholbach speak?
[17:09] <dholbach> my aim for the session is to get you from "How can I help out? I can't code in C/C++." (a question I get very often) to "Ah, I understand things much better now, I know where to look things up and who to ask."
[17:09] <rico45> pls start
[17:09] <zubin71> pls start
[17:10] <dholbach> so I'll cover a bunch of more general topics and help you set up a development environment
[17:10] <credobyte> zubin71: patiance :)
[17:10] <bptk421>  /ignore #ubuntu-classroom JOINS PARTS NICKS QUITS
[17:10] <diwanshuster> hello everyone
[17:10] <zubin71> hello
[17:10] <rico45> no patiance impatient
[17:11] <bptk421>  /ignore #ubuntu-classroom JOINS PARTS NICKS QUITS
[17:11] <dholbach> so as a first step, please enable "Source code" in System -> Administration -> Software Sources -> Ubuntu Software
[17:11] <diwanshuster> done
[17:11] <Nomads>  /ignore #ubuntu-classroom JOINS PARTS NICKS QUITS
[17:12] <dholbach> Once that's done, you'll notice a lot of entries that start with deb-src in /etc/apt/sources.list
[17:12] <dholbach> I'll explain why we need it a bit later on
[17:12] <dholbach> afterwards, please run
[17:12] <dholbach>    sudo apt-get install --no-install-recommends ubuntu-dev-tools build-essential pbuilder
[17:12] <dholbach> it will install a bunch of very useful tools we're going to need for the session
[17:13] <dholbach> ubuntu-dev-tools contains scripts that are very useful for packaging and repetitive tasks (it also depends on devscripts which has even more useful stuff)
[17:13] <dholbach> build-essential is necessary to do the most common tasks having to do with compiling and building
[17:14] <dholbach> pbuilder is the perfect tool to build packages in a sane and reproducable way
[17:15] <dholbach> now please edit the file    ~/.pbuilderrc    (gedit, vi, emacs, whatever you like best)
[17:15] <dholbach> add the following line to it:
[17:15] <dholbach> COMPONENTS="main universe multiverse restricted"
[17:15] <dholbach> and save it
[17:15] <dholbach> now please run:
[17:15] <dholbach>    sudo pbuilder create
[17:16] <dholbach> it will set up a pbuilder instance for you which will take a while
[17:16] <dholbach> I forgot, please install gnupg too:
[17:16] <dholbach>   sudo apt-get install gnupg
 QUESTION: Do I need to use pbuilder or is that optional?
[17:18] <dholbach> _Fauchi95_: pbuilder is a great tool to test-build a package in a separate and minimal environment - it's a great way to test the build
[17:18] <dholbach> it's by no means a must, but I'll get back to the topic of testing in a bit
[17:18] <dholbach> ok... while that's running, let's create a GPG Key - if you have one already you can lay back and relax
[17:19] <dholbach> Please run
[17:19] <dholbach>   gpg --gen-key
[17:19] <dholbach> we use GPG keys to sign packages to identify them as our own work and make sure they weren't tampered with
[17:19] <dholbach> you can also use it to encrypt and sign other files and emails
[17:20] <dholbach> https://help.ubuntu.com/community/GnuPrivacyGuardHowto has more info and I won't go into too much detail, using the defaults should be fine for now
[17:20] <dholbach> give it your name and your preferred email address, that should be fine for now
[17:22] <dholbach> once it's done, you can get your fingerprint and key id by running something like this:
[17:22] <dholbach>    gpg --fingerprint your.name@email.com
[17:22] <dholbach> mine says something like:
[17:22] <dholbach> pub   1024D/059DD5EB 2007-09-29
[17:22] <dholbach>       Schl.-Fingerabdruck = 3E5C 0B3C 8987 79B9 A504  D7A5 463A E59D 059D D5EB
[17:22] <dholbach> uid                  Daniel Holbach .......
[17:22] <dholbach> 059DD5EB is the key id
[17:24] <dholbach> Afterwards please run
[17:24] <dholbach>    gpg --send-keys KEYID
[17:24] <dholbach> ie: gpg --send-keys 059DD5EB
[17:24] <dholbach> this will upload your gpg key to the servers, so other people can identify your files and your emails as yours
[17:25] <dholbach> as a next step, we need to upload it to Launchpad too
[17:25] <dholbach> (if you have no Launchpad account yet, please visit https://launchpad.net/+login)
[17:26] <dholbach> it seems like some people have a problem with gpg not having a default keyserver set, in that case, please add  --keyserver keyserver.ubuntu.com
[17:27] <dholbach> you can add your GPG key to Launchpad by visiting: https://launchpad.net/people/+me/+editpgpkeys
[17:27] <dholbach> ok, that should be it for preparations right now
[17:28] <dholbach> so what did we do
[17:28] <dholbach>  - install a bunch of tools
[17:28] <dholbach>  - created a pbuilder instance (which might be still running for some of you)
[17:28] <dholbach>  - created a GPG key
[17:28] <dholbach>  - uploaded the key to keyservers and launchpad
[17:29] <dholbach> ok... so what do we do with Launchpad
[17:30] <dholbach> Launchpad is used for everything in Ubuntu - Translations of packages, Bug Reports for packages, Specifications of new Ubuntu features, Code branches, and packages are also built there
[17:30] <dholbach> that plus our whole team organisation
[17:30] <dholbach> the great thing about Launchpad is that it is written by awesome people and it is Open Source
[17:30] <dholbach> also... it's written in Python :)
[17:31] <dholbach> We'll have a bunch of interesting Launchpad sessions too this week:
[17:31] <dholbach>  -  Using the LP API for fun and profit -- leonardr (Tue 1st Sep, 19:00 UTC)
[17:31] <dholbach>  -  Getting started with Launchpad development -- gmb  (Wed 2nd Sep, 16:00 UTC)
[17:32] <dholbach>  -  Being productive with bzr and LP code hosting - rockstar (Thu 3rd Sep, 19:00 UTC)
[17:32] <dholbach>  -  Hacking Soyuz to get your builds done -- noodles775, cprov and wgrant (Fri 4th Sep, 20:00 UTC)
[17:32] <dholbach> a lot of other sessions will probably briefly cover Launchpad too
 Question:Not enough random bytes available.  Please do some oth
[17:34] <dholbach> anurag213: just let it sit there for a while - gnupg is getting more entrophy and random numbers from your machine
[17:34] <dholbach> ok, next we'll tell the development tools who we are
[17:34] <dholbach> just edit  ~/.bashrc  in your favourite editor
[17:34] <dholbach> and add something like this to the end of it:
[17:35] <dholbach>    export DEBFULLNAME='Daniel Holbach'
[17:35] <dholbach>    export DEBEMAIL='daniel.holbach@ubuntu.com'
[17:35] <dholbach> then save it
[17:35] <dholbach> and run    source ~/.bashrc
[17:35] <dholbach> alright... that should be it for now
[17:36] <dholbach> so what's next
[17:36] <dholbach> I'll talk a bit about source packages and what we do with them, how code gets changed, when we change which pieces of Ubuntu, who you can talk to, where you can find out more, etc. :)
[17:36] <dholbach> then we'll do some hands-on package building :-)
[17:37] <dholbach> so first of all, here's where you find more information:
[17:37] <dholbach>  https://wiki.ubuntu.com/MOTU/GettingStarted
[17:37] <dholbach> bookmark the page! it links to all the important documents we have
[17:37] <dholbach> among them:
[17:37] <dholbach>   - https://wiki.ubuntu.com/PackagingGuide
[17:38] <dholbach>      which has a lot of information about packaging in general
[17:38] <dholbach>      especially https://wiki.ubuntu.com/PackagingGuide/Recipes where you can find out how to use the tools easily
[17:39] <dholbach>      there's also https://wiki.ubuntu.com/MOTU/Videos which has a bunch of videos which talk about packaging, updating packages, patching stuff, etc.
[17:39] <dholbach>   -  https://wiki.ubuntu.com/UbuntuDevelopment is important too because it explains how Ubuntu Development generally works, processes, who is responsible for what and so on
[17:40] <dholbach>   - https://wiki.ubuntu.com/Packaging/Training invites you to Packaging Training IRC sessions which happen every Thursday
[17:40] <dholbach> the next one is going to be: Thursday 3rd September, 6:00 UTC, Ubuntu Development Q&A... with me :-)
[17:41] <dholbach> ok, now let's have a look at https://wiki.ubuntu.com/ReleaseSchedule
[17:42] <dholbach> it's a great way to understand more about Ubuntu Development if you know more about the different phases of the release
[17:42] <dholbach> this is the schedule of the karmic release which we're working on right now - it's due for October 29th
[17:43] <dholbach> in the first phase the new release is created in Launchpad and the toolchain is set up which means that the most important packages (like libc and gcc, the compiler collection) are bootstrapped
[17:43] <dholbach> afterwards we start merging changes from Upstream and Debian (I'll go into more detail in a bit)
[17:43] <dholbach> and then UDS happens
[17:44] <dholbach> UDS is the Ubuntu Developer Summit where Ubuntu developers meet in real life to discuss and define new features
[17:44] <dholbach> these often result into specifications where we exactly describe why we want the feature, how it's going to work, its impact and its implementation strategy
[17:44] <dholbach> https://blueprints.launchpad.net/ubuntu should have a few you can take a look at
 dholbach: how can a person participate in UDS?
[17:45] <dholbach> alourie|vm: everybody is invited to attend UDS, so if you live close or are sponsored to go there you can participate locally
[17:45] <dholbach> if you can't, you can participate via VOIP and IRC
 QUESTION : what do you mean by bootstrap ?
[17:46] <dholbach> gotunandan: when the new toolchain is uploaded, you need to make sure the new gcc is built with the new libc6 and binutils, etc. - I unfortunately don't have much time to discuss it here, but #ubuntu-toolchain might be a good place to discuss it further
[17:47] <dholbach> once the new features are all discussed and described in specifications people work on their features, upload new version of packages and we import a lot of packages from Debian
[17:47] <dholbach> (more on that in a bit)
[17:48] <dholbach> that all happens in the "green" part of     https://wiki.ubuntu.com/ReleaseSchedule
[17:48] <dholbach> "green" doesn't mean "it's all great here and it all works"!
[17:48] <dholbach> it means that developers have a lot of freedom to work on things :)
[17:48] <dholbach> if you want to participate you need to run the new development release IN SOME FORM
[17:49] <dholbach> I say "in some form" because obviously you probably need your computer and can't have the kernel, libc, X or GNOME explode all the time :-)
[17:49] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases describes how to safely and sanely use the current development release
 QUESTION: for packaging can you just run pbuilder for the development release?
[17:49] <dholbach> trothigar: good question - just what I wanted to talk about :)
[17:50] <dholbach> the answer is no
[17:50] <dholbach> test-building a package for karmic is a good start
[17:50] <dholbach> but you definitely need to do this on karmic too:
[17:50] <dholbach>   _____ _____ ____ _____ ___ _   _  ____ _
[17:50] <dholbach>  |_   _| ____/ ___|_   _|_ _| \ | |/ ___| |
[17:50] <dholbach>    | | |  _| \___ \ | |  | ||  \| | |  _| |
[17:50] <dholbach>    | | | |___ ___) || |  | || |\  | |_| |_|
[17:50] <dholbach>    |_| |_____|____/ |_| |___|_| \_|\____(_)
[17:50] <dholbach> which is why just "test building on karmic" is not good enough
[17:51] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases explains how to use a virtual machine, a chroot or a separate partition for your development work, so you don't hose the family computer :)
[17:51] <dholbach> ok, moving on in the release schedule:
[17:52] <dholbach> afterwards we have Feature Freeze (which we're in in karmic right now) where you need to get exceptions for uploading new upstream versions or other radical changes
[17:52] <dholbach> at this time of the release some things might still be broken but the features should at least be half-way there
[17:53] <dholbach> after that we introduce more and more freeze dates: UI, kernel, documentation, translations, etc.
[17:53] <dholbach> one gets frozen every week so we get a very stable release that can be safely documented, translated and tested
 QUESTION: are there automated testtools for package testing, eg tests for regression testing? or should that be provided by upstream?
[17:53] <dholbach> slacker_nl: great question
[17:54] <dholbach> there's a number of upstream developers (which means software authors) that provide us with test suites and very often they are run during the build to directly find out if things got broken in the new release
[17:54] <dholbach> there's tools like pbuilder for safe test-building and there's tools like lintian that can check your packaging for you
[17:56] <dholbach> ok... let's take a quick 5 minute break and we can get our hands dirty afterwards
[17:56] <dholbach> for all of you that need a new cup of tea or a drink or need to nip to the loo
[17:56] <dholbach> see you in just a bit :-)
[18:00] <dholbach> alright... let's kick off part 2
[18:01] <dholbach> for all of you who just arrived: you can ask questions in #ubuntu-classroom-chat (please prefix with QUESTION:), logs will be available afterwards on https://wiki.ubuntu.com/UbuntuDeveloperWeek
[18:01] <dholbach> Ok... now let's get some source package and let's try to test build it
[18:01] <dholbach> please run
[18:01] <dholbach>    apt-get source hello
[18:02] <dholbach> if you have "Sources" enabled in Software Sources this should work now
[18:02] <dholbach> what it does it the following
[18:02] <dholbach> it will get the source package for the 'hello' package
[18:03] <dholbach> there's the distinction between the source packages and the binary packages
[18:03] <dholbach> what my Mom installs, the .deb files are the binary packages which are a result of the build
[18:03] <dholbach> what we work on as Ubuntu developers is the source packages
[18:03] <dholbach> in the case of hello (on karmic) this means the following files:
[18:04] <dholbach>    hello_2.4-1.diff.gz  hello_2.4-1.dsc  hello_2.4.orig.tar.gz
[18:04] <dholbach> hello_2.4.orig.tar.gz means: the original source code that was released by the software authors of 'hello' in the version 2.4
[18:05] <dholbach> the 'orig' is important - it means: this tar.gz file didn't receive any changes at all, it's just as it was downloaded from the hello homepage
[18:05] <dholbach> (just renamed)
[18:06] <dholbach> hello_2.4-1.diff.gz is the compressed set of changes that were applied by Debian (and Ubuntu) developers to make the source package build the Debian/Ubuntu way
[18:07] <dholbach> so what does this mean "the debian/ubuntu way"?
[18:07] <dholbach> some of you might have compile source code already, where you manually build software by running:
[18:07] <dholbach> ./configure    make     sudo make install
[18:08] <dholbach> the packaging process basically wraps around those build commands and enables us to apply the same build process to every kind of package
[18:08] <dholbach> so it doesn't matter if it's a python program, a set oh PHP modules, something written in C or something to do with Perl
[18:08] <dholbach> also you add some meta information like the package name, a description, etc.
[18:09] <dholbach> The session "Packaging from scratch" -- Laney on Friday will talk about that in more detail
[18:09] <dholbach> also "Learning from mistakes - REVU reviewing best practices" -- mok0  on Thursday  will have useful tips
 QUESTION: Why is dpkg-dev needed? I get an error it's not installed. isn't it available in the ubuntu repository?
[18:09] <dholbach> sorry, please run
[18:09] <dholbach>    sudo apt-get install dpkg-dev
[18:10] <dholbach> it's needed too, I thought it would be pulled in
[18:10] <dholbach> just run
[18:10] <dholbach>      dpkg-source -x *.dsc
[18:10] <dholbach> afterwards and you'll be fine
[18:10] <dholbach> I'll get to the purpose of it in just a bit
 QUESTION:Could you elucidate  "wraps around those build commands"
[18:11] <dholbach> [BIOS]Goo: ok, let's go into some more detail
[18:12] <dholbach> so a regular application written in C will often require you to run something like ./configure; make; make install; etc.
[18:12] <dholbach> a python application that uses distutils might need something like invocations of    python ./setup.py ....
[18:13] <dholbach> sometimes for a package to work afterwards (some simple scripts) it will be enough to just copy them where they belong
[18:13] <dholbach> the package build process can be divided into steps like configuration, compilation, installation, something that happens post-installation and so on
[18:13] <dholbach> think of it as a "meta build process"
[18:14] <dholbach> that process is specified in the debian policy and we make use of that
[18:14] <dholbach> the great thing about this standardisation is: our tools all treat source packages the same way, no matter what weird way they work internally
[18:14] <dholbach> moving on :)
[18:15] <dholbach> hello_2.4-1.dsc just contains meta data of the package like md5sums and so on
[18:16] <dholbach> so what apt-get source (or  more specifically dpkg-source -x *.dsc) did was:
[18:16] <dholbach>  - unpack hello_2.4.orig.tar.gz
[18:16] <dholbach>  - unpack and apply the patch with our changes hello_2.4-1.diff.gz
[18:16] <dholbach> so you should be able to see the hello-2.4 directory
[18:16] <dholbach> (or hello-2.3 if you're on an older version)
[18:17] <dholbach> this directory should contain a debian/ directory which basically contains all the packaging
[18:17] <dholbach> daniel@miyazaki:~$ ls hello-2.4/debian/
[18:17] <dholbach> changelog  control  copyright  postinst  prerm  rules  watch
[18:17] <dholbach> daniel@miyazaki:~$
[18:17] <dholbach> I won't explain every last detail now, just very quickly
[18:17] <dholbach>  - changelog: descriptions of all the packaging changes (one new entry per new version that was uploaded to the archive)
[18:18] <dholbach>  - control: information about the source package (who maintains it, where's the homepage, which packages are necessary to build it, etc.) and the resulting binary package(s)
[18:18] <dholbach>  - copyright: licensing and copyright information of the software
[18:18] <dholbach>  - rules: how is the package build, how does the meta build process work
[18:18] <dholbach> we can safely ignore the others for now
[18:19] <dholbach> alright... now let's test-build the package
[18:19] <dholbach> if your pbuilder setup succeeded, you just run the following
[18:19] <dholbach>     sudo pbuilder build hello_2.4-1.dsc
[18:20] <dholbach> if it works out, you should be able to have a look at /var/cache/pbuilder/result/hello_*.deb afterwards
[18:20] <dholbach> this should work
[18:20] <dholbach>    less /var/cache/pbuilder/result/hello_*.deb
[18:20] <dholbach> this will show you the contents of the package, its size and dependencies, etc.
[18:21] <dholbach> if you have a look at the build log you will see what happened there:
[18:21] <dholbach> first the separate build environment was set up, then some additional packages installed
[18:22] <dholbach> then ./configure was run, then the actual compilation of the source code happened, then some files were installed and then they were all glued together in /var/cache/pbuilder/result/hello_*.deb, then the build environment torn down again
[18:22] <dholbach> the fine thing about pbuilder is that it will store all the packages that are necessary to build a package
[18:23] <dholbach> and you don't need to download them over and over again
 dholbach: QUESTION: what if packages need an update?
[18:23] <dholbach> alourie|vm: you run    sudo pbuilder update   (similar to apt-get update)
 QUESTION: presumably the build deps are downloaded as binaries. Does pbuilder share the same cache as apt?
[18:24] <dholbach> trothigar: you can set it up that way
[18:24] <dholbach> https://wiki.ubuntu.com/PbuilderHowto should have more information on the topic
[18:25] <dholbach> it came up in -chat a couple of times, so here goes:
[18:25] <dholbach>   <RainCT> penguin42: Yeah. Using pbuilder-dist (from ubuntu-dev-tools) is a great way to achieve that
[18:25] <dholbach> pbuilder-dist is a fine tool to test-build packages for various ubuntu and debian releases
[18:25] <dholbach> talk to RainCT to find out more about it :)
[18:26] <dholbach> ok... so how does Ubuntu Development work? what do people do with those .dsc .diff.gz and .orig.tar.gz files
[18:26] <dholbach> basically for every change that is done to a package a new source package must be uploaded to the Launchpad build servers
[18:27] <dholbach> that's where the gpg key comes in, if you're not part of the team (I'll get to that in a sec), it will reject your changes
[18:27] <dholbach> the same applies for Launchpad Personal Package Archives (https://help.launchpad.net/Packaging/PPA)
[18:27] <dholbach> you can think of it as a primitive (sorry everybody) version control system
[18:28] <dholbach> Developer A makes a change and uploads version 2.4-2 of hello
[18:28] <dholbach> and I can get it via   apt-get source hello   later on and improve it some more if I like
[18:29] <dholbach> there are efforts going on to make more use of distributed revision control (using Bazaar on Launchpad) and Mr James Westby will talk about that later in the week
[18:29] <dholbach> Friday 4th September, 18:00 UTC - Fixing an Ubuntu bug using Bazaar -- james_w
[18:30] <dholbach> so how would you go about sending in changes now that you're not part of the team yet
[18:30] <dholbach> easy: come to tomorrow's session "Fixing small bugs in Ubuntu" and learn how to produce patches
[18:30] <dholbach> once you have the patch, you attach it to a bug report and subscribe the reviewers team
[18:31] <dholbach> they'll give you a review and some advice and upload the change for you once it's all good
[18:31] <dholbach> basically they'll download the source package, apply your changes, sign it with they gpg key and upload it for you
 QUESTION: what would happen in the case that two users happen to update at the same time on Launchpad??
[18:31] <dholbach> msp301: those collisions happen every now and then, Launchpad will just use the one that was milliseconds before and throw away the other :)
 dholbach: QUESTION: how do we prepare patches?
[18:32] <dholbach> alourie|vm: tomorrow, 16:00 UTC, this place :-)
[18:32] <dholbach> find more detail about the reviewers team and how to get stuff uploaded at: https://wiki.ubuntu.com/SponsorshipProcess
[18:33] <dholbach> once the reviewers are happy with your general work and get tired of uploading and reviewing myriads of changes for you, they'll tell you that and you can send your application for upload rights :-)
[18:33] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopers explains the process
[18:34] <dholbach> ok... that roughly explains how Ubuntu works
[18:34] <dholbach> there's the release schedule with freeze dates, there's people working with source packages, there's bug reports and people attaching patches to them
[18:34] <dholbach> there's packages getting built, downloaded and tested
[18:34] <dholbach> but that doesn't explain how developers interact
[18:34] <dholbach> there's mailing lists and IRC
[18:35] <dholbach> https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu and #ubuntu-motu should be interesting for you
[18:35] <dholbach> because these channels contain the most awesome and frienly people that can help you out
[18:35] <dholbach> there's lots more mailing lists: https://lists.ubuntu.com/
[18:36] <dholbach> and there's lots more irc channels: https://help.ubuntu.com/community/InternetRelayChat
[18:36] <dholbach> but try to take one step at a time :-)
[18:36] <dholbach> it can be a bit overwhelming :)
 QUESTION: Does building package in my pc will have it installed in my machine. If yes then how do i uninstall it if somethings goes wrong?
[18:36] <dholbach> bogor: no, you have to explicitly install the package, running   sudo dpkg -i bla.deb
[18:36] <dholbach> that's why you probably best check out https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[18:37] <dholbach> which explains how to have a separate, up-to-date development environment
 QUESTION: you've talked about development releases, what about backports, how does that process work, when does a package get backported?
[18:37] <dholbach> slacker_nl: good one
[18:37] <dholbach> slacker_nl: so we all work on karmic now.... it's going to be released on October 29th
[18:37] <dholbach> afterwards the karmic will be frozen
[18:38] <dholbach> no uploads to karmic anymore
[18:38] <dholbach> afterwards only uploads to karmic-security karmic-updates and karmic-backports are accepted
[18:38] <dholbach>  Effectively testing for regressions -- sbeattie  on Thursday will have more information on that
[18:39] <dholbach> https://wiki.ubuntu.com/SRU also explains it in more detail
 QUESTION: where do i join if i wanna participate in gnome desktop env development?
[18:39] <dholbach> openweek0_: check out https://wiki.ubuntu.com/Teams for more information on various teams within Ubuntu
 QUESTION: is that the same with LTS releases ? retricted updates etc ??
[18:40] <dholbach> msp301: no, what I just mentioned above concerns all releases, LTS or not
[18:40] <dholbach> LTS is just supported for longer than the "regular" 18 months, it's 3 years of support on the desktop and 5 on the server
 QUESTION: can I safely run "sudo rm -rf /var/cache/pbuilder/" to purge pbuilder ?
[18:40] <dholbach> c_korn: yes
[18:41] <dholbach> ok, now that we know how developers interact, one thing is VERY important
[18:41] <dholbach> always document changes you are about to make as good as you can
[18:41] <dholbach> we have people living in various parts on earth, speaking different languages and having different skill sets
[18:42] <dholbach> as we maintain all packages together as one big team it's important that other developers don't have to second guess what you might have meant
[18:42] <dholbach> also in 6 months time you probably don't want to second guess your own patches or documentation :)
[18:43] <dholbach> ok... speaking of patches and developers: we're not alone in the open source world
[18:43] <dholbach> we inherit a great deal of good stuff from the Debian project and other projects
[18:43] <dholbach> if we make changes we want to make sure to contribute them back to Debian, so let's take a quick look back at the hello example
[18:44] <dholbach> 2.4-1 is the version in karmic
[18:44] <dholbach> this means:
[18:44] <dholbach>  - 2.4 is the release that was done by the authors of hello on their homepage
[18:44] <dholbach>  - "-1" means that one revision of 2.4 was done in Debian and we inherited that
[18:44] <dholbach> debian/changelog has more information on what happened there
[18:45] <dholbach> if I was to do a change for Karmic, the new version string would be
[18:45] <dholbach>  2.4-1ubuntu1
[18:45] <dholbach> meaning: still 2.4 upstream release, one (inherited) debian revision, one Ubuntu change
[18:46] <dholbach> this also means that in the new Ubuntu release (karmic+1) we can't just copy (we call it 'sync') the package from debian, as we might overwrite the changes that I did in 2.4-1ubuntu1
[18:47] <dholbach> if there was a 2.5-1 in Debian, we'd need to very closely check if we can just overwrite my changes or if I need to merge the manually into the 2.5-1 Debian version (and thus get 2.5-1ubuntu1)
[18:47] <dholbach> to be able to sync as much as possible and share the same codebase all over it's necessary to send patches upstream
[18:47] <dholbach> On Wednesday we'll have a session called " Bug lifecycle, Best practices, Workflow, Tags, Upstream, Big picture" by jcastro and pedro_ who will talk about that some more
 QUESTION: what do I run to test hello after the pbuilder build completes?
[18:48] <dholbach> aacool: you'd run    sudo dpkg -i /var/cache/pbuilder/result/hello*.deb    to install the resulting package
[18:48] <dholbach> and then run
[18:48] <dholbach>    hello
[18:48] <dholbach> in the command line :-)
 QUESTION: What happens with package numbering when ubuntu brings out a newer upstream version before debian does, then debian catches up?
[18:48] <dholbach> penguin42: nice one :)
[18:49] <dholbach> so let's say Debian is still on 2.4-1 and we discover there's a new release out by the hello upstream guys
[18:49] <dholbach> we'd call it 2.5-0ubuntu1
[18:49] <dholbach> to indicate: it's upstream 2.5, we didn't get a revision of it from Debian, but have the first revision of it in Ubuntu
 QUESTION: Since Ubuntu is debian based, can i follow the same package building process for Debian as well?(using pbuild)
[18:50] <dholbach> [BIOS]Goo: essentially, yes
[18:50] <dholbach> https://wiki.ubuntu.com/UbuntuPackagingChanges explains what's different in the Ubuntu world
 QUESTION: What's the order? I mean hello.2.4-1 is before or after hello.2.10-1 ? If before, What goes after hello.2.10-1_ubuntu9? If after what happend if the upstream developer use a different notation?
[18:50] <dholbach> norax: first 2.4-1 then 2.10-1
[18:50] <dholbach> to be on the safe side, you can do this
[18:51] <dholbach> daniel@miyazaki:~$ dpkg --compare-versions 2.10-1 gt 2.4-1 && echo TRUE
[18:51] <dholbach> TRUE
[18:51] <dholbach> daniel@miyazaki:~$
[18:51] <dholbach> dpkg is always authoritative on package versions
[18:51] <dholbach> the command above checks if 2.10-1 is greater than 2.4-1 and print TRUE if it's true :)
 QUESTION: Probably for last; how to clean up a system after using pbuilder. Not just apt-get remove, but more importantly removing all remants of local repositories, build remnants etc.
[18:52] <dholbach> soyrochus: just deinstall the packages that we installed, remove ~/.pbuilderrc and /var/cache/pbuilder
[18:52] <dholbach> that should get you there
[18:52] <dholbach> but more practically: use a virtual machine
[18:52] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[18:53] <dholbach>  . o O { I didn't think that would be the most usef link today :-) }
 QUESTION: is it possibleto generate the debian/* file out of git TAGS, log,... and configure.ac?
[18:53] <dholbach> playya: yes, some people use distributed revision control for 1) the packaging itself and 2) packaging upstream snapshots from bzr/git/svn/cvs/etc
 QUESTION: regarding giving back: what is prefered, create a debian package and wait for Ubuntu to sync with debian or to create a ubuntu package directly? does debian sync with ubuntu?
[18:54] <dholbach> slacker_nl: that depends on the release schedule
[18:54] <dholbach> slacker_nl: if we're a week away from release and the fix is critical we might ask somebody from upstream for advice, but we won't block on them if we know that we need that fix
[18:54] <dholbach> https://wiki.ubuntu.com/Upstream has more info on our collaboration with upstreams
[18:55] <dholbach> ok... as last tips I'd like to give you:
[18:55] <dholbach>  https://wiki.ubuntu.com/MOTU/GettingStarted
[18:55] <dholbach> because it links to all the important stuff
[18:55] <dholbach>  https://wiki.ubuntu.com/Packaging/Training
[18:56] <dholbach> because of the session we'll have on thursday: general questions and answers about Ubuntu development, this place
[18:56] <dholbach> also please join us in #ubuntu-motu on irc.freenode.net
[18:56] <dholbach> and on the ubuntu-motu mailing list
[18:56] <dholbach> I really hope to see all of you during the great sessions we have this week
[18:56] <dholbach> and hope to see you all as Ubuntu contributors really really soon
[18:57] <dholbach> make me proud! :-)
[18:57] <huats> thanks dholbach !
[18:57] <dholbach> thanks everybody - have a great Ubuntu Developer Week!
[18:57] <alourie|vm> dholbach: excellent lecture!
[18:57]  * dinxter claps
[18:57] <msp301> thanks :)
[18:57]  * alourie|vm cheers
[18:57] <zubin71> claps
[18:57] <michele_> Thank you for all the fish :)
[18:57] <dholbach> 3 minutes break until rickspencer3 and didrocks talk about quickly!
[18:57]  * didrocks waves at dholbach 
[18:57] <zubin71> thankx a lot
[18:57] <[BIOS]Goo> :) thanx
[18:57] <bear24rw> thanks
[18:57] <trothigar> thank you
[18:57] <[BIOS]Goo> zubin :P
[18:57] <shrinivasan1> thanks a lot
[18:57] <jango6> thx
[18:57] <alourie|vm> thanks a lot
[18:57] <^arky^> thanks dholbach
[18:57] <aalcazar> thanks
[18:57] <penguin42> Thanks dholbach
[18:57] <soyrochus> great session; thanks
[18:57] <pothos> it was also good in german
[18:58] <raji> thankx
[18:58]  * porthose claps
[18:58] <zubin71> [BIOS]Goo : haha... :-P
[18:58]  * sum-it thanks dholbach 
[18:58] <pothos> but a little bit different
[18:58] <fromme> cheers
[18:58] <bennabi> thanks a lot
[18:58] <[BIOS]Goo> That was Amazin :) gonna contribute tonite itself :P
[18:58] <david_> ty
[18:58] <bogor> dholbach, that was a awesome wonderful lecture
[18:58] <lau_> thx!
[18:58] <kboi> thanks dholbach
[18:58] <c_korn> thanks dholbach
[18:58] <Etilworg> #ubuntu-classroom-talk
[18:58] <dtrich_> thanks you dholbach
[18:58]  * RainCT hugs dholbach :)
[18:58]  * alourie|vm joins
[18:59]  * nixternal hugs dholbach 
[18:59] <shobhit> cheers!!
[18:59] <credobyte> dholbach: respect! thnx for the lecture :)
[18:59] <chiossif_> thanks a lot dholbach !
[18:59]  * dholbach hugs you all back
[18:59] <arulalan> thank you very much  dholbach !
[18:59] <dholbach> ok... I'll quieten this channel down again :-)
[18:59] <dholbach> ok everybody... let's kick of session number 2 (or 3 depending how you count it)
[19:00] <dholbach> next up are rickspencer3 and didrocks
[19:00] <rickspencer3> hi
[19:00] <didrocks> hey o/
[19:00] <rickspencer3> thanks for having us
[19:00] <dholbach> they are members of Ubuntu's Desktop team, they are fantastic and know a lot about hacking on Desktop stuff
[19:00] <dholbach> short: they definitely kick arse
[19:00] <rickspencer3> this is the first time I've done one of these
[19:01] <rickspencer3> so please be patient if I don't certain things correctly ;)
[19:01] <dholbach> please ask all your questions in #ubuntu-classroom-chat
[19:01] <dholbach> and prefix them with "QUESTION: " so they stick out
[19:01] <rickspencer3> didrocks, promised to help me though :) and he'll channel your questions
[19:01] <dholbach> rickspencer3, didrocks: the floor is yours
[19:01] <didrocks> rickspencer3: we trust you :) I will relay question
[19:01] <rickspencer3> lol
[19:01] <rickspencer3> so, here we go ...
[19:01] <rickspencer3> in a nutshell ... quickly makes it easy and fun to write apps
[19:01] <rickspencer3> Let's start with installing
[19:02] <rickspencer3> While it's installing, I can provide some background
[19:02] <rickspencer3> Quickly works with Karmic only, atm
[19:02] <rickspencer3> sudo apt-get install quickly python-desktopcouch-records
[19:02] <rickspencer3> Note that this may take a while to download everything if you don't have it installed already, as it brings in lots of developer tools, like Glade, and dpkg-dev.
[19:02] <rickspencer3> After Quickly is installed, close the terminal and open a new one so that statement completion works.
[19:03] <rickspencer3> so while you are all watching it install, a little background
[19:03] <rickspencer3> Quickly has two parts so far
[19:03] <rickspencer3> A command line parser that parses your input and directs commands to "templates"
[19:03] <rickspencer3> and a template for writing an app for Ubuntu
[19:03] <rickspencer3> #
[19:03] <rickspencer3> Templates are sets of commands and code generators that are designed to work together in an end to end fashion to help developers write a certain kind of application.
[19:04] <rickspencer3> There is only on Quickly template so far, and it's for a Ubuntu project.
[19:04] <rickspencer3> we'll be using that one in this session
[19:04] <rickspencer3> Quickly is in on version 0.2 in Karmic universe repository
[19:04] <rickspencer3> Quickly templates should make programming *easy and fun*
[19:04] <rickspencer3> the easy and fun part is important!
[19:05] <rickspencer3> to make it easy and fun ... we've made some opinionated choices about what tools, apis, etc.. to use
[19:05] <rickspencer3> *very* opinionated ;)
[19:05] <rickspencer3> Python for the language
[19:05] <rickspencer3> pygtk for the UI framework
[19:05] <rickspencer3> Glade for the UI editor
[19:06] <rickspencer3> Gedit for the code editor (though this is easy for yuo to change)
[19:06] <rickspencer3> bzr for version control
[19:06] <rickspencer3> Launchpad for code hosting
[19:06] <rickspencer3> desktopcouch for storage/database (!)
[19:06] <rickspencer3> A terminal for the interface ... yes Quickly is a CL tool
[19:07] <rickspencer3> so, the command line nature, plus the opinionated choices has brought some comparisons to Rails
[19:07] <rickspencer3> *there is no quickly runtime or base class library*
[19:07] <rickspencer3> Using the Ubuntu Project won't bring in any dependencies on Quickly itself
[19:08] <didrocks> rickspencer3: there are some questions now. Ok to take them?
[19:08] <rickspencer3> so ... assuming quickly has installed, or is close to installing for you ...
[19:08] <rickspencer3> didrocks, sure
[19:08] <rickspencer3> go ahead
 QUESTION: Can we get quickly to work with Jaunty?
[19:08] <didrocks> rickspencer3: I let you this one :)
[19:08] <rickspencer3> well
[19:08] <rickspencer3> I don't see technically why it couldn't
[19:08] <rickspencer3> but we have't done any work for this atm
[19:09] <rickspencer3> I think there are desktopcouch builds for Jaunty
[19:09] <rickspencer3> so ... yes ... if someone does it :)
[19:09] <rickspencer3> other questions?
[19:09] <didrocks> in a nutshell, if desktopcouch is working for Jaunty, there is no blocker on quickly's side
 QUESTION: does quickly also work with qt (for KDE users)?
[19:09] <rickspencer3> ah
[19:09] <rickspencer3> well ... there is no QT template atm
[19:10] <rickspencer3> I would love to see one get created though
[19:10] <rickspencer3> I think though, that Kubuntu is a bit farther ahead than Ubuntu wrt developer tools
[19:11] <rickspencer3> more questions?
 rickspencer3: Qt template:I'm planning to do one, that is why I'm here
[19:11] <didrocks> good news \o/
[19:11] <rickspencer3> yeah!
[19:11] <didrocks> that's all for the questions, atm :)
[19:11] <rickspencer3> k
[19:11] <rickspencer3> let's move on
[19:11] <rickspencer3> we can discuss new template in more depth if we have time at the end
[19:12] <rickspencer3> Probably the best way to see what Quickly is all about is to follow along as I build and release an app.
[19:12] <rickspencer3> We'll use the following commands to build the app:
[19:12] <rickspencer3> $quickly create ubuntu-project searchy
[19:12] <rickspencer3> $quickly glade
[19:12] <rickspencer3> $quickly edit
[19:12] <rickspencer3> $quickly run
[19:12] <rickspencer3> $quickly package
[19:12] <rickspencer3> $quickly release
[19:13] <rickspencer3> note that the "$" is just a little thing I do to show a command line input
[19:13] <rickspencer3> it's not part of the command ;)
[19:13] <rickspencer3> We'll build an app that directs a search to http://linuxsearch.org (kirkland's custom search page).
[19:13] <rickspencer3> Get started by creating an application from the ubuntu-project template.
[19:14] <rickspencer3> I'm calling it "searchy"
[19:14] <rickspencer3> Note that I've already claimed "searchy" on launchpad, so you'll need to choose a different name if you want to try to release your code.
[19:14] <rickspencer3> (best name ever) ;)
[19:14] <rickspencer3> Also note that there is currently a limitation in Quickly that means that your application has to have only a one word name. We hope to fix this in a future release.
[19:15] <rickspencer3> so once again, to generate the search app, I do:
[19:15] <rickspencer3> $quickly create ubuntu-project searchy
[19:15] <rickspencer3> this tells quickly to use the ubuntu-project template, and to call what is created "searchy"
[19:15] <rickspencer3> This causes a bunch of info to be dumped to the command line, but ends with the application being run
[19:16] <rickspencer3> Note that it's called "Searchy", but otherwise, it's just a stock application
[19:16] <rickspencer3> what quickly did was to copy over basically a sample application, and do some text switcheroos to customize the app
[19:16] <rickspencer3> with the name provided
[19:17] <rickspencer3> If you've closed the application and want to run it again, change to the searchy directory, and use:
[19:17] <rickspencer3> $quickly run
[19:17] <rickspencer3> note that you get a preferences dialog that currently doesn't work due to a small bug :(
[19:17] <rickspencer3> and also an about dialog
[19:18] <rickspencer3> let's look at editing the UI
[19:18] <rickspencer3> The UI I am envisioning is just a text box, and when I hit enter, it does the search. So I need to edit the default UI.
[19:18] <rickspencer3> First, go to the directory that quickly created for the app: $cd searchy
[19:18] <rickspencer3> then: $quickly glade
[19:18] <rickspencer3> Glade is the program that to edit the UI
[19:18] <rickspencer3> If I just run Glade from the Applicatons menu IT WON'T WORK with quickly
[19:19] <rickspencer3> so Glade should open with the generated UI files ready to edit
[19:19] <rickspencer3> Under the Projects menu, switch to SearchyWindow. This is the main window for your application.
[19:19] <rickspencer3> Delete the image and the label (image1 and label1) to clear out space in the UI.
[19:20] <rickspencer3> In the pallette, under Control and Display, click on the Text Entry control. Then click on the space where the label used to be.
[19:20] <rickspencer3> that should add a textentry for you
[19:20] <rickspencer3> and call it "entry1"
[19:20] <rickspencer3> Also, turn off the size request for the window.
[19:21] <rickspencer3> otherwise, the window will be a funny size when it runs
[19:21] <rickspencer3> Do this by selecting searchy_window in the inspector (the treeview at the top right)
[19:21] <rickspencer3> then in properties (the window right below) ...
[19:21] <rickspencer3> click Common tab, and unselect Width Request and Height Request checkboxes.
[19:22] <rickspencer3> so the UI is edited, but we need to tell the ui file to tell our python code to do something when the user hits the enter key in the edit field
[19:22] <rickspencer3> we do this by defining a "signal handler" in glade, and then writing handler code in python
[19:22] <rickspencer3> so to define the handler
[19:22] <rickspencer3> In Glade, click on the text entry (entry1) to select it
[19:22] <rickspencer3> Switch to the Signals tab
[19:23] <rickspencer3> Click in the Hanlder column in the activate row, and type "do_search". Hit Enter.
[19:23] <rickspencer3> Make sure that you save, or your changes won't show up when you run the app!
[19:23] <rickspencer3> so that's editing the UI
[19:23] <rickspencer3> didrocks, shall I pause to answer questions before we go on to write a little code?
[19:23] <didrocks> yes, there is a question on the glade side before we begin to write some code
 QUESTION: Why does launching Glade from Applications > Programming won't work with quickly? What does quickly do differently?
[19:24] <rickspencer3> what quickly does is assumes that there is one UI file for each Python class for each window type
[19:24] <rickspencer3> instead of a single big ui file taht defines all of the UI for the whole project
[19:25] <rickspencer3> this allows each class to derive from window, and most importantly from Dialog
[19:26] <rickspencer3> quickly needs to generate some xml files to tell Glade about these classes
[19:26] <rickspencer3> and if you just load Glade from the Applications menu, Glade doesn't get to see those UI files
[19:26] <rickspencer3> and won't load the UI files rather than risk corrupting them
[19:26] <rickspencer3> so, I'd love to make this easier and more fun in a later version
[19:27] <rickspencer3> other questions?
[19:27] <didrocks> rickspencer3: no, that's all. But there are a lot of people trying quickly :)
[19:27] <didrocks> you can go on ^^
[19:27]  * rickspencer3 sweats a little at the brow line
[19:27] <rickspencer3> Now we just need to write a little code to make the search happen
[19:27] <rickspencer3> Go back to the terminal and type: $quickly edit
[19:28] <rickspencer3> make sure that you are in the searchy directory
[19:28] <rickspencer3> This will open your editor (most likey Gedit) with all of the python files for your project
[19:28] <rickspencer3> apparently there is a bug that is keeping this form working well for VIM users atm :(
[19:28] <rickspencer3> Before you start, make sure your editor is set up for Python programming
[19:28] <rickspencer3> !!!
[19:28] <rickspencer3> this part is important
[19:28] <rickspencer3> or you will get weird errors and generally not have fun
[19:29] <rickspencer3> Python uses spaces and tabs very differently, and it can cause your program not to run, and can be very confusing if you don't set up Gedit properly.
[19:29] <rickspencer3> Go to Edit -> Preferences
[19:29] <rickspencer3> Go to Editor tab
[19:29] <rickspencer3> Turn on Use spaces instead of tabs
[19:29] <rickspencer3> Set Tab width to 4
[19:29] <rickspencer3> This will set up Gedit to follow Python standards while coding
[19:29] <rickspencer3> if you haven't programmed python before ...
[19:29] <rickspencer3> just a quick note
[19:29] <rickspencer3> python uses indentations level to indicate scope
[19:30] <rickspencer3> so indentations are very critical
[19:30] <rickspencer3> ok ... so back to the code
[19:30] <rickspencer3> in gedit click on the tab for "searchy"
[19:30] <rickspencer3> Hit Cntrl-S to make the syntax coloring work
[19:30] <rickspencer3> "searchy" is the main python file for your application. It runs the code for the main window, and is the first file that gets run when you start your app.
[19:31] <rickspencer3> basically, to make the window do stuff, you'll add methods and member varaibles to the SeachyWindow class
[19:32] <rickspencer3> remember when we added do_search to edit1?
[19:32] <rickspencer3> All we need to do is to add a function in the SearchyWindow class called do_search
[19:32] <rickspencer3> this will be called when the user hits enter on entry1
[19:32] <rickspencer3> The function will just read what is in the text entry field, construct a url string, and use webbrowser to do a web search. Searchy will then close itself.
[19:32] <rickspencer3> Add urllib by adding "import urllib" at line 10.
[19:32] <rickspencer3> Add urllib by adding "import webbrowser" at line 11.
[19:33] <rickspencer3> Then at line 82, hit enter a couple of times to add a new function at line 84.
[19:33] <rickspencer3> I put the edited file into pastebin here: http://paste.ubuntu.com/262082/
[19:33] <rickspencer3>     def do_search(self, widget, daata=None):
[19:33] <rickspencer3>         search_words = self.builder.get_object("entry1").get_text()
[19:33] <rickspencer3>         q = urllib.urlencode({'q':search_words})
[19:33] <rickspencer3>         url = "http://linuxsearch.org/?cof=FORID%3A9&cx=003883529982892832976%3At4dsysmshjs&"
[19:33] <rickspencer3>         url += q
[19:33] <rickspencer3>         url += "&sa=Search"
[19:33] <rickspencer3>         webbrowser.open(url)
[19:33] <rickspencer3>         self.destroy()
[19:33] <rickspencer3> that's the function that I wrote to respond to do_search
[19:34] <rickspencer3> Notice around line 86, the code uses "self.builder" to get a reference to the text entry that was added in Glade.
[19:34] <rickspencer3> Where does self.builder come from?
[19:34] <rickspencer3> Well, the ubuntu-project template sets up a relationship between .ui files generated by Glade, and Python *classes* that use those files.
[19:34] <rickspencer3> In order for this to work, the generated Python files have special functions that get generated that set up the objects for you.
[19:34] <rickspencer3> You can see this around line 94 of the searchy file. A function called NewSearchWindow.
[19:34] <rickspencer3> This special function knows how to set up SearchyWindow object. And then calls "finish_initializing" on the newly created object.
[19:35] <rickspencer3> This means a few things:
[19:35] <rickspencer3> 1. never try to create a searchy window in code like this:
[19:35] <rickspencer3> wind = SearchyWindow()
[19:35] <rickspencer3> because then the ui file won't be set up correctly, and "finish_initializing" won't be called.
[19:35] <rickspencer3> 2. Use "finish_initializing" to add any set up code, as that will be called *after* the UI is loaded.
[19:35] <rickspencer3> (stuff you may have put in an __init__() function before
[19:35] <rickspencer3> 3. Do this to create a new window:
[19:36] <rickspencer3> wind = SearchyWindow.NewSearchyWindow()
[19:36] <rickspencer3> and all will be well.
[19:36] <rickspencer3> so back to the do_search function
[19:36] <rickspencer3> this function pulls out the text from text entry on line 86
[19:36] <rickspencer3> Uses urllib to create a url parameter in line 87
[19:36] <rickspencer3> line 88 - 90 build a url string
[19:36] <rickspencer3> line 91 opens the web browser
[19:37] <rickspencer3> then line 92 closes the SearchyWindow
[19:37] <rickspencer3> when you are done coding ...
[19:37] <rickspencer3> use $quickly run
[19:37] <rickspencer3> to run it
[19:37] <rickspencer3> so that's the coding section
[19:37] <rickspencer3> didrocks, any questions before we discuss packaging or releasing?
[19:38] <didrocks> rickspencer3: there are two questions, but it's related to what you will discuss later, so, I'm queuing them
 Question: Any special things to do if we want to add or own modules?
[19:38] <rickspencer3> ok
[19:38] <rickspencer3> for packaging will discuss later
 QUESTION: Does Quickly handle translations?
[19:38] <rickspencer3> for coding, right now you just create new files and pull them in
[19:39] <rickspencer3> for translations there are a couple of pieces
[19:39] <rickspencer3> first, since the ubuntu-project template uses glade by default, the UI is tranlatably by default
[19:40] <rickspencer3> for using strings in code, you would need to do the get_text trick, which quickly doesn;t handle natively, but perhaps it should
[19:40] <rickspencer3> I'll log a bug on that
[19:40] <rickspencer3> then for doing the translations, quickly assumes you will use launchpad for your code hosting
[19:41] <rickspencer3> so translations get supported there in the launchpad way
[19:41] <rickspencer3> maybe go on to packaging?
[19:41] <didrocks> (maybe a "$quickly addfile" command)
[19:41] <didrocks> one more question
[19:41]  * rickspencer3 nods
 QUESTION: does quickly use gtkbuilder or libglade?
[19:41] <rickspencer3> gtkbuilder!!
[19:41] <rickspencer3> libglade is deprecated
[19:41] <rickspencer3> :)
[19:41] <didrocks> phew ^^
[19:42] <didrocks> rickspencer3: you can go on :)
[19:42] <rickspencer3> that's one of the reasons I wanted to do quickly, I wrote weeks of libglade code before I discovered it was deprecated
[19:42] <rickspencer3> I don't want that to happen to other people
[19:42] <rickspencer3> so's ... packaging
[19:42] <rickspencer3> ok .. here's the thing
[19:43] <rickspencer3> personally, I find packaging very persincety
[19:43] <rickspencer3> and complicated, and time consuming
[19:43] <rickspencer3> especially compared to say, using ftp to but files on a web site
[19:43] <rickspencer3> with quickly, though, it goes waaay easier
[19:44] <rickspencer3> Typically, you'll want to share your software in a PPA, but we'll cover that next ... but we can cover that next
[19:44] <rickspencer3> To make a package with quickly, you'll want to start by licensing your software
[19:44] <rickspencer3> To do this, start by editing the generated file called "Copyright".
[19:44] <rickspencer3> Change the top line to have the current year and your name and your email.
[19:44] <rickspencer3> So I would make the top line look like this:
[19:44] <rickspencer3> # Copyright (C) 2009 Rick Spencer rick.spencer@canonical.com
[19:44] <rickspencer3> then ...
[19:44] <rickspencer3> $quickly license
[19:44] <rickspencer3> The ubuntu-project template is going to use this to apply the GPL V3 (as no license is given in the command arg) to Searchy python files
[19:45] <rickspencer3> You can use other well-known license with $quickly license <LICENSE> (shell completion is your friend) or use your personal license.
[19:45] <rickspencer3> (thanks didrocks)
[19:45] <rickspencer3> Now if I reload my files, I can see that the license has been added to the top
[19:45] <rickspencer3> Note that if you didn't license before building the package on LP, it will be automatically licensed to GPL V3 with your LP user name for copyright
[19:45] <rickspencer3> so, easy to license, what about to package?
[19:45] <rickspencer3> Now I need to provide just a little info to quickly so that it knows enough about my project to make a good package.
[19:46] <rickspencer3> This info is provided in the setup.py file, also generated for you
[19:46] <rickspencer3> Open setup.py.
[19:46] <rickspencer3> Scroll down to the part that says:
[19:46] <rickspencer3> ###################### YOU SHOULD MODIFY ONLY WHAT IS BELOW ######################
[19:47] <rickspencer3> Obviously, you only want to edit what is below that.
[19:47] <rickspencer3> You can see how I set that up here:
[19:47] <rickspencer3> http://paste.ubuntu.com/262183/
[19:47] <rickspencer3> DistUtilsExtra.auto.setup(
[19:47] <rickspencer3>     name='searchy',
[19:47] <rickspencer3>     version='0.1',
[19:47] <rickspencer3>     license='GPL-3',
[19:47] <rickspencer3>     author='Rick Spencer',
[19:47] <rickspencer3>     author_email='rick.spencer@canonical.com',
[19:47] <rickspencer3>     description='Quickly do Linux Searches',
[19:47] <rickspencer3>     long_description='A simple text entry field in a window that directs searches to http://linuxsearch.org',
[19:47] <rickspencer3>     url='https://launchpad.net/searchy',
[19:47] <rickspencer3>     cmdclass={'install': InstallAndUpdateDataDirectory}
[19:47] <rickspencer3>     )
[19:47] <rickspencer3> this is going to tell python-distutils-extra a little about me and my app
[19:48] <rickspencer3> You can also change the info in the desktop file to change the category and other stuff.
[19:48] <rickspencer3> For Searchy, it's called searchy.desktop.in
[19:48] <rickspencer3> Another good thing to do is to change the icon to your own.
[19:48] <rickspencer3> You can do that by editing the file "logo.svg" and the file "icon.png"
[19:48] <rickspencer3> but let's skip that for now
[19:48] <rickspencer3> Once you've licensed it and personalized it, to create a package, just use the command:
[19:48] <rickspencer3> $quickly package
[19:49] <rickspencer3> This will do a few things for you.
[19:49] <rickspencer3> First, it will search through your project for dependencies.
[19:49] <rickspencer3> !!
[19:49] <rickspencer3> thanks to pitti for this bit of magic!
[19:49] <rickspencer3> python-distutils-extra will infer dependencies from your code
[19:49] <rickspencer3> Then quickly package does a bunch of deb magic.
[19:50] <rickspencer3> This spits out a zipped up version of your project
[19:50] <rickspencer3> But more importantly, a .deb file
[19:50] <rickspencer3> You can find these files at the peer level of your project directory.
[19:50] <rickspencer3> If you double click on the .deb file, you can install your app
[19:50] <rickspencer3> or you can send the .deb file around, etc...
[19:50] <rickspencer3> didrocks, given that we have only a few minutes .. shall I touch on releasing, or just answer questions?
[19:51] <didrocks> rickspencer3: there are not so many questions you didn't answer, just drop some word on releasing and we will give the 5 latest minutes for questions
[19:51] <rickspencer3> k
[19:51] <rickspencer3> let's rock it!
[19:51] <rickspencer3> Before you can use quickly release, though, you need to set up launchpad.
[19:52] <rickspencer3> I think this was all covered in the last session, but here are some links
[19:52] <rickspencer3> and you can drop into #quickly if you want some more help
[19:52] <rickspencer3> create an account and set up ssh keys:
[19:52] <rickspencer3> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[19:52] <rickspencer3> In your launchpad account, you will need a "personal package archive", or PPA
[19:52] <rickspencer3> But first, you'll need a pgp key for your ppa.
[19:52] <rickspencer3> Follow the instructions here: https://help.launchpad.net/YourAccount/ImportingYourPGPKey
[19:53] <rickspencer3> when you make you pgp key, don't add a comment to it!
[19:55] <didrocks> ok, rickspencer3 seems to have some trouble with his connection
[19:56] <didrocks> going on
[19:56] <didrocks> If there is a comment in it, quickly won't be able to find it.
[19:56] <didrocks> Now you have to setup a ppa to publish your code. You can come on #quickly and we will help you :)
[19:56] <didrocks> then, create a launchpad project
[19:56] <didrocks> use the command:
[19:56] <didrocks> $quickly release
[19:56] <didrocks> You will have to interact a little with command to make it work
[19:57] <didrocks> (the first time, to say who you are, what lp project you want to be binded to)
[19:57] <didrocks> When this is all done, quickly will churn for a while building and signing packages
[19:57] <didrocks> Then it will upload the package to your ppa.
[19:57] <didrocks> Once it's in your ppa, you can share that link with your users
[19:57] <didrocks> they can install by adding the deb line to their sofware sources
[19:57] <didrocks> and after that, if you update the software, they will get the changes.
[19:58] <didrocks> here we are for the short story, now, going to answer to some questions in the last 3 minutes :)
 Question: is quickly python only or can I use a different coding language; C for instance?
 Question: (for later) are there template translation capabilities ex: move from Pyqt to PySide?
[19:58] <didrocks> today, we only have one template, which is ubuntu-project template
[19:58] <didrocks> the idea is to enable user to create a bunch of them
[19:58] <didrocks> quickly already support this, we have to blog on how to create a proper template
 QUESTION: How do you create new templates for quickly & what format are they in (briefly)
[19:59] <didrocks> so, for answering this question, wait for a week, I'm writing a "dive into quickly" blog post suit and you will hopefully have all your answers :)
[19:59] <didrocks> so, a ubuntu-C-project will be awesome
[20:00] <didrocks> ubuntu-game template, that uses pygame  too
[20:00] <didrocks> and a gedit-plugin that makes it easy to add functions to gedit
[20:00] <didrocks> also, LaTeX template, etc. the sky is the limit :)
 Question: What are u using couchdb for? Can our apps interact with your records using desktopcouch
[20:01] <didrocks> well, no time to descript desktopcouch, but it's a good piece of software
[20:01] <didrocks> in short, it enables to store preferences locally or remotely :)
[20:01] <didrocks> rickspencer3: try to speak again
[20:02] <rickspencer3_> sorry
[20:02] <rickspencer3_> my computer froze :(
[20:02] <didrocks> he's back \o/
[20:02] <rickspencer3_> but didrocks knows all
[20:03] <rickspencer3_> I'll hop into #quickly in like 30 minutes
[20:03] <rickspencer3_> and can discuss other questions there
[20:03] <didrocks> great, thanks rickspencer3_ for the session
[20:03] <rickspencer3_> thank you didrocks
[20:03] <jawnsy> thanks rickspencer3_ and didrocks and all that participated by asking questions in the chat channel :-)
[20:03] <didrocks> hope to see all you guys using quickly :)
[20:04] <didrocks> now it's the turn of jawnsy for packaging perl
[20:04] <didrocks> jawnsy: you can do a perl template ;)
[20:04] <didrocks> (for quickly of course ^^)
[20:04] <jawnsy> I'll introduce myself and a few of the people that are joining me today for this session
[20:04] <jawnsy> my name is Jonathan Yu, I'm a new(ish) member joining the pkg-perl team, and I'm not a Debian Developer
[20:05] <jawnsy> I have with me today some other members of the team: gregoa, jackyf, mogaal, Ryan52
[20:06] <jawnsy> gregoa is a Debian Developer and is up near the top rankings in terms of number of packages maintained :-) If you've ever used a Perl package on Debian, it's likely gregoa's had a hand in it at some point or another
[20:07] <jawnsy> mogaal and jackyf are both newer members to the team, so they will be giving some more insight into what it's like to begin packaging Perl modules
[20:07] <jawnsy> Ryan52 is almost a Debian Developer himself, and also contributes significantly to the group, and has also worked on the pkg-ruby-extras team to package Ruby libraries, so he can speak to the difference between the two worlds
[20:08] <jawnsy> in order to follow along, I'll ask that everyone who wishes to participate (follow along with a simple module we'll build) to install the following packages: devscripts lintian dh-make-perl
[20:08] <jawnsy> as usual, please ask questions in #ubuntu-classroom-chat, please hilight jawnsy-home and/or prefix it with QUESTION so I can see it easily
[20:09] <jawnsy> to begin with, we'll look at a CPAN module called Locale::Msgfmt, because it's simple and relatively easy to package
[20:10] <jawnsy> to begin every package, we use a tool called dh-make-perl
[20:10] <jawnsy> its purpose is to download a module and set up the skeleton framework for getting it built
[20:11] <jawnsy> Perl/CPAN developers have agreed upon a standardized toolchain which makes building, testing and installing packages a more-or-less consistent affair -- most packages, and all of the popular packages, build in the same manner
[20:11] <jawnsy> this makes it easy for us to build these modules in Debian
[20:11] <jawnsy> so to begin, type a line like this in a shell, after having installed the aforementioned prerequisite modules (that is, devscripts, lintian and dh-make-perl)
[20:12] <jawnsy> you might want to do this in a temporary folder, as the build process installs stuff in your current working directory
[20:12] <jawnsy> so I've done:
[20:12] <jawnsy> mkdir tmp
[20:12] <jawnsy> cd tmp
[20:12] <jawnsy> dh-make-perl --cpan Locale::Msgfmt
[20:12] <jawnsy> now, what that does is simply retrieve the Locale::Msgfmt package from CPAN and set up the main framework for it
[20:13] <jawnsy> so after seeing lots of text scroll by on your screen, you should end up with a .tar.gz and a directory named Locale-Msgfmt-0.14
[20:13] <jawnsy> the tarball is the upstream source, and the directory contains the upstream source plus some debhelper and other Debian-related metadata files, which are used during the build process
[20:14] <jawnsy> let's look at the anatomy of this package. taking a file listing in the Locale-Msgfmt-0.14 directory, we get this output:
[20:14] <jawnsy> bin  Build.PL  Changes  debian  dev  lib  Makefile.PL  MANIFEST  META.yml  README  t
[20:14] <jawnsy> all of those files come from the upstream source, with the exception of the debian/ subdirectory, which, as mentioned, contains all of the files that do the magic of building the module
[20:15] <jawnsy> now... I'll digress a bit from the main topic to mention that you can build these CPAN modules and install them via dpkg by using some command line parameters to dh-make-perl; namely: dh-make-perl --install --cpan Locale::Msgfmt
[20:16] <jawnsy> this is great if you are just doing some small packages which you'd otherwise have installed via CPAN anyway, but when making them for Debian, there are a few more things we need to look through to ensure good Quality Assurance
[20:17] <jawnsy> take note that while this installs the package, it won't be able to update it, so you'll be stuck at that version indefinitely. thus, for packages you're likely to use a lot, a better solution is to file a Request For Package bug, and have that package officially supported in Debian
[20:17] <jawnsy> Okay, so let's look at some of the files in debian/:
[20:18] <jawnsy> changelog  compat  control  copyright  liblocale-msgfmt-perl.docs  liblocale-msgfmt-perl.examples  rules  watch
[20:18] <jawnsy> these files all have a little bit of magic to them -- we'll come back to this later
[20:19] <jawnsy> let's first get our Perl module to build into a familiar-looking .deb
[20:19] <jawnsy> so, change back to the Locale-Msgfmt-0.14 root directory
[20:19] <jawnsy> the packages we've installed so far should include the "debuild" program, so from the main tree, simply type that on your command line:
[20:19] <jawnsy> $ debuild
[20:20] <jawnsy> you'll notice it outputs a lot of stuff, including the familiar (if you've ever installed a package via CPAN) test output
[20:20] <jawnsy> if we look a directory above us (this is why I said it's useful to create a temporary directory first).. we see a bunch of files now
[20:20] <jawnsy> so let's look at what each of these files are
[20:21] <jawnsy> liblocale-msgfmt-perl_0.14-1_all.deb  liblocale-msgfmt-perl_0.14-1.dsc           liblocale-msgfmt-perl_0.14.orig.tar.gz
[20:21] <jawnsy> liblocale-msgfmt-perl_0.14-1.diff.gz  liblocale-msgfmt-perl_0.14-1_i386.changes  Locale-Msgfmt-0.14
[20:21] <jawnsy> as Daniel Holbach (dholbach) mentioned earlier... the .deb is the binary that you actually install
[20:21] <jawnsy> so if you would like to install the package now, you can simply type: sudo dpkg --install *.deb
[20:22] <jawnsy> then there is the upload description (dsc) file, and also the original tarball, and the gzipped diff which indicates what changes have been made for Debian (notably, the inclusion of all the debian/ files)
[20:22] <jawnsy> okay, so now let's look into what the .deb would actually install in our system
[20:23] <jawnsy> thankfully, dpkg has a flag that lets us do this easily. simply:
[20:23] <jawnsy> $ dpkg --contents *deb
[20:23] <jawnsy> please, do let me know if I'm going too quickly or if there is anything unclear. do so in #ubuntu-classroom-chat.
[20:23] <jawnsy> so now we see a file listing, which includes exactly where everything will be installed on your system (if you do dpkg --install) on that package
[20:24] <jawnsy> now, in Debian we don't want to waste users' space
[20:24] <jawnsy> so we look at things like the examples and the documentation to make sure they are really useful, before installing them in /usr/share/doc
[20:25] <jawnsy> so for example in this case, the README file doesn't tell us anything useful
[20:25] <jawnsy> this is a good time to bring up what some of those magic files are
[20:26] <jawnsy> the README file is installed because it is listed in this file: liblocale-msgfmt-perl.docs
[20:26] <jawnsy> similarly all the examples listed in liblocale-msgfmt-perl.examples are installed
[20:26] <jawnsy> so if there is ever documentation or examples you don't think should be installed, you can remove them here
[20:26] <jawnsy> so let's look inside the *.docs file
[20:26] <jawnsy> we find a single line, README, which is the name of the file that is installed, that we don't want
[20:27] <jawnsy> if we simply remove that line, then the debhelper installation mechanism will not install the file
[20:27] <jawnsy> now, since an empty file is useless, we can just remove the file altogether
[20:27] <jawnsy> changing back to the main Locale-Msgfmt-0.14 root directory, let's try rebuilding this package
[20:27] <jawnsy> by running `debuild' again
[20:28] <jawnsy> so again, the same hubbub of text scrolling by
[20:28] <jawnsy> and we can examine the contents once again (dpkg --contents *deb), noticing this time that the README is no longer installed
[20:29] <jawnsy> so we'll look briefly at the function of the other files
[20:29] <jawnsy> and then I'll open the floor for some questions and answers
[20:29] <jawnsy> Perl packaging really isn't difficult, and being a Perl user/developer myself, I got into it initially to get some packages I needed into Debian
[20:30] <jawnsy> I should mention a great thing about the pkg-perl group is that we have 10+ members, including gregoa, who are prolific Debian Developers
[20:30] <jawnsy> and it's often a matter of days or weeks to get a package uploaded, compared to months as you'd have with the normal mentors process
[20:31] <jawnsy> in the context of Ubuntu, we also handle our modules which have been sync'd to Ubuntu, and we have two important liasions to the Ubuntu community (many more are welcome!)
[20:31] <jawnsy> nhandler aka Nathan Handler, and Iulian Udrea are both members of the team
[20:31] <jawnsy> everything that benefits Debian or Ubuntu, beenefits both -- the changes flow both ways, and that is really the magic of open source
[20:31] <jawnsy> anyway, back to the meaning of the rest of the debian/ files
[20:32] <jawnsy> after building I've now got something like this in debian/:
[20:32] <jawnsy> changelog  control    files                  liblocale-msgfmt-perl.debhelper.log  liblocale-msgfmt-perl.substvars  watch
[20:32] <jawnsy> compat     copyright  liblocale-msgfmt-perl  liblocale-msgfmt-perl.examples       rules
[20:32] <jawnsy> the .log file, liblocale-msgfmt-perl and the .substvars are just leftover files from the build, and aren't necessary
[20:33] <jawnsy> if they bother you, you can have the package build cleaned up by changing to: Locale-Msgfmt-0.14 again, and issuing:
[20:33] <jawnsy> $ fakeroot debian/rules clean
[20:33] <jawnsy> (though you'll need to install fakeroot for that)
[20:33] <jawnsy> (that command might work as debian/rules clean, without fakeroot, I'm not sure)
[20:33] <jawnsy> oh, heh, I'm learning new things every day. Ryan52 mentions to me out of band that "debclean" also accomplishes this task
[20:34] <jawnsy> okay, so the remaining files--
[20:35] <jawnsy> changelog is the Debian changelog file, which lists things that have been done in the Debian package only (upstream packages generally, but not always, also include their own changelog for the purpose of CPAN users)
[20:35] <jawnsy> from the dpkg contents listing we had before, recall that we saw these files:
[20:35] <jawnsy> -rw-r--r-- root/root      1063 2009-07-09 05:16 ./usr/share/doc/liblocale-msgfmt-perl/changelog.gz
[20:35] <jawnsy> -rw-r--r-- root/root       163 2009-08-31 11:09 ./usr/share/doc/liblocale-msgfmt-perl/changelog.Debian.gz
[20:35] <jawnsy> the changelog.gz is the upstream package changelog
[20:35] <jawnsy> the .Debian file is the one we know as debian/changelog
[20:36] <jawnsy> the changelog is also the source of our version number tracking for packages
[20:36] <jawnsy> you'll notice in the changelog two lines; the first and the last:
[20:36] <jawnsy> liblocale-msgfmt-perl (0.14-1) unstable; urgency=low
[20:36] <jawnsy>  -- Jonathan Yu <jawnsy@cpan.org>  Mon, 31 Aug 2009 11:09:19 -0400
[20:36] <jawnsy> which are notable
[20:37] <jawnsy> now, the first one is the package name + version number; unstable is the release name in Debian, where all new packages go
[20:37] <jawnsy> the trailer has, importantly, my name and e-mail address
[20:37] <jawnsy> this is what gets recorded as the "uploader" of a given version of a package, even though you won't be uploading packages directly -- a Sponsor does that on your behalf
[20:38] <jawnsy> though if you're a Ubuntu Developer then you'd be the uploader and wouldn't need a sponsor (but you already know that)
[20:38] <jawnsy> the next file, control, is where most of the magic happens
[20:39] <jawnsy> its purpose is to specify things like what the package is (ie a description), and other things like the dependencies the package needs
[20:39] <jawnsy> importantly, Build-* things [note: the first paragraph relates to the Source package, from which binaries are built]
[20:39] <jawnsy> the Build-* relationships tells us what we need to install in order to build something, though that is separate from what we need to use the module
[20:40] <jawnsy> so, for example, while I might need Test::Exception to run tests during building, I don't need that in the binary package
[20:40] <jawnsy> this explains why some packages will show: libtest-exception-perl in Build-Depends, but not in Depends
[20:40] <jawnsy> I'll leave the exact meaning of the rest of the fields as an exercise for you, but the Debian Policy Manual describes them all at length
[20:41] <jawnsy> the copyright file contains information relating to the copyright of all our packages, which is important in Debian and Ubuntu because that is how we protect free software
[20:41] <jawnsy> the Debian Free Software Guidelines are a central part of the Debian Social Contract, and I imagine that to a great extent the Ubuntu community agrees
[20:42] <jawnsy> so moving along, the *.examples file is just like *.docs (which we removed).. and it contains a list of places to find examples
[20:42] <jawnsy> in this one, we find one line: t/samples/*
[20:42] <jawnsy> which does what you'd expect with a shell glob, it just gets all the files in that directory and installs them (explaining much of what you saw in the dpkg contents listing)
[20:43] <jawnsy> now there are two more files left to explain
[20:43] <jawnsy> the watch file is autogenerated and most often doesn't need to be modified
[20:43] <jawnsy> the purpose of this file is to scan the upstream for new releases, and given that most Perl-related things are released via CPAN, you probably won't need to touch this file
[20:43] <jawnsy> the rules file is an important part of the build process
[20:44] <jawnsy> currently the format is just a simple makefile, but it calls the debhelper build system to get everything done
[20:44] <jawnsy> Locale-Msgfmt happens to be a simple module as I mentioned before
[20:44] <jawnsy> so the rules file just contains:
[20:44] <jawnsy> %:
[20:44] <jawnsy> dh $@
[20:45] <jawnsy> and debhelper does the other magic :-)
[20:45] <jawnsy> there are some other features of debhelper which we use from time to time, but this gives you a basic idea of how to build Perl modules, and what each file is for
[20:46] <jawnsy> before I open the floor up to some questions, do you guys from the pkg-perl team have any other comments to make?
[20:47] <jawnsy> ...? :-)
[20:47] <jawnsy> I guess they're happy with my treatment of this :P
[20:47] <jawnsy> I could go into a more complicated example, or rant about why the pkg-perl team is cool, or answer other questions
[20:48] <jawnsy> I hope that this session (finished mostly in under 40 minutes) shows you how easy it is to participate in the team
[20:48] <jawnsy> as I mentioned, I'm not a Debian Developer nor Ubuntu Developer
[20:49] <jawnsy> yet I can contribute to both projects through the group and with the help of the many DDs that sponsor my uploads
[20:49] <jawnsy> dinxter asks:
[20:49] <jawnsy> QUESTION: Is there somewhere i can look for a reference for what all those magic debelper files like .example are for and how they work, .install, etc
[20:49] <|Ryan52> the debhelper manpages are good. "man dh", "man dh_installexamples", etc.
[20:50] <jawnsy> you'll notice to when you run debuild, you'll get a list of a bunch of debhelper commands that are being executed
[20:50] <gregoa> and for the big picture: man debhelper
[20:50] <jawnsy> the scripts are usually named according to what they do, so it's not too difficult
[20:50] <jawnsy>    dh_installman
[20:50] <jawnsy>    dh_installcatalogs
[20:50] <jawnsy>    dh_installcron
[20:50] <jawnsy> ^ some example output
[20:51] <jawnsy> so if one is curious about what those do, you can take a look at their manpages
[20:51] <jawnsy> there aren't too many, and if you join the group (as we hope you will), it's easy to ask for help
[20:52] <jawnsy> I myself have only really packaged Perl modules, but many of the concepts are the same -- what the meta-files do, getting familiarzed with Debian and Ubuntu's social policies, etc
[20:53] <jawnsy> so that means it is a great way to begin contributing to Debian or Ubuntu, prior to even becoming a * Developer :-)
[20:53] <jawnsy> alexm mentions that even though I've gotten everyone to install lintian, I haven't explained what it does, or what the warnings mean
[20:53] <|Ryan52>  
[20:54] <jawnsy> lintian is Debian's package checking system. it's a Perl program with many plugins and checks that looks at your code to figure out possible places you might have done something incorrectly
[20:54] <jawnsy> this is another tool which ensures Debian and Ubuntu's quality assurance
[20:54] <jawnsy> we can run this manually from the main directory (where our .deb file is)
[20:55] <jawnsy> so I get this output:
[20:55] <jawnsy> aven'jon(~/tmp)> lintian *changes
[20:55] <jawnsy> W: liblocale-msgfmt-perl: script-with-language-extension usr/bin/msgfmt.pl
[20:55] <jawnsy> E: liblocale-msgfmt-perl: description-synopsis-is-duplicated
[20:55] <jawnsy> W: liblocale-msgfmt-perl: description-contains-dh-make-perl-template
[20:55] <jawnsy> there are flags you can use to get more descriptive output, which also includes what the issue is and a proposed way of fixing it
[20:56] <jawnsy> lintian is usually very good at doing this, though it is no substitute for experience (and this is where mentors and the sponsors come in)
[20:56] <jawnsy> first off is the script being installed with a language extension. Debian policy does not like .pl files being installed in /usr/bin
[20:56] <jawnsy> which is where that warning comes from. we can fix this by providing an override during the install process
[20:57] <jawnsy> let me mention a bit about how that works
[20:57] <gregoa> I always run lintian as "lintian -iI --pedantic --color=auto <pkg>.changes" get also get the informational and pedantic messages and the nice informations jawnsy mentioned
[20:57] <jawnsy> when you're building the package, by default it puts it somewhere like your home directory or in debian/
[20:57] <jawnsy> in our case, that's what produced the debian/liblocale-msgfmt-perl folder
[20:57] <jawnsy> prior to us cleaning it
[20:57] <jawnsy> that is the "staging area" where things are installed, before being rolled into the debian binary
[20:58] <jawnsy> so, in an override we'd be able to rename the script in this staging area, which thus changes the name that it's installed as, so as to comply with policy
[20:58] <jawnsy> overrides are just a way for us to change the default behaviour of debhelper, and it's part of what makes it so flexible and great :-)
[20:58] <jawnsy> this is all probably a bit complicated for the beginner, but that's how that issue is tackled
[20:59] <jawnsy> we only have a minute or two left so I'll mention the other two warnings
[20:59] <jawnsy> one of them comes from what dh-make-perl inserts in your files, to make sure you actually edit them
[20:59] <jawnsy> you'll see the boilerplate text when looking at the files and remove them, so you won't get that warning
[20:59] <jawnsy> the synopsis being duplicated has to do with a bad description in the description field
[20:59] <jawnsy> notably, the first line of the Description field (which is our synopsis or short description of the module) is the same as our long description
[21:00] <jawnsy> so usually this is where a packager would need to describe what the package does in a few lines (a paragraph or two at minimum) so that users know what it is :-)
[21:00] <jawnsy> so this about concludes our talk about Debian/Ubuntu Perl Packaging
[21:01] <jawnsy> I do hope you learned something from this, and that you consider joining the group, or even just visiting to see if it's something you might be interested in
[21:01] <jawnsy> we are on irc.debian.org (OFTC) in #debian-perl
[21:01] <jawnsy> aven'jon(~/tmp)> lintian *changes
[21:01] <jawnsy> W: liblocale-msgfmt-perl: script-with-language-extension usr/bin/msgfmt.pl
[21:01] <jawnsy> E: liblocale-msgfmt-perl: description-synopsis-is-duplicated
[21:01] <jawnsy> oops wrong paste
[21:01] <jawnsy> err
[21:01] <jawnsy> this page welcomes new members, and provides lots of useful information: http://wiki.debian.org/Teams/DebianPerlGroup/Welcome
[21:01] <jawnsy> thank you all for your
[21:01] <jawnsy> time
[21:01] <jackyf> as a sort of newscomer, I can add that the atmosphere of pkg-perl IRC discussion channel, where is significant part of collaboration is done, is very warm and, so, easy to join :)
[21:02] <Riddell> thanks jawnsy.  In a couple of minutes me and agateau will be doing an introduction to Plasmoid with Python
[21:02] <jawnsy> now I shall surrender the floor to agateau and Riddel for "Fun with Python Plasmoids" :-)
[21:02] <agateau> Shall we start now?
[21:02] <jawnsy> *round of applause for Riddell and agateau* :-)
[21:02] <agateau> thanks jawnsy :)
[21:03] <agateau> Riddell and myself are now going to introduce you to plasmoid developments in Python
[21:03] <Riddell> and we want you to follow along at home!
[21:03] <agateau> I'll do a short intro of Plasma and Python, then Riddell will take you through your first plasmoid
[21:04] <agateau> and I'll come back with more widgetry for your plasmoids
[21:04] <agateau> First things first,
[21:04] <agateau> What is Plasma?
[21:04] <agateau> It's the new implementation of the desktop
[21:04] <agateau> in KDE4
[21:05] <agateau> Riddell reminds me I should tell you what packages you need to install while I talk:
[21:05] <agateau> apt-get install kdebase-workspace-bin plasma-scriptengine-python
[21:05] <agateau> and you should be all set
[21:06] <agateau> so, Plasma is based on Qt Graphics View framework, which is, quoting Qt doc:
[21:06] <agateau> "Graphics View provides a surface for managing and interacting with a large
[21:06] <agateau> number of custom-made 2D graphical items, and a view widget for visualizing the
[21:06] <agateau> items, with support for zooming and rotation."
[21:06] <agateau> it can use hardward acceleration, and be themed with SVG files
[21:06] <agateau> what are plasmoid?
[21:07] <agateau> plasmoids are little gadgets you can put on your desktop
[21:07] <agateau> the whole KDE4 desktop is made of plasmoids
[21:07] <agateau> (taskbar, pager, K menu, clock, systray...)
[21:07] <agateau> some examples:
[21:07] <agateau> http://kde.org/announcements/4.2/screenshots/plasma-other-widgets.png
[21:07] <agateau> http://kde.org/announcements/4.3/screenshots/desktop.png
[21:08] <agateau> Plasmoids can be developed in C++, JavaScript, Ruby...
[21:08] <agateau> and Python
[21:08] <agateau> our beloved language
[21:08] <agateau> Python is an interpreted, dynamic programming language
[21:09] <agateau> it's simple yet powerful,
[21:09] <agateau> and very versatile
[21:09] <agateau> it can be used for throw away scripts, desktop applications, web servers...
[21:09] <agateau> and plasmoids
[21:09] <agateau> as Riddell is now going to show you...
[21:09] <Riddell> we had some questions first
[21:09] <Riddell> 21:05 < wizz_> is plasmoid available for ubuntu 9.04 and python2.6?
[21:10] <Riddell> yes, you need to install python-plasma in jaunty
[21:10] <Riddell> as well as kdebase-workspace-bin
[21:10] <Riddell> 21:06 < msp301> will plasma work under gnome??
[21:10] <Riddell> yes, you can use the plasmoidviewer app
[21:10] <Riddell> or you can try running plasma-desktop on top of gnome, goodness knows how that will end up
[21:11] <Riddell> so let's get coding!
[21:11] <Riddell> a basic plasmoid is made up of a metadata file
[21:11] <Riddell> which tells plasma the name and other vital information about the plasmoid
[21:11] <Riddell> and some code
[21:12] <Riddell> that all gets zipped up
[21:12] <Riddell> and finally you install the zip file so you can run the plasmoid
[21:12] <Riddell> so start off in a new directory
[21:12] <Riddell> and make the directories needed for our "hello-python" plasmoid
[21:13] <Riddell> mkdir -p hello-python/contents/code
[21:13] <Riddell> cd hello-python
[21:13] <Riddell> here we'll put our metadata which is in .desktop format
[21:13] <Riddell> [Desktop Entry]
[21:13] <Riddell> Encoding=UTF-8
[21:13] <Riddell> Name=Hello Python
[21:13] <Riddell> Type=Service
[21:13] <Riddell> ServiceTypes=Plasma/Applet
[21:13] <Riddell> Icon=chronometer
[21:14] <Riddell> is the top, that gives it a name and tells plasma that it's an applet, also gives it an icon to use for the Add Applet dialogue
[21:14] <Riddell> next some vital plasma info lines
[21:14] <Riddell> X-Plasma-API=python
[21:14] <Riddell> X-Plasma-MainScript=code/main.py
[21:15] <Riddell> so plasma knows it's looking for Python and it knows what code it's looking for
[21:15] <Riddell> finally some plugin info lines
[21:15] <Riddell> X-KDE-PluginInfo-Author=Simon Edwards
[21:15] <Riddell> X-KDE-PluginInfo-Email=simon@simonzone.com
[21:15] <Riddell> X-KDE-PluginInfo-Name=hello-python
[21:15] <Riddell> X-KDE-PluginInfo-Version=1.0
[21:15] <Riddell> X-KDE-PluginInfo-Website=http://plasma.kde.org/
[21:15] <Riddell> X-KDE-PluginInfo-Category=Examples
[21:15] <Riddell> X-KDE-PluginInfo-Depends=
[21:15] <Riddell> X-KDE-PluginInfo-License=GPL
[21:15] <Riddell> X-KDE-PluginInfo-EnabledByDefault=true
[21:15] <Riddell> 21:15 < keffie_jayx> Riddell: what is the file name .Desktop?
[21:16] <Riddell> this all goes in a file called "metadata.desktop"
[21:16] <Riddell> and here's the full thing
[21:16] <Riddell> http://people.canonical.com/~jriddell/plasma-python/hello-python/metadata.desktop
[21:16] <Riddell> so if you were following closely, you'll have worked out that code/main.py will be where the real code is
[21:17] <Riddell> cd contents/code  and emacs code.py
[21:17] <Riddell> we all use emacs don't we? :)
[21:17] <Riddell> sorry   emacs main.py
[21:18] <Riddell> python always starts with importing the relevant libraries
[21:18] <Riddell> in this case it's PyQt and PyKDE
[21:18] <Riddell> from PyQt4.QtCore import *
[21:18] <Riddell> from PyQt4.QtGui import *
[21:18] <Riddell> from PyKDE4.plasma import Plasma
[21:18] <Riddell> from PyKDE4 import plasmascript
[21:19] <Riddell> we want to make a class inheriting from the plasma Applet base class
[21:19] <Riddell> if you know object orientated programming, python is very simple
[21:19] <Riddell> class HelloPython(plasmascript.Applet):
[21:19] <Riddell>     def __init__(self,parent,args=None):
[21:19] <Riddell>         plasmascript.Applet.__init__(self,parent)
[21:20] <Riddell> that's the class header and the constructor, which just calls the parent constructor
[21:20] <Riddell> we want an init() method to do some basic setup
[21:20] <Riddell>     def init(self):
[21:20] <Riddell>         self.setHasConfigurationInterface(False)
[21:20] <Riddell>         self.resize(125, 125)
[21:20] <Riddell>         self.setAspectRatioMode(Plasma.Square)
[21:21] <Riddell> Plasma prefers we don't do the basic setup in the constructor so it gives us this separate init() method instead
[21:21] <Riddell> the code should be pretty self readable because KDE APIs are like that, and Python is clean as programming languages come
[21:22] <Riddell> the main body we're interested in is the paint method which will paint our hello message
[21:22] <Riddell>     def paintInterface(self, painter, option, rect):
[21:22] <Riddell>         painter.save()
[21:22] <Riddell>         painter.setPen(Qt.white)
[21:22] <Riddell>         painter.drawText(rect, Qt.AlignVCenter | Qt.AlignHCenter, "Hello Kubuntu!")
[21:22] <Riddell>         painter.restore()
[21:22] <Riddell> which is also pretty self explanatory, it uses the painting object to put some text on the screen
[21:23] <Riddell> finally plasma needs us to create the applet object from our class
[21:23] <Riddell> def CreateApplet(parent): return HelloPython(parent)
[21:23] <Riddell> the whole code can be found here http://people.canonical.com/~jriddell/plasma-python/hello-python/contents/code/main.py
[21:24] <Riddell> next we need to package it
[21:24] <Riddell> go back to your top level directory and put it into a zip file
[21:24] <Riddell> zip -r hello-python hello-python
[21:25] <Riddell> finally install it with plasmapkg
[21:25] <Riddell> plasmapkg -i hello-python.zip
[21:25] <Riddell> it will say if it installed correctly or not
[21:25] <Riddell> if it's installed correctly you should be able to add it as a widget to your plasma desktop
[21:25] <Riddell> or if you're not using KDE you can use plasmoidviewer
[21:26] <Riddell> plasmoidviewer hello-python
[21:26] <Riddell> with any luck it'll look a bit like this http://people.canonical.com/~jriddell/plasma-python/hello-python.png
[21:27] <Riddell> you can get the zip file from http://people.canonical.com/~jriddell/plasma-python/hello-python.zip incase you didn't get all the code
[21:27] <Riddell> whoever manages that successfully first gets a free beer
[21:27] <Riddell> agateau: want to take them to the next level?
[21:28] <agateau> Riddell: yup!
[21:28] <agateau> So,
[21:28] <agateau> We will continue with widgets
[21:29] <agateau> So far the created plasmoid draws text itself in the paintInterface() method
[21:29] <agateau> This is quite powerful because you get a very fine control over what you want to draw
[21:29] <agateau> but it can also lead to inconsistency if every plasmoid draw things their way
[21:30] <agateau> To help with this, plasma comes with a quite complete set of widgets
[21:30] <agateau> You can use regular Qt widgets in a Plasmoid,
[21:31] <agateau> but using Plasma widgets is a better idea because they will match the plasma theme
[21:31] <agateau> and you will get fancy effects for the same price
[21:31] <agateau> A good example of a plasmoid which uses Plasma widgets is powerdevil
[21:31] <agateau> http://people.canonical.com/~agateau/udw/powerdevil.png
[21:32] <agateau> as you can see, we can use labels, slidesrs, comboboxes, buttons...
[21:32] <agateau> quite a few things
[21:32] <agateau> let's modify the previous example to use widgets instead of custom painting
[21:33] <agateau> I suggest you make a copy of the hello-python dir
[21:33] <agateau> just make sure you rename the plasmoid
[21:33] <agateau> - edit metadata.desktop
[21:34] <agateau> - change X-KDE-PluginInfo-Name value to hello-widget
[21:34] <agateau> now go to our new copy of main.py
[21:35] <agateau> We no longer need paintInterface() so we can remove it
[21:35] <agateau> instead we are going to add some lines to the init() method
[21:35] <agateau> First we create a label:
[21:35] <agateau> label = Plasma.Label(self.applet)
[21:36] <agateau> And define some text in it:
[21:36] <agateau> label.setText("Hello world!")
[21:36] <agateau> Notice that we used self.applet, not self when we created the label
[21:37] <agateau> This is little Python Plasma quirk, just remember to use self.applet as a parent for your widgets and all will be fine
[21:37] <agateau> If you try it like this, your plasmoid won't behave very well when resized
[21:38] <agateau> We need to assign a layout to the plasmoid and add our label to it
[21:38] <agateau> a layout is like an organizer: it ensure widgets are correctly aligned and resized when the plasmoid gets resized
[21:38] <agateau>  self.layout = QGraphicsLinearLayout(Qt.Horizontal, self.applet)
[21:39] <agateau> Here it is, an horizontal layout
[21:39] <agateau> now we add our label to it
[21:39] <agateau> self.layout.addItem(label)
[21:39] <agateau> And it should be good
[21:39] <agateau> You can give it a try in the same way Riddell shown you with the first plasmoid
[21:40] <agateau> cd to the hello-widget/ dir
[21:40] <agateau> zip -r ../hello-widget.zip .
[21:40] <agateau> plasmoidviewer hello-widget
[21:40] <agateau> oups...
[21:40] <agateau> forgot the install step
[21:41] <agateau> plasmapkg -i ../hello-widget.zip
[21:41] <agateau> then plasmoidviewer hello-widget
[21:41] <agateau> (actually, you can install from the dir directly, "plasmapkg -i ." will work fine)
[21:42] <agateau> Did you get a widget-powered "Hello world" plasmoid?
[21:42] <agateau> If you want to try more widgets, you can have a look at the list of Plasma classes:
[21:43] <agateau> http://api.kde.org/4.2-api/kdelibs-apidocs/plasma/html/annotated.html
[21:43] <agateau> (It's C++, but the doc is usable in Python with no changes)
[21:43] <agateau> Since KDE 4.3, there is even a VideoWidget!
[21:44] <agateau> With this, I am going to leave you in the expert hands of Riddell
[21:44] <Riddell> we had some questions over in -chat
[21:44] <Riddell> 21:28 < NamShub> Question: I would like to learn how to add a configuration dialog and read/write settings from this dialog
[21:44] <Riddell> which was well answered by fliegenderfrosch
[21:44] <Riddell> 21:31 < fliegenderfrosch> NamShub: setHasConfigInterface(True), then you reimplement the functions showConfigurationInterface(self) and createConfigurationInterface(self, parent)
[21:44] <Riddell> 21:31 < fliegenderfrosch> showConfigurationInterface(self) basically just creates a KPageDialog and calls createConfigureInterface with it as argument
[21:45] <Riddell> as I said KDE APIs are designed to be easy to read so just read the docs
[21:45] <Riddell> I also pointed NamShub to plasma-widget-googlecalendar as a larger example which has recently been added to karmic
[21:45] <Riddell> fliegenderfrosch wanted to know when the apidocs for PyKDE 4.3 are available?
[21:46] <Riddell> that'll happen when Sime gets some spare time, he maintains PyKDE single handed and is quite the hero
[21:46] <Riddell> in the mean time the 4.2 API is pretty good http://api.kde.org/pykde-4.2-api/plasma/index.html
[21:46] <Riddell> and you can always use the C++ API docs and convert them easily enough http://api.kde.org/4.x-api/kdelibs-apidocs/plasma/html/index.html
[21:47] <Riddell> I'll quickly take you through a more complete example
[21:48] <Riddell> copy your hello-widget directory to powerchart
[21:48] <Riddell> and edit metadata.desktop to give it a Name=Power Chart and X-KDE-PluginInfo-Name=powerchart
[21:48] <Riddell> I'll not paste the whole of the code but you can find it here http://people.canonical.com/~jriddell/plasma-python/powerchart/contents/code/main.py
[21:49] <Riddell> this example is a battery monitor
[21:49] <Riddell> it uses a powerful tool in Plasma, the data engine
[21:49] <Riddell> data engines are plugins which provide some useful data, could be about the network status or could be about a blog feed
[21:50] <Riddell> the engine can be used by several applets if they have a need for it
[21:50] <Riddell> Plasma's API is full of useful GUI widgets as agateau said earlier
[21:50] <Riddell> and this example uses a widget called a SignalPlotter:  self.chart = Plasma.SignalPlotter(self.applet)
[21:51] <Riddell> which draws a chart for us
[21:51] <Riddell> the connectToEngine() method creates a dataengine of type 'soliddevice'
[21:51] <Riddell> Solid is the KDE library which gives us information about all sorts of hardware
[21:52] <Riddell> it's cross platform so it'll work on Linux, BSD, Windows and more
[21:52] <Riddell> with a simple  self.engine.connectSource(battery, self)  our applet will get called whenever the solidengine reports a change in the battery
[21:52] <Riddell> dataUpdated() will get called and that grabs the battery value and puts it into the SignalPlotter widget
[21:53] <Riddell> it looks like this http://people.canonical.com/~jriddell/plasma-python/powerchart.png
[21:54] <Riddell> as you can tell, the power of KDE is in its libraries and APIs, you can do a lot with a little code
[21:54] <Riddell> http://people.canonical.com/~jriddell/plasma-python/powerchart.zip is the final code
[21:55] <Riddell> we're almost out of time
[21:55] <Riddell> any questions?
[21:55] <Riddell> RainCT rightly noted that Encoded= isn't needed in .desktop files any more, so that's one less line of code needed :)
[21:55] <Riddell> we have lots of plasmoid packaged in karmic now
[21:56] <Riddell> and you can get loads more from the Get New Stuff button in Plasma which downloads them from kde-look.org
[21:56] <Riddell> if you have an interesting applet written do put it on kde-look.org
[21:56] <Riddell> and if you find an interesting applet that a lot of people would be interested in, we probably want it packaged up into a .deb, which is pretty easy
[21:57] <Riddell> join us in #kubuntu-devel if you want to help or ask developer questions
[21:57] <Riddell> or #plasma for more detailed plasma knowledge
[21:57] <Riddell> these tutorials came from techbase.kde.org
[21:57] <Riddell> http://techbase.kde.org/Development/Tutorials/Plasma
[21:58] <Riddell> you can find loads of useful information on techbase (and if it's not there, it's a wiki so edit!)
[21:58] <Riddell> 21:56 < keffie_jayx_> QUESTION: is there a guide for packaging these plasmoids to keep in a PPA or something?
[21:58] <Riddell> there's the normal packaging guide on the ubuntu wiki
[21:59] <Riddell> for examples of Python Plasmoid packaging you can look at plasma-widget-facebook say in karmic
[21:59] <agateau> an interesting alternative distribution channel is kde-look,
[21:59] <Riddell> as agateau said you can upload it to kde-look.org so others can download it with Get New Stuff
[21:59] <Riddell> :)
[22:00] <Riddell> and if you want the package in the main Ubuntu archive put it on Revu and ping us on #kubuntu-devel to review it
[22:00] <Riddell> time up, anything to add agateau?
[22:00] <agateau> no, except that we are waiting for your plasmoids!
[22:01] <Riddell> thanks for coming everyone
[22:02] <Riddell> logs are online already at http://irclogs.ubuntu.com/2009/08/31/%23ubuntu-classroom.html
[22:03] <agateau> We should give appropriate credits:
[22:04] <agateau> Oh, actually Riddell did :)
[22:05] <Riddell> thanks to Simon Edwards for the tutorial and for PyKDE :)
[22:05] <Riddell> the logs are also at https://wiki.kubuntu.org/MeetingLogs says ausimage