[05:28] <abhi_nav> testing
[08:35] <ubuntu4menick> test
[09:27] <maja87> hi
[09:32] <qwebirc45021> hou
[10:15] <kim0> 2~/join #ubuntu-classroom
[11:15] <malcolmci> What timezone is the schedule represented in?
[11:15] <abhi_nav> UTC
[11:15] <abhi_nav> malcolmci, ^^
[11:16] <malcolmci> So the first session is in 8 hours, roughly?
[11:17] <abhi_nav> malcolmci, hmm
[11:17] <malcolmci> *6 hours
[11:17] <abhi_nav> may be
[11:17] <malcolmci> abhi_nav: seems so. thankyou :)
[11:18] <abhi_nav> malcolmci, :)
[11:18] <rww> http://www.worldtimeserver.com/current_time_in_UTC.aspx
[11:19] <umang> Or run `date -d "4:00pm UTC"`
[11:20] <malcolmci> umang: very handy. didn't know about date - cheers
[11:20] <umang> :)
[11:49] <rww> I did know about date, but didn't know it could do /that/. My days of confusing timezone fingermath are over \o/
[11:58] <mindaugas-bu> i still trying to figure out the time...
[11:58] <abhi_nav> mindaugas-bu, run date -u it shows current UTC then compare it with your time
[11:59] <rww> mindaugas-bu: Ubuntu Developer Week starts at 1600 UTC. It's currently around 1100 UTC
[11:59] <mindaugas-bu> yea. that means it starts in 7hours...
[11:59] <rww> 5, actually
[11:59] <mindaugas-bu> oh yeah
[11:59] <mindaugas-bu> just woke up
[12:00] <mindaugas-bu> brain no work :)
[13:36] <lukejduncan> goodmorning (if it's morning for you) jaeklChristian
[14:56] <GreenDance> Hi
[14:57] <GreenDance> who will be holding todays event?
[14:58] <rww> GreenDance: the presenters are listed on the timetable at https://wiki.ubuntu.com/UbuntuDeveloperWeek
[14:58] <dholbach> GreenDance: https://wiki.ubuntu.com/UbuntuDeveloperWeek has the names of session leaders
[14:58] <GreenDance> Thank You
[14:58] <GreenDance> Can't be long now till it start's :)
[14:59] <rww> GreenDance: two hours :)
[15:00] <GreenDance> rww: this will be my first attendance to an event :)
[15:01] <volo> hu
[15:01] <mindo_ltu> u not the only one out there
[15:01] <GreenDance> rww: does the channel get muted while the host talks?
[15:01] <mindo_ltu> i finaly find some free minutes to install irc and join this channel
[15:02] <rww> GreenDance: See https://wiki.ubuntu.com/UbuntuDeveloperWeek/Rules . Sometimes with these things it's +m, sometimes people just don't speak.
[15:03] <GreenDance> :)
[16:05] <ean5533> jeybee444: Here's your test 2
[16:58] <GreenDance> 5 minutes to go :)
[16:58] <chilicuil> :O!
[16:59] <YoBoY> bonjour :)
[16:59] <tripgod> hola
[16:59] <sarhan> hello
[17:00] <dholbach> WELCOME TO UBUNTU DEVELOPER WEEK!
[17:00] <gnuovo> Buongiorno. Hello! Where is ubuntu-classroom-it ?
[17:00] <dholbach> gnuovo: just join the channel
[17:00] <dholbach> Ok, first things first:
[17:00] <gnuovo> i can't find it
[17:00] <dholbach> please all join #ubuntu-classroom-chat
[17:00] <dholbach> and please just speak in there
[17:00] <dholbach> this room is for session discussion only
[17:01] <dholbach> if you have questions, please ask them in #ubuntu-classroom-chat or any of the language-specific chat rooms listed at https://wiki.ubuntu.com/UbuntuDeveloperWeek
[17:01] <dholbach> we have lots of helpers here and other interested folks who are very happy to help you out when you run into trouble
[17:01] <dholbach> if you ask a question about anything specific to the session, please write something like this in the channel:
[17:02] <dholbach> QUESTION: What is Daniel's dog called?
[17:02] <dholbach> don't forget the "QUESTION:" so it stands out and is easier to see :)
[17:02] <dholbach> alright, with the organisational bits sorted out, let the fun begin :-D
[17:03] <dholbach> My name is Daniel Holbach, I'm an Ubuntu Developer, have been hanging around here since 2004 and work for Canonical for a few years now
[17:03] <dholbach> I love the Ubuntu Developer community, so if you join at some stage, you'll make me very very happy
[17:03] <dholbach> everything of importance is on https://wiki.ubuntu.com/UbuntuDeveloperWeek
[17:04] <dholbach> that includes session details, the timetable, how to join in, a glossary and lots of other stuff
[17:04] <dholbach> I hope you'll have as great a time as I do, so let's kick this week of with "Getting Started with Ubuntu Development"
[17:04] <dholbach> in the first part of the session I'd like to practically help you get a couple of tools installed and an environment set up in which you can work on your first few bugs, etc :)
[17:05] <dholbach> in the second part we'll actively have a look at a few bugs and fix them together
[17:05] <dholbach> in those sessions I'd love to resolve as many questions as possible
[17:05] <dholbach> so if I don't make sense, my instructions don't work, or I missed something, please let me know
[17:05] <dholbach> and please: if you like the event: tell your friends and blog about it
[17:05] <dholbach> alright
[17:05] <dholbach> let's get started :)
[17:06] <dholbach> first of all: please do me a favour and bookmark https://wiki.ubuntu.com/MOTU/GettingStarted because it links to all the important pages you'll need in your life
[17:06] <dholbach> one of them I'd like to highlight first: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[17:06] <dholbach> if you work on Ubuntu, it's important that you run the latest development release
[17:06] <dholbach> you don't need to run it as your main system, but in a virtual machine, or a spare partition or a spare computer, that's cool
[17:06] <dholbach> why?
[17:07] <dholbach> simple: because this way you'll refer to all the current development libraries, modules and stuff and you can test packages better
[17:07] <dholbach> also do we want to fix all of our bugs first in the development release, then in other releases (if at all applicable, but more on that later)
[17:07] <dholbach> so if you don't have a virtual machine or chroot or anything set up, that's fine for now, but please do it later on
[17:08] <dholbach> the link I mentioned above has good instructions on this
[17:08] <dholbach> ok, so first of all please enable "Source code" and "universe" in System → Software Sources → Ubuntu Software
[17:08] <dholbach> (if you already have, you're fine :-))
 QUESTION: wouldn't it make sense to do that now? because you need to download a lot of things/packages etc
[17:09] <dholbach> tillux: no, it'd take too much time
[17:09] <dholbach> tillux: and it's fine - you can just copy the instructions later on
 QUESTION: What programming language r u going to be using?
[17:10] <dholbach> umutuygar: we'll see :-) I think for now I'll stick to packaging basics where we fix a couple of bugs
 QUESTION: will this be GNOME-centric?
[17:10] <dholbach> BeardyGnome13: no, not at all
[17:10] <dholbach> alright, next please
[17:10] <dholbach> sudo apt-get install --no-install-recommends bzr-builddeb ubuntu-dev-tools fakeroot build-essential gnupg pbuilder debhelper
[17:10] <dholbach> this will give you a bunch of tools that are going to be useful generally, not just in these examples
[17:11] <dholbach> somethinginteres: bzr-builddeb pulls in bzr which we'll use to get the source code for one or two examples
[17:11] <dholbach> ubuntu-dev-tools pulls in devscripts which both are incredibly helpful at making repetitive packaging tasks easy
[17:12] <dholbach> fakeroot is needed by debuild (in devscripts) to mimic root privileges when installing files into a package
[17:12] <dholbach> build-essential pulls in lots of useful very basic build tools like gcc, make, etc
[17:12] <dholbach> gnupg is used to sign files in our case (uploads in the future)
[17:12] <dholbach> pbuilder is a build tool that builds source in a sane, clean and minimal environment it sets up itself
[17:13] <dholbach> debhelper contains scripts that automate lots of the build process in a package
[17:13] <dholbach> let's first set up our gpg key
[17:13] <dholbach> as I said above we use it to sign files for upload
[17:14] <dholbach> but more generally it is used to sign and encrypt mails, files or text generally
[17:14] <dholbach> we use it to indicate that WE were the last to touch a file and not somebody else
[17:14] <dholbach> that ensures that only people who we know about get to upload packages
[17:14] <dholbach> please run
[17:14] <dholbach>   gpg --gen-key
[17:14] <dholbach> (if you have no gpg key yet)
[17:15] <dholbach> sticking to the defaults is totally fine, for example don't you need a comment
[17:15] <dholbach> if you need more info on gpg keys, head to https://help.ubuntu.com/community/GnuPrivacyGuardHowto which talks about everything in more detail
[17:15] <dholbach> enter your name, email address and just stick to the default values for now
[17:16] <dholbach> it could be that gpg is still sitting there and waiting for more random data to generate your key - that's expected and fine
[17:16] <dholbach> just open another terminal while we carry on, it'll finish on its own
[17:16] <dholbach> as I said: if you have a gpg key already, skip this step
[17:16] <dholbach> in the meantime we'll set up pbuilder
[17:17] <dholbach> please open an editor and edit the file ~/.pbuilderrc (create if you don't have it yet)
[17:17] <dholbach> please add the following content to the file
[17:17] <dholbach> COMPONENTS="main universe multiverse restricted"
[17:17] <dholbach> and save it
[17:18] <dholbach> once you're done, please run
[17:18] <dholbach>   sudo pbuilder create
[17:18] <dholbach> this will also take some time, so let's chat a bit about pbuilder
[17:18] <dholbach> what does it do?
[17:18] <dholbach> it builds packages in a clean and minimal environment
[17:18] <dholbach> it keeps your system "clean" (so you don't install millions of build dependencies on your own system)
[17:19] <dholbach> it makes sure the package builds in a minimal, unmodified environment
[17:19] <dholbach> so you ensure that the package does not just build because you made lots of changes on your system, but the build is reproducable
[17:19] <dholbach> you can update package lists (later on) with: sudo pbuilder update
[17:20] <dholbach> and to build packages you run: sudo pbuilder build package_version.dsc
 QUESTION: will the transcript of the classroom be available later?
 QUESTION: Will there be full log available?
[17:20] <dholbach> yes
[17:20] <dholbach> it will be linked from https://wiki.ubuntu.com/UbuntuDeveloperWeek
[17:20] <dholbach> for the impatient: http://irclogs.ubuntu.com
[17:21] <dholbach> ok, so how pbuilder works is like this: it first gets the minimal packages for a base system, stores them in a tarball, whenever you build a package it'll untar the base tarball, then install whatever your current build requires, then build it, then tear it all down again
[17:21] <dholbach> luckily it caches the packages :)
 QUESTION: To confirm, the install of pbuilder etc should be done -right now- on our main box?
[17:22] <dholbach> somethinginteres: it helps as you can perform the examples on your own machine and have it set up later on too
[17:22] <dholbach> ok, what's next while gpg and pbuilder are doing their thing
[17:23] <dholbach> we tell some other tools who we are
[17:23] <dholbach> if you use the bash shell, which is the default, please edit ~/.bashrc
[17:23] <dholbach> and at the end of it, please add something like
[17:23] <dholbach> DEBFULLNAME="Daniel Holbach"
[17:23] <dholbach> DEBEMAIL="daniel.holbach@ubuntu.com"
[17:23] <dholbach> and save it
[17:23] <dholbach> PLEASE USE YOUR OWN NAME, THANKS :-)
 QUESTION: I am doing everything in my main day to day usable machine. is it ok? I dont want anything to ruine my cute ubuntu. :)
[17:24] <dholbach> abhi_nav: yes, it'll be fine
[17:24] <dholbach> once you're done editing ~/.bashrc, please run   source ~/. bashrc  (it's only needed once)
 QUESTION: Should these match the values we put into GPG?
[17:24] <dholbach> tpw_rules87: yes
[17:25] <dholbach> ok, with this out of the way, the packaging tools will know you by your name and you don't need to enter it, for example if you do changelog entries, etc.
[17:25] <dholbach> are there any more questions up until now?
 QUESTION: where is the .bashrc file located?
[17:26] <dholbach> augdawg:  ~/.bashrc
[17:26] <dholbach> so /home/<your user name>/.bashrc
 QUESTION do i need to write my that email which i was used to create gpgp key some months ago? now I have another email
[17:27] <dholbach> abhi_nav: yes, it helps to have the same in there, but you can also add another user id to your gpg key later on
[17:27] <dholbach> refer to https://help.ubuntu.com/community/GnuPrivacyGuardHowto for that
 QUESTION: is the preferred arch for dev'ing AMD64 or i386 ?
[17:27] <dholbach> malcolmci: every supported architecture of ubuntu will work fine
 QUESTION: Will this session revolve around packaging bugs, or bugs in general?
[17:28] <dholbach> devildante: I picked a few packaging bugs, but maybe we'll do something else later on, let's see :)
 QUESTION: what does the ~ mean?
[17:28] <dholbach> my user name is "daniel"
[17:28] <dholbach> so ~ for me will be expanded to /home/daniel
 QUESTION: for those running on lucid: should pbuilder have been triggered with "--distribution maverick" ?
[17:29] <dholbach> tillux: for now that's fine - if you set up a maverick chroot/virtual-machine/partition/machine later on, you can just repeat the steps
[17:29] <dholbach> for this sessions it's irrelevant
 QUESTION: is my gpg key machine-specific?
[17:29] <dholbach> BeardyGnome13: no, you can just copy it to another machine
 QUESTION: PBuilder is downloading for Lucid, should it be downloading for Mavrick or Lucid?
[17:29] <dholbach> somethinginteres: see what I just said to tillux above
 QUESTION: i hate to ask , but will pbuilder create eat up my b/w .. i'm on a limited b/w connection ...
[17:29] <dholbach> theneoindian: you better stop it then and repeat later on on a different connection
[17:30] <dholbach> alright
[17:30] <dholbach> thanks for the great questions
[17:30] <dholbach> I don't know how quick your pbuilders and gpgs are, so I'll keep talking a bit about ubuntu development and how it all works, we'll make some good use of pbuilder and your shiny new gpg key later on :)
[17:31] <dholbach> first things first: ubuntu is very special in how it's produced and how we all work
[17:31] <dholbach> as you know it comes out every 6 months
[17:31] <dholbach> that means we have a tight release schedule and everything we do and work on is defined by that schedule
[17:32] <dholbach> check out https://wiki.ubuntu.com/MaverickReleaseSchedule for the current release schedule for maverick
[17:32] <dholbach> the quick version: green means: lots is allowed here, red means: almost nothing is allowed here :)
[17:33] <dholbach> long version:
[17:33] <dholbach>  - toolchain is uploaded for the new release (gcc, binutils, libc, etc.), so the most basic build tools are there
[17:33] <dholbach>  - new changes that happened in the meantime are synced or merged (more on that later on)
[17:34] <dholbach>  - ubuntu developer summit (uds) happens where features are defined and talked about
[17:34] <dholbach>  - up until debian import freeze we import source changes from debian semi-automatically
[17:34] <dholbach>  - up until feature freeze we get new stuff in, work on features, try to make it all work
[17:34] <dholbach>  - if a feature is not half-way there yet by feature freeze, it will likely get deferred to the next release
[17:35] <dholbach>  - from feature freeze on you can see that lots of freezes are added throughout the weeks and you'll need more and more freeze exceptions for big changes
[17:35] <dholbach> the focus is clearly: testing, testing, testing and fixing, fixing, fixing
[17:35] <dholbach> the more obvious fixes are (a huge 20 million line patch is not obvious) :)
[17:35] <dholbach> the more obvious the better
[17:36] <dholbach> the same goes for fixes that are introduced AFTER the release
[17:36] <dholbach> we just want to fix stuff in ...-updates if it's REALLY URGENT stuff with really simple fixes
[17:37] <dholbach> so as you can imagine, this means: introduce big changes early in the release cycle, so we can shake out problems over a longer time
 dholbach: On the release schedule, I see a column named "Work Item Iteration"
[17:37] <dholbach> ah yes
[17:38] <dholbach> if you check out http://people.canonical.com/~pitti/workitems/maverick/all-ubuntu-10.10.html you will see a graph and loads of text
[17:38] <dholbach> this is a list of work items defined by specifications written at the ubuntu developer summit
[17:39] <dholbach> work items are specific pieces of work that somebody at UDS decided to work on during the cycle
[17:39] <dholbach> it's more a tool for the managers at Canonical to keep their people busy
[17:39] <dholbach> I mean… make sure we're on track ;-)
 QUESTION: (I've asked this during the Userday as well but am wondering as to your input) Do you feel that the fast release cycle of Ubuntu might be hindering it's progress? It seems a lot of time is spent in freezing and testing rather than working out new features.
[17:39] <dholbach> marceau: not at all - I think it's a good thing - it forces us to stay focused and make sure that stuff gets done
[17:40] <dholbach> marceau: if we don't get a feature done this cycle, it'll be next cycle
[17:40] <dholbach> also it's important for everybody else who works with the project, as it's very easily predictable
[17:40] <dholbach> alright, enough cycle discussions :)
[17:41] <dholbach> another thing I'm keen to talk about is: how to get stuff in
[17:41] <dholbach> when I spoke about gpg you noticed that I said that only people who "we know" get to upload packages directly
[17:41] <dholbach> this means that as a new contributor you will have to work with sponsors who basically review your work and upload it for you
[17:42] <dholbach> once you did that a couple of times and they recognise you and your good work, you can apply for ubuntu developer membership
[17:42] <dholbach> and you can ask the people you've worked with for comments on your application
[17:43] <dholbach> it's really not very complicated, you basically set up a wiki page with your contributions, ask for comments and submit for an irc meeting of the developer membership board and you're done
[17:43] <dholbach> no need to learn a secret handshake, send me money or anything else
[17:43] <dholbach> it's contributions and good work that counts
[17:43] <dholbach> it helps if you're a team player :)
 QUESTION: what does an ubuntu developer membership get you?
[17:44] <dholbach> augdawg: https://wiki.ubuntu.com/UbuntuDevelopers will tell you :)
[17:44] <dholbach> the most obvious thing is that you can upload changes yourself
 QUESTION: But will sending you money help the process? *wink*
[17:44] <dholbach> prayii: unfortunately I'm not on the Developer Membership Board :)
 QUESTION: so when your a member do you get the ability to fix bugs smewhat more indepedently, trying to word it right
[17:44] <dholbach> tech2077: it's a question of trust: once you demonstrated that you do good work, you can get upload rights
[17:44] <dholbach> tech2077: same goes for Ubuntu membership
[17:45] <dholbach> people get an @ubuntu.com email address when they can be recognised for their good work in Ubuntu
 QUESTION: what is the expected knowledge level of people taking part in this week's sessions?
[17:45] <dholbach> marceau: I guess it will differ from session to session: in this session it's good enough to be curious and have played with a terminal before and have a knack for making things work again :)
 QUESTION: is it the case that being an Ubuntu dev means being a programming vet or are there plenty of opportunity for n00bs to learn and contribute something..?
[17:46] <dholbach> there are lots of opportunities to learn, which is why we're doing this whole thing :)
 QUESTION: If I'd like to contribute to both Ubuntu and Debian, which should I use?
[17:46] <dholbach> umang: you can contribute to Debian by using Ubuntu and collaborating with Debian developers
[17:46] <dholbach> umang: it totally depends on you what you use and what you work on
[17:46] <dholbach> alright
[17:46] <dholbach> let's take more questions later on again
[17:46] <dholbach> my fingers are hurting already
[17:46] <dholbach> just kidding
[17:47] <dholbach> I assume pbuilder is done setting up, if not, do this later on
[17:47] <dholbach> apt-get source hello
[17:47] <dholbach> (it will download the source of the hello package)
[17:47] <dholbach> now please run
[17:47] <dholbach> sudo pbuilder build hello_*.dsc
[17:47] <dholbach> this will kick off the build in the form I explained earlier
 QUESTION: what .dsc stands for?
[17:48] <dholbach> abhi_nav: great question
[17:48] <dholbach> what "apt-get source" downloads is:
[17:49] <dholbach> (in most cases) an .orig.tar.gz file, which contains the source code of the software in a tarball released by the software authors
[17:49] <dholbach> in some cases a .diff.gz file with changes that were applied to make the package build in the Ubuntu/Debian way
[17:49] <dholbach> and a .dsc file with metadata like checksums and the like
[17:49] <dholbach> it's really not that important right now
[17:49] <dholbach> once the build is done, you can check out the contents of /var/cache/pbuilder/result
[17:50] <dholbach> it will contain the built hello .deb file :)
[17:50] <ClassBot> There are are 10 minutes remaining in the current session.
[17:50] <dholbach> ok, let's deal with gpg (for those that have not set it up yet)
[17:51] <dholbach> if you run
[17:51] <dholbach>   gpg --fingerprint your.name@email.com
[17:51] <dholbach> it will print out something like:
[17:51] <dholbach> pub   1024D/059DD5EB 2007-09-29
[17:51] <dholbach>       Key fingerprint = 3E5C 0B3C 8987 79B9 A504  D7A5 463A E59D 059D D5EB
[17:51] <dholbach> uid                  Daniel Holbach <dh@mailempfang.de>
[17:51] <dholbach> ...
[17:51] <dholbach> in the example above, my KEY ID is 059DD5EB
[17:51] <dholbach> please run
[17:51] <dholbach>   gpg --send-keys <KEY ID>
[17:52] <dholbach> it will upload your _public_ portion of the key to keyservers which will sync the key among them
[17:52] <dholbach> once that's done, you can tell Launchpad, which we use for all development about your shiny new gpg key
[17:52] <dholbach> https://launchpad.net/people/+me/+editpgpkeys
[17:53] <dholbach> (you need a Launchpad account for this)
[17:53] <dholbach> https://help.launchpad.net/YourAccount/ImportingYourPGPKey should help you if you run into any trouble
 QUESTION: gpg: no keyserver known (use option --keyserver)
[17:54] <dholbach> try:     gpg --keyserver keyserver.ubuntu.com --send-keys <KEY ID>
[17:55] <dholbach> alright, let's take a 5 minute break in which you can set up launchpad account and tell launchpad about your key, or get a cold beverage, or just relax for a bit
[17:55] <dholbach> in the next part of the session, we'll go and work on a few bugs together :)
[17:55] <ClassBot> There are are 5 minutes remaining in the current session.
[18:00] <dholbach> Alright, we're back for part 2!
[18:00] <dholbach> two things I'd like to get out again are:
[18:01] <dholbach>  - https://wiki.ubuntu.com/MOTU/GettingStarted (bookmark it, please)
[18:01] <dholbach>  - #ubuntu-motu and #ubuntu-packaging on irc.freenode.net are great channels with great people who can help you answer your questions - you'll find lots of friends there
[18:01] <dholbach> do we have any more questions about the session before or are we ready to roll and fix a few bugs?
 QUESTION: fingerprint authent. on lanchpad wont work
[18:02] <dholbach> please follow https://help.launchpad.net/YourAccount/ImportingYourPGPKey very closely
[18:02] <dholbach> and try again
[18:02] <dholbach> if it doesn't work, talk to the fine people in #launchpad
[18:02] <dholbach> they can sort you out
 QUESTION: Will we fix real bugs?
[18:02] <dholbach> devildante: YES
[18:02] <dholbach> ready to go?
[18:03] <dholbach> ROCK ON, that's how we like it!
[18:03] <dholbach> ok, I'd like to introduce you to a very real sort of bugs, FBTFS bugs
[18:03] <dholbach> and with that a new acronym, FTBFS means Fails To Build From Source
[18:04] <dholbach> if a package doesn't build, it can be because all kinds of crazy things
[18:04] <dholbach> sometimes the source code is actually broken, sometimes it's because we lack the right version of some development library, etc etc etc
[18:05] <dholbach> it's something you'll probably struggle with a couple of times as an aspiring developer :)
[18:05] <dholbach> so let's head to http://qa.ubuntuwire.org/ftbfs/ - it shows a list of packages that FTBFS (yes it's used as a verb) right now
[18:05] <dholbach> let's first have a look at http://launchpadlibrarian.net/50406598/buildlog_ubuntu-maverick-i386.pykickstart_1.74-1_FAILEDTOBUILD.txt.gz
[18:05] <dholbach> it's the compressed log of the build on launchpad
[18:06] <dholbach> so what you just saw when you ran pbuilder, just on lots of machines in Launchpad :)
[18:06] <dholbach> first part is the installation of necessary packages, last part is the deinstallation of packages
[18:07] <dholbach> so close to the end of the log you'll find this
[18:07] <dholbach>    dh_usrlocal
[18:07] <dholbach> dh_usrlocal: debian/python-pykickstart/usr/local/bin/ksvalidator is not a directory
[18:07] <dholbach> dh_usrlocal: debian/python-pykickstart/usr/local/bin/ksflatten is not a directory
[18:07] <dholbach> dh_usrlocal: debian/python-pykickstart/usr/local/bin/ksverdiff is not a directory
[18:07] <dholbach> rmdir: failed to remove `debian/python-pykickstart/usr/local/bin': Directory not empty
[18:07] <dholbach> dh_usrlocal: rmdir debian/python-pykickstart/usr/local/bin returned exit code 1
[18:07] <dholbach> so something with files being installed in usr/local
[18:07] <dholbach> we, as packagers, don't do usr/local - it's against the rules :)
[18:08] <dholbach> usr/local is just for stuff the user installs manually
[18:08] <dholbach> you can find more about what goes where in the FHS (file hierarchy standard) and the debian policy document
[18:08] <dholbach> ok, remember how I said "be a team player" and "have a knack for making things work again" a couple of minutes before?
[18:09] <dholbach> it's important that when you work as a developer, you bear in mind the bigger picture
[18:10] <dholbach> "upstreams" are the software authors of packages included in ubuntu, they often release their "upstream source" on their own website, it often gets included in debian, where patches are added to make the packages build the debian (and ubuntu) way, and we often inherit the code just like that
[18:10] <dholbach> the more upstream and debian and ubuntu are in sync the better
[18:10] <dholbach> sometimes we make different decisions, but those should be for very good reasons
[18:10] <dholbach> because every deviation means additional work when merging changes later on again
[18:11] <dholbach> so, when I look at a bug like that I very often check "was it fixed in Debian or upstream already"?
[18:11] <dholbach> so the package is called pykickstart
[18:11] <dholbach> let's check out https://launchpad.net/ubuntu/+source/pykickstart
[18:11] <dholbach> as you can see, it was introduced in maverick and is at version 1.74-1 right now
[18:12] <dholbach> on the Debian side, we see similar information at http://packages.debian.org/src:pykickstart
[18:12] <dholbach> you can see that 'sid', the Debian development version, has 1.75-1 already
[18:12] <dholbach> click on the 'sid' link to get to http://packages.debian.org/source/sid/pykickstart
[18:12] <dholbach> on the right side it has a link to the debian changelog
[18:13] <dholbach> http://packages.debian.org/changelogs/pool/main/p/pykickstart/pykickstart_1.75-1/changelog
[18:13] <dholbach> so this is a regular debian/ubuntu changelog entry that states what in this package upload was changed
[18:13] <dholbach> as you can see, the maintainer wrote something about a new upstream version and
[18:13] <dholbach> "   * Update debian/rules: pass --buildsystem=python_distutils to avoid ftbfs."
[18:13] <dholbach> "avoid ftbfs" is like music to my ears - to yours too?
[18:14] <dholbach> I'd say we get the Debian source and try to build it and see if that works
[18:14] <dholbach> if you go back to http://packages.debian.org/source/sid/pykickstart - you'll see a link to a .dsc file
[18:14] <dholbach> http://ftp.de.debian.org/debian/pool/main/p/pykickstart/pykickstart_1.75-1.dsc
[18:14] <dholbach> when we installed the devscripts package earlier, we got a tool called dget
[18:15] <dholbach> we'll use that now to download the source from debian
[18:15] <dholbach> dget -xu http://ftp.de.debian.org/debian/pool/main/p/pykickstart/pykickstart_1.75-1.dsc
[18:15] <dholbach> to build it, you know already what to do:
[18:15] <dholbach>   sudo pbuilder build pykickstart_1.75-1.dsc
[18:16] <dholbach> this will take a little bit now, so let's all try to be patient and see how it works out ;-)
[18:16] <dholbach> questions up until now?
 QUESTION: Why -"xu"?
[18:17] <dholbach> Noz3001: without -x dget will not unpack the source (you're right, we could have ignored that - usually it's very helpful to get the source unpacked immediately to dive right into it)
[18:17] <dholbach> Noz3001: without -u dget will complain about a missing gpg key, because it can't confirm the identity of the uploader (you probably won't have the debian maintainer's public key in your keyring)
 QUESTION: umut@umut-laptop:~/code/ubuntu-classroom$ sudo pbuilder build pykickstart_1.75.dsc
[18:18] <dholbach> umutuygar: did you execute the dget command above in the same directory?
 QUESTION: How you get a sponsor?
[18:18] <dholbach> ElPasmo: we'll get to that in a bit, https://wiki.ubuntu.com/SponsorhipProcess if you're impatient :)
 QUESTION: can I run 2 or more pbuilder instances at the same time?
[18:19] <dholbach> chilicuil: yes, you can use pbuilder-dist (in the ubuntu-dev-tools package) for that
[18:19] <dholbach> chilicuil: also there's https://wiki.ubuntu.com/PbuilderHowto
 QUESTION: We're past the point of pulling in debian packages for Maverick aren't we? But if a package ftbfs and the debian one fixes it what happens?
[18:19] <dholbach> penguin42: I'll get to that in a sec
 QUESTION: how to add gpg into keyring?
[18:20] <dholbach> Krysis: gpg --recv-keys <KEY ID>
 QUESTION: What's the easiest way to find a nice diff of the two source packages (1.74-1 from ubuntu and 1.75-1 from debian)?
[18:20] <dholbach> nice question
[18:20] <dholbach> you'd   apt-get source pykickstart   to get the ubuntu version too
[18:20] <dholbach> then run
[18:21] <dholbach> debdiff pykickstart_1.74-1.dsc pykickstart_1.75-1.dsc
[18:21] <dholbach> (probably pipe it through less, filterdiff, etc afterwards)
[18:21] <dholbach> rww just corrected me, the link earlier should have been https://wiki.ubuntu.com/SponsorshipProcess
[18:22] <dholbach> alright, pykickstart 1.75-1 from Debian succeeded to build on my end
[18:22] <dholbach> so what do we do
[18:22] <dholbach> let me explain a bit how Ubuntu and Debian fit in to the big picture of the release schedule I described earlier
[18:23] <dholbach> up until Debian Import Freeze, we automatically sync source packages from Debian and build them in Launchpad, if:
[18:24] <dholbach>  1. the package in Ubuntu is not modified (usually obvious by reading the version number, 1.74-1 vs. 1.74-1ubuntu1)
[18:24] <dholbach>  2. if the package is in Debian main (so free software)
[18:25] <dholbach> so how do we live in this world?
[18:26] <dholbach> if we introduce a change in Ubuntu, say we go from 1.74-1 to 1.74-1ubuntu1
[18:26] <dholbach> then Debian introduces 1.75-1
[18:26] <dholbach> we need to decide if we can overwrite our changes (we sync the source)
[18:27] <dholbach> or if we need to merge the source manually
[18:27] <dholbach> it's very tempting to say "ha, no we can sync from Debian"
[18:27] <dholbach> but it's INCREDIBLY IMPORTANT to READ THE DIFF
[18:27] <dholbach> just reading the changelog is not good enough
[18:27] <dholbach> READ THE DIFF
[18:27] <dholbach> and TEST
[18:27] <dholbach>  _____ _____ ____ _____ _
[18:27] <dholbach> |_   _| ____/ ___|_   _| |
[18:27] <dholbach>   | | |  _| \___ \ | | | |
[18:27] <dholbach>   | | | |___ ___) || | |_|
[18:27] <dholbach>   |_| |_____|____/ |_| (_)
[18:27] <dholbach>                           
[18:27] <dholbach> :-)
 dholbach: who decides if we should sync with upstream debian or keep ubuntu modification, for example ?
[18:29] <dholbach> malcolmci: that's the best possible question
[18:29] <dholbach> that's the responsibility you have as a developer
[18:29] <dholbach> you need to make sure in the best way possible that the actual change can be implemented in the way you suggested
[18:30] <dholbach> if you're unsure, you can ask lots of other fine people in #ubuntu-devel or #ubuntu-motu or #ubuntu-packaging
[18:30] <dholbach> also the sponsoring process (somebody reviews your code or suggestion first) helps with that in the beginning
[18:30] <dholbach> it's just important that you do your best in making sure and testing
 dholbach: ah, so the package maintainer decides?
[18:31] <dholbach> malcolmci: in Ubuntu we don't have dedicated package maintainers, so we maintain the packages as a big team
 QUESTION: would the easiest way to test be toi just install the deb file from debian and see if it works?
[18:31] <dholbach> mickstephenson52: thanks for getting me back on track :)
[18:31] <dholbach> so, we have 1.74-1 in maverick
[18:31] <dholbach> and we have 1.75-1 in Debian sid
[18:31] <dholbach> which means that we did not introduce changes in Ubuntu, so we're sure that we don't have to merge things manually
[18:32] <dholbach> we just verified that the package builds again in the new version
[18:32] <dholbach> and we're still before feature freeze in maverick, so requesting a sync (https://wiki.ubuntu.com/SyncRequestProcess) should be fine, once we're sufficiently sure it's all good
[18:32] <dholbach> installing the .deb and see if it work is a great way
 QUESTION: I would expect that for very essential packages, like glibc, there is more than a single person to decide whether to keep or update?
[18:33] <dholbach> AudioFranky: yes, those decisions are made at UDS in a bigger group and usually there's agreement between people in Ubuntu and Debian who work on the package
[18:34] <dholbach> when I said that "we don't have dedicated maintainers" I meant that we have no "big maintainer lock" (somebody OWNS the package), but indeed we have people with a special area of expertise
[18:34] <dholbach> and that's respected
[18:34] <dholbach> alright, the path ahead seems clear: test the package, make sure it's alright, then engage with the sync request process
[18:35] <dholbach> here's some more food for though, you can try it out yourself:
[18:35] <dholbach> http://launchpadlibrarian.net/50981070/buildlog_ubuntu-maverick-i386.xdotool_1:2.20100602.2915-1_FAILEDTOBUILD.txt.gz
[18:35] <dholbach> http://launchpadlibrarian.net/50411959/buildlog_ubuntu-maverick-i386.weave_1.3-2_FAILEDTOBUILD.txt.gz
[18:35] <dholbach> but as I said: be careful and talk to people on #ubuntu-motu or #ubuntu-packaging if you're unsure
[18:35] <dholbach> being unsure is a good thing and knowing when to ask a sign of taking responsibility
[18:35] <dholbach> and that's valued
[18:36] <dholbach> alright, now I have another interesting case for us:
[18:36] <dholbach> http://launchpadlibrarian.net/49981844/buildlog_ubuntu-maverick-i386.xpad_4.0-5_MANUALDEPWAIT.txt.gz
[18:36] <dholbach> the xpad package fails to build too
[18:36] <dholbach> towards the bottom of the log you can see this:
[18:36] <dholbach> libmagickcore-extra: missing
[18:36] <dholbach> libmagickcore-extra: does not exist
[18:37] <dholbach> so this means that one of the packages that is specified as a requirement to build the xpad package is not there
[18:37] <dholbach> let's get the source code and let's try to fix it
[18:38] <dholbach> this time we'll do it differently:
[18:38] <dholbach>   bzr branch lp:ubuntu/xpad
[18:39] <dholbach> this will not get us the source package (remember the .dsc, .orig.tar.gz and .diff.gz file) but a bazaar branch (revision control system) with all revisions in Ubuntu and Debian
[18:39] <dholbach> this will take a little bit, but is worth it
[18:41] <dholbach> in the case of source packages you just get one revision, in a format that works with all the debian/ubuntu build tools, but we're slowly moving towards a world where we work with upstreams and debian and distributed version control is just what's easier to use
[18:41] <dholbach> I'd like to show you how easy to use it is
[18:41] <dholbach> alright, once bzr is done, run
[18:41] <dholbach>   cd xpad
[18:41] <dholbach> and
[18:41] <dholbach>   less debian/control
[18:42] <dholbach> let me explain a bit what this is about
[18:42] <dholbach> debian/control contains information about the source package and the resulting .deb (binary) packages
[18:43] <dholbach> in this case it's relatively simple, let's go through the source stanza first
[18:43] <dholbach> Source: specifies the nam
[18:43] <dholbach> e
[18:43] <dholbach> Section and Priority are used by the package management to have a bit of metadata
[18:43] <dholbach> Maintainer is the maintainer in Debian
[18:43] <dholbach> Build-Depends is just what we're looking for
[18:43] <dholbach> this is the minimal list of packages necessary to build the package
[18:44] <dholbach> Standards-Version is the version of the debian policy this complies with and homepage just more metadata
[18:44] <dholbach> this is all additional info regarding the source
[18:45] <dholbach> the resulting xpad package is defined in the next stanza
[18:45] <dholbach> Package: is the package name
[18:45] <dholbach> "Architecture: any" means that the package needs to get built on every individual architecture available separately
[18:45] <dholbach> somethinginteres: i386, amd64, powerpc, sparc, etc. etc.
[18:46] <dholbach> sorry somethinginteres - this was autocompleted, I meant "so"
[18:46] <dholbach> if you just put a bunch of python scripts into a package, or just some documentation that is architecture independent, you use "Architecture: all"
[18:47] <dholbach> Depends: is the list of dependencies of the resulting package
[18:47] <dholbach> these are all auto-generated
[18:47] <dholbach> shlibs:Depends is the list of library packages that contain libraries the binaries in the deb packages are linked against
[18:47] <dholbach> misc:Depends a few additional Depends that might be useful
[18:48] <dholbach> all of these complicated computations are done by scripts in the debhelper package
[18:48] <dholbach> Description too is used by the package management tools
[18:48] <dholbach> so debian/control is a file that contains lots of the definition of the package itself
[18:49] <dholbach> you can check out the other files in debian/ on your own later on, https://wiki.ubuntu.com/PackagingGuide will help you with that
 QUESTION: will we ever mess with the bottom section?
[18:49] <dholbach> bcurtiswx: we could, for example if a user tells us that there's a dependency missing or there's a typo in the package description or something
[18:51] <dholbach> so to avoid confusion: this example will just work in maverick, it's a maverick build failure
[18:51] <dholbach> if you don't run maverick right now, that's no big deal, just trust me blindly then ;-)
[18:52] <dholbach> http://launchpadlibrarian.net/49981844/buildlog_ubuntu-maverick-i386.xpad_4.0-5_MANUALDEPWAIT.txt.gz mentioned that libmagickcore-extra was missing
[18:52] <dholbach> apt-cache search libmagickcore-extra (on maverick) will reveal that it's now called libmagickcore3-extra
 QUESTION: i guess it's best to run maverick on a separate machine / VM then?
[18:53] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases has all that info
[18:53] <dholbach> ok, so we just change libmagickcore-extra to libmagickcore3-extra in debian/control
[18:53] <dholbach> and save the file
[18:54] <dholbach> if you exit your editor and run    bzr diff    you'll see your change
[18:54] <dholbach> now please run    update-maintainer    (script from ubuntu-dev-tools) to update the maintainer field which we were asked to do by our friends at debian to indicate that we made changes in the package)
[18:55] <dholbach> (sorry folks need to speed up a lil bit)
[18:55] <dholbach> now please run   dch -i
[18:55] <dholbach> also a devscripts tool which deals with all things related to debian/changelog
[18:56] <dholbach> it will automatically fill out some stuff for you
[18:56] <dholbach> you just need to enter a descriptive message for your changes
[18:56] <dholbach> I'd go for something like
[18:57] <dholbach>   * debian/control: updated build-depends from libmagickcore-extra to libmagickcore3-extra to fix FTBFS.
[18:57] <dholbach> (and wrap at 80 chars)
[18:57] <dholbach> it's important to note what you changed in which files
[18:57] <dholbach> and the more explicit you are about your changes, the easier it will be for you and others later on in understanding what you did
[18:58] <dholbach> if you close a bug with your fix, please add   (LP: #123456)
[18:58] <dholbach> this special syntax will automatically close the bug once it gets merged in
[18:58] <dholbach> now please save the file
[18:58] <dholbach> and run
[18:58] <dholbach>    bzr bd -- -S -us -uc
[18:58] <dholbach> this will build the source package from the branch
[18:59] <dholbach> (-S -us -uc are arguments for debuild which is used internally)
[18:59] <dholbach> then you move out of the directory and pbuilder the generated source package
[18:59] <dholbach> to test if that works now
[18:59] <dholbach> this will naturally take a bit
[18:59] <dholbach> once you're happy with all the  C A R E F U L   tests you did
[18:59] <dholbach> you can go back into the branch
[18:59] <dholbach> run debcommit
[19:00] <dholbach> and then push the changes to launchpad and request a merge
[19:00] <dholbach> https://wiki.ubuntu.com/Bugs/HowToFix explains the last bits
[19:00] <dholbach> sorry for running out of time
[19:00] <dholbach> I hope you enjoyed the session
[19:01] <dholbach> please check out https://wiki.ubuntu.com/MOTU/GettingStarted
[19:01] <dholbach> and join #ubuntu-motu and #ubuntu-packaging
[19:01] <dholbach> next up is Mr apachelogger, who will talk about Widgetcraft
[19:01] <dholbach> have a great day
[19:01] <dholbach> and ROCK ON!
[19:01]  * apachelogger applauds and thanks dholbach for a wonderful session
[19:01]  * dholbach hugs apachelogger
[19:01]  * apachelogger hugs the whole channel :D
[19:01] <apachelogger> brillian news everyone!
[19:01] <dholbach> as you can see, hugs are a vital ingredient of making Ubuntu ROCK :)
[19:01] <dholbach> with that I leave the stage now
[19:02] <apachelogger> welcome to an intro to widgetcraft. also known as the art of creating plasma widgets.
[19:02] <apachelogger> this talk is backed up by a set of slides that can be followed at http://docs.google.com/present/view?id=ajk6csn6c2vn_53fj6c47f6
[19:02] <apachelogger> my name is Harald Sitter, and I wish you a pleasant journey :)
[19:03] <apachelogger> first off I would like to direct your attention to important sites that will help a lot with writing plasmoids.
[19:03] <apachelogger> General tutorials on JavaScript Plasma programming are avilailable at: http://techbase.kde.org/Development/Tutorials/Plasma#Plasma_Programming_with_JavaScript
[19:03] <apachelogger> Information on Plasma packages: http://techbase.kde.org/Projects/Plasma/Package
[19:03] <apachelogger>  And a rather simplified JavaScript API: http://techbase.kde.org/Development/Tutorials/Plasma/JavaScript/API
[19:04] <apachelogger> in general I probably should mention that the kde techbase is a wonderful resource for KDE programming topics of all kinds with a vast amount of tutorials
[19:04] <apachelogger> so, lets get started.
[19:04] <apachelogger> first let me quickly get some terms straight.
[19:04] <apachelogger> -> Plasma <-
[19:04] <apachelogger> is the technology underlying the KDE workspace.
[19:05] <apachelogger> it is available in multiple different versions. on a PC you will have plasma-desktop, on a netbook possibly plasma-netbook and in the future you will be able to run plasma-mobile on your mobile device (e.g. a smart phone)
[19:05] <apachelogger> \o/ yay for plasma on my mobile ;)
[19:06] <apachelogger> even though those incarnations of plasma might look different, they all root in teh same base technology and follow the same principles
[19:06] <apachelogger> next up is -> plasmoid <-
[19:06] <apachelogger> I have already used that term. Plasmoids are sort of native Plasma Widgets.
[19:06] <apachelogger> There are also non-native widgets ;)
[19:06] <apachelogger> For example one can run Mac Widgets or Google Gadgets inside Plasma as well.
[19:07] <apachelogger> In this talk I will show you how to write Plasmoids in JavaScript using 2 (well, technically 3) example Plasmoids.
[19:07] <apachelogger> and yes!!!! we will be able to pull this off in the limited time that we got.
[19:07] <apachelogger> We just need to believe in it :-D
[19:07] <apachelogger> [endofboringbits]
[19:07] <apachelogger> Time to move on to the interesting parts ...
[19:08] <apachelogger> let me show you just how difficult it is to write a plasmoid.
[19:08] <apachelogger> as with every programming introduction I will start with a "Hello" example.
[19:08] <apachelogger> if you do not want to write the stuff yourself, you can find a finsihed example at http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor/
[19:08] <apachelogger> as one might judge from the name this hello plasmoid is apachelogger branded and featuring doctor who awesomeness ;)
[19:09] <apachelogger> first we need to get the structure sorted out a bit - no fun without the politics :/
[19:09] <apachelogger> I will however try to limit this to the bare minimum
[19:09] <apachelogger> so
[19:09] <apachelogger> Any plasmoid *should* at least contain two files.
[19:09] <apachelogger> One for the "politics" (giving the plasmoid a name and icon) and one for the actual code.
[19:10] <apachelogger> specficis are in detail explained in the KDE techbase
[19:10] <apachelogger> (if anyone really cares :P)
[19:10] <apachelogger> for now you can just trust me and execute the following in a directory of your choice
[19:10] <apachelogger> mkdir -p hello-doctor/contents/code/
[19:10] <apachelogger> touch hello-doctor/metadata.desktop
[19:10] <apachelogger> touch hello-doctor/contents/code/main.js
[19:10] <apachelogger> these 3 lines will create the most essential directories and the 2 files I was talking about
[19:11] <apachelogger> Now for the adding of content.
[19:11] <apachelogger> (please excuse if I am rushing this a bit, but it is rather boring ;))
[19:11] <apachelogger> open hello-doctor/metadata.desktop in an editor of your choice (be it vi or nano ;)) and add the information seen at http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor/metadata.desktop
[19:12] <apachelogger> most of those files should be pretty self-explaining and are documented in the techbase
[19:12] <apachelogger> should you have a question about one of those - please ask
[19:12] <apachelogger> the only thin worth mentioning is that the field X-KDE-PluginInfo-Name *must* be rather unique
[19:13] <apachelogger> QUESTION: What does X-KDE-PluginInfo-EnabledByDefault=true do?
[19:13] <apachelogger> no one knows that ;)
[19:13] <apachelogger> all the information about that field is that you do not need to change it
[19:13]  * apachelogger also did not bother to look its function up in the source code....
[19:14] <apachelogger> once you have made the metadata.desktop suite your needs, save it and let us move on to ... the code :D
[19:14] <apachelogger> the code goes to hello-doctor/contents/code/main.js (that is actually changable via the desktop file in case you haven't noticed)
[19:14] <apachelogger> now behold!
[19:14] <apachelogger> layout = new LinearLayout(plasmoid);
[19:14] <apachelogger> label = new Label(plasmoid);
[19:14] <apachelogger> layout.addItem(label);
[19:14] <apachelogger> label.text = 'Hello Doctor!';
[19:15] <apachelogger> Yes, four lines of code :P
[19:15] <apachelogger> I am not kidding you :P
[19:15] <apachelogger> first we create a layout that belongs to your plasmoid and call it "layout", then we create a label that also belongs to our plasmoid and call it "label".
[19:16] <apachelogger> we add the label and to our layout and give it a text
[19:16] <apachelogger> and, well, that is it
[19:16] <apachelogger> and since it just got mentioned that this is much easier than C++
[19:16] <apachelogger> indeed it is
[19:17] <apachelogger> also it is available by default in plasma, so it is as protable as C++
[19:17] <apachelogger> in the end you should choose a javascript code over C++ for various reasons, if you do not need any of the C++ advantages :)
[19:17] <apachelogger> thereofre I am also talking about javascript :)
[19:17] <apachelogger> anyhow
[19:17] <apachelogger> lets view the plasmoid
[19:17] <apachelogger> plasmoidviewer ./hello-doctor
[19:18] <apachelogger> usually this should give you our new plasmoid, if it does not  -> http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor.png
[19:18] <apachelogger> Congratulations, you just have made your first Plasmoid!
[19:18] <apachelogger> plasmoidviewer is a very useful tool for in-development debugging
[19:19] <apachelogger> now that we have a plasmoid, it would be very nice to have it packaged, so we can install it in plasma and share it with others
[19:19] <apachelogger> for general purpose widget management plasma comes with a tool called plasmapkg
[19:20] <apachelogger> using plasmapkg -i you can install plasmoids to use them in plasma
[19:20] <apachelogger> packaging them is no magic either
[19:20] <apachelogger> just create a zip ;)
[19:20] <apachelogger> cd hello-doctor
[19:20] <apachelogger> zip -r ../hello-doctor.zip .
[19:20] <apachelogger> mv ../hello-doctor.zip ../hello-doctor.plasmoid
[19:21] <apachelogger> that will give you a nice plasmoid package to use with plasmapkg
[19:21] <apachelogger> and share with your friends
[19:21] <apachelogger> shadeslayer: mind the period in ./hello-doctor/
[19:22] <apachelogger> believe it or not, you now know almost everything
[19:22] <apachelogger> well, the important stuff anyway, lets digg a bit into development
[19:22] <apachelogger> that we will do with my incredibly awesome superior sweet and unicorny "trollface" plasmoid
[19:23] <apachelogger> you can either create the basic infrastructure using the commands I gave you for hello-doctor, or just recycle my template http://people.ubuntu.com/~apachelogger/udw/10.07/trollface-template/
[19:23] <apachelogger> remember to make metadata.desktop suite your needs, if you want
[19:23] <apachelogger> otherwise lets dive right into trollface/contents/code/main.js
[19:24] <apachelogger> the template I have provides no more than the code we used for hello-doctor
[19:24] <apachelogger> building up on that we will make superior awesomeness now
[19:24] <apachelogger> let me think
[19:24] <apachelogger> hm
[19:24] <apachelogger> how about we add a button to that ;)
[19:24] <apachelogger> one to push ;)
[19:25] <apachelogger> terribly difficult cod eagain...
[19:25] <apachelogger> button = new PushButton(plasmoid);
[19:25] <apachelogger> layout.addItem(button);
[19:25] <apachelogger> button.text = 'Push me!!!';
[19:25] <apachelogger> very similar to the label code but with a pushbuton now... just add that at the bottom of your main.js and you should get a button now
[19:25] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor-1.png
[19:25] <apachelogger> looks fancy, eh? ;)
[19:26] <apachelogger> yeah, I know, not really, but we will get there
[19:26] <apachelogger> oh hold on!
[19:26] <apachelogger> oh dear, oh dear! That does not look right at all :/
[19:26] <apachelogger> I do not know about you, but I really wanted the button under the label
[19:26] <apachelogger> not next to it
[19:26] <apachelogger> well, this gives me reason to talk a bit about layouting
[19:26] <apachelogger> ^ see what I did there
[19:27] <apachelogger> evil as I am I made myself a topic to talk about :D
[19:27] <apachelogger> so, our layout is obviously there to help with placement of our items
[19:27] <apachelogger> for that different layouts can use different rules
[19:27] <apachelogger> our simple linearlayout supports to ways to layout items
[19:27] <apachelogger> by vertical or horizontal orientation
[19:28] <apachelogger> suffice to say, the default is horizontal, hence our button is right of the label
[19:28] <apachelogger> to change that we add
[19:28] <apachelogger> layout.orientation = QtVertical;
[19:28] <apachelogger> now everything should be as intent by the author
[19:28] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor-2.png
[19:29] <apachelogger> be careful though!
[19:29] <apachelogger> when just adding items ot a layout (i.e. using the addItem() function) they will be listed in order of adding!
[19:29] <apachelogger> one should keep that in mind for later ;)
[19:29] <apachelogger> currently our button does not do much though :(
[19:29] <apachelogger> a bit sad.
[19:30] <apachelogger> let's add some super feature.
[19:30] <apachelogger> for this we will introduce a new javascript function. this is done using the function keyword. like this:
[19:30] <apachelogger> function showTroll()
[19:30] <apachelogger> {
[19:30] <apachelogger>     label.visible = false;
[19:30] <apachelogger> }
[19:30] <apachelogger> QUESTION: Can we resize that button?
[19:30] <apachelogger> yes, but a bit later
[19:30] <apachelogger> QUESTION: im getting http://imagebin.ca/view/RuCn71.html , what have i done wrong?
[19:31] <apachelogger> broken plasma most likely, what you are seeing here is that for some reason the plasma theme is not rendering properly, which is mostly an indication for running usntable pre-release software :P
[19:31] <apachelogger> so essenntially the items are there, they are just not drawn properly, goes a bit out of the scope of widgetcraft though :)
[19:32] <apachelogger> back to my new function showTroll
[19:32] <apachelogger> it does not do much
[19:32] <apachelogger> but what it does, man that is epic
[19:32] <apachelogger> it makes the label invisible
[19:32] <apachelogger> how scary is that!!!
[19:33] <apachelogger> now if you add showTroll(); to the bottom of your script the label will never be visible, not a lot of sense ... I just mention that to make you understand what a function is ;)
[19:33] <apachelogger> what would make a lot more sens is if we could hook up our button with that function
[19:33] <apachelogger> well *surprise* we can ;)
[19:34] <apachelogger> Qt has a system called signal and slots, it basically allows us to connect certain events of objects (signals) to functions that will carry out to an effect (slot).
[19:34] <apachelogger> Suppose my home is a plasmoid.
[19:34] <apachelogger> Now someone rings the bell, this will trigger that I go to the door and open it.
[19:35] <apachelogger> In Qt terms this means: someone emits the singal bellRung, this triggers my slot openDoor, and that slot will have as resulting situation that I am standing at my open door
[19:35] <apachelogger> I hope this clears things up that are going to happen next ... if not, poke devildante he knows all about signals and slots  ;)
[19:35] <apachelogger> so
[19:35] <apachelogger> like my home has a bell that can be rung, our plasmoid has a button...
[19:36] <apachelogger> and well, buttons can be clicked... ;)
[19:36] <apachelogger> nw we just connect that clicking to the function
[19:36] <apachelogger> button.clicked.connect(showTroll);
[19:36] <apachelogger> you can add this anywhere below the creation of the butotn
[19:36] <apachelogger> if you run the code now and click the button it will hide the label!
[19:36] <apachelogger> so magic :)
[19:37] <apachelogger> any questions thus far?
[19:37] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor-2-2.png
[19:37] <apachelogger> the careful observer will notice that there is still space occupied by our label
[19:38] <apachelogger> this is because we have just made it invisible
[19:38] <apachelogger> it is still there
[19:39] <apachelogger> in order to reuse the space we just remove it from the layout
[19:39] <apachelogger> function showTroll()
[19:39] <apachelogger> {
[19:39] <apachelogger>     label.visible = false;
[19:39] <apachelogger>     layout.removeItem(label);
[19:39] <apachelogger> }
[19:39] <apachelogger> using this improved showTroll fucntion the button sould now not only hide the label but also reuse its space
[19:39] <apachelogger> now
[19:40] <apachelogger> while we are at it, let us also invert the logic
[19:40] <apachelogger> we probably want our label back at some point
[19:40] <apachelogger> function hideTroll()
[19:40] <apachelogger> {
[19:40] <apachelogger>     layout.insertItem(0, label);
[19:40] <apachelogger>     label.visible = true;
[19:40] <apachelogger> }
[19:40] <apachelogger> so now we have showTroll and hideTroll
[19:40] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor-3.png
[19:41] <apachelogger> what we can do now, is hooking up our button with the hideTroll too
[19:41] <apachelogger> so for that we need to think a bit
[19:41] <apachelogger> first we connect to showTroll
[19:41] <apachelogger> in showTroll we hence need to disconnect that again and connect to hideTroll
[19:42] <apachelogger> vice versa in hideTroll
[19:42] <apachelogger> button.clicked.disconnect(showTroll);
[19:42] <apachelogger> button.clicked.connect(hideTroll);
[19:42] <apachelogger> for showTroll
[19:42] <apachelogger> and
[19:42] <apachelogger> button.clicked.disconnect(hideTroll);
[19:42] <apachelogger> button.clicked.connect(showTroll);
[19:42] <apachelogger> for hideTroll
[19:42] <apachelogger> Brilliant!
[19:42] <apachelogger> QUESTION: Why is the label a troll? :-)
[19:42] <apachelogger> the troll is not yet there, we will get there soon enough
[19:43] <apachelogger> in fact
[19:43] <apachelogger> lets do it now ;)
[19:43] <apachelogger> let me shed some light on why this is called trollface...
[19:43] <apachelogger> just showing and hidign a text label is a bit boring, and way too ungraphical tool!
[19:43] <apachelogger> so let us add a picture into the mix
[19:43] <apachelogger> oh I don't know, maybe http://people.ubuntu.com/~apachelogger/udw/10.07/trollface/contents/images/troll.png
[19:43] <apachelogger> ;)
[19:43] <apachelogger> Oh why, lets call it "troll", shall we? (you see where I am getting at here ;)). The code should be pretty clear:
[19:44] <apachelogger> troll = new Label(plasmoid);
[19:44] <apachelogger> troll.image = plasmoid.file("images", "troll.png");
[19:44] <apachelogger> layout.addItem(troll);
[19:44] <apachelogger> Now please run your plasmoid and see what uglyness we have produced....
[19:44] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor-4.png
[19:44] <apachelogger> ewwww!!!!
[19:44] <apachelogger> The Label is too big, the button is too big and the image is too small! Great job apachelogger!
[19:44] <apachelogger> Of course this was intentionally so I can tell you about the beauty of QSizePolicies ;)
[19:45] <apachelogger> By default a layout will try to use as much space as is possible and divert this space equally between its items. So while label and button are too small, they are indeed the same size as the image and vice versa.
[19:45] <apachelogger> This is however not desired in our situation, so we tell the button and image to follow a different policy than "use whatever you get from the layout".
[19:45] <apachelogger> For that we will use special leet magic called QSizePolicy. For specifics please take a look at the Qt documentation. In our example we will only need 2 policies:
[19:45] <apachelogger> * maximum - try to occupy as much space as possible
[19:45] <apachelogger> * fixed - magically lock to appropriate default value
[19:45] <apachelogger> We can apply those to our button...
[19:46] <apachelogger> button.sizePolicy = QSizePolicy(QSizePolicyMaximum, QSizePolicyFixed);
[19:46] <apachelogger> What we are telling the button is that it shall use as much horizontal space as possible but use a decent unchangable default value for its vertical size.
[19:46] <apachelogger> For our troll we will use max:max because we want the whole image shown. Using max:max the troll will try to use as much horizontal and as much vertical space as it can get.
[19:46] <apachelogger> troll.sizePolicy = QSizePolicy(QSizePolicyMaximum, QSizePolicyMaximum);
[19:47] <apachelogger> (In consequence the label will have to live on left overs, which is just fine for this example)
[19:47] <apachelogger> Trying this you should get a decent picture now!
[19:47] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/hello-doctor-4-1.png
[19:47] <apachelogger> Good news everyone!
[19:47] <apachelogger> We have all the basic components in place and can stick them together to get some more usefulness out of it ;-)
[19:48] <apachelogger> How about we do not show the troll by default, but only if the user presses the button?
[19:48] <apachelogger> How about we do show the label only if the troll is not shown?
[19:48] <apachelogger> Sounds like a plan, a plan that will require 4 lines of code (somehow with me a lot of things only require 4 lines of code, in case you noticed ;-)).
[19:48] <apachelogger> shadeslayer: you are missing the initial connection
[19:48] <apachelogger> ....So, to showTroll we add:
[19:48] <apachelogger> layout.insertItem(0, troll);
[19:48] <apachelogger> troll.visible = true;
[19:49] <apachelogger> and to hideTroll:
[19:49] <apachelogger> troll.visible = false;
[19:49] <apachelogger> layout.removeItem(troll);
[19:49] <apachelogger> They should look familiar to you by now and again are just inverted.
[19:49] <apachelogger> If you try this now, then you will notice that I was not completely, honest, 4 lines of code do not quite cut it.
[19:49] <apachelogger> We still need to remove one and add one (so in the end we are at +5 -1 = 4 :-P).
[19:49] <apachelogger> As we do not want the troll shown when the label is shown, we must change the initial state of our troll.
[19:50] <apachelogger> Instead of adding it to the layout (which is now handled by showTroll) we will set its initial visiblity to false (which also gets changed in showTroll).
[19:50] <apachelogger> layout.addItem(troll);
[19:50] <apachelogger> becomes
[19:50] <apachelogger> troll.visible = false;
[19:50] <apachelogger> And from this point on we have a proper Trollface!
[19:50] <apachelogger> Hooray \o/
[19:50] <apachelogger> That leaves us with 10 minutes for fun stuff ^^
[19:50] <ClassBot> There are are 10 minutes remaining in the current session.
[19:50] <apachelogger> see ;)
[19:51] <apachelogger> Well, this was all very nice, but really, still a bit boring.
[19:51] <apachelogger> Plasma can do so much more.  In fact so much that I do not have time to properly show you :(
[19:51] <apachelogger> But let us take animations for example ;)
[19:51] <apachelogger> How about making our troll rotate. Good idea, isn't it? :D
[19:51] <apachelogger> First lets get a rotate object we can work with:
[19:51] <apachelogger> rotate = animation("Rotate");
[19:52] <apachelogger> outside a function please!
[19:52] <apachelogger> I recommend adding this towards the end of your code.
[19:52] <apachelogger> Now we have a rotate animation. But we still need to tweak it a bit to our needs.
[19:52] <apachelogger> rotate.targetWidget = troll;
[19:52] <apachelogger> Now just add the following somewhere in your showTroll function:
[19:52] <apachelogger> rotate.start();
[19:52] <apachelogger> This will start the animiation. And that is all we need to do for starters. If you try your code you should get a neat rotating head upon click.
[19:53] <apachelogger> It will however only rotate 180 degrees, not terribly awesome. Lets tweak this a bit.
[19:53] <apachelogger> Lets set the rotation to 360 degrees:
[19:53] <apachelogger> rotate.angle = 360;
[19:53] <apachelogger> and maybe make it a bit slower, say 5000 ms:
[19:53] <apachelogger> rotate.duration = 5000;
[19:53] <apachelogger> You might also have noticed that it will only rotate once, let us make this endless:
[19:53] <apachelogger> rotate.loopCount = -1;
[19:53] <apachelogger> Voila! A spinning head :D
[19:54] <apachelogger> Now since I am a bit short on time, let me wrap this up, sorry for rushing a bit towards the end :)
[19:54] <apachelogger> Another cool widget I created yesterday is a Player Control Widget - Playdget. You can find it at
[19:54] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/playdget/
[19:55] <apachelogger> if your trollface is not working properly you can also take a look at my implementation:
[19:55] <apachelogger> http://people.ubuntu.com/~apachelogger/udw/10.07/trollface/
[19:55] <ClassBot> There are are 5 minutes remaining in the current session.
[19:55] <apachelogger> in general you will find snapshots of the various trollface steps in http://people.ubuntu.com/~apachelogger/udw/10.07/
[19:55] <apachelogger> QUESTION: Can you program KDE or pure Qt applications using JavaScript?
[19:56] <apachelogger> In Qt 4.7 there will be a new fraemwork called QtQuick which indeed allows you to create entire apps in JavaScript
[19:56] <apachelogger> in fact, as far as I know plasma-mobile uses this a lot
[19:56] <apachelogger> QUESTION: can you write DataEngines in JavaScript?
[19:57] <apachelogger> I am not entirely sure, in either case I am not sure you would want to to do this for performance reasons, might be worth asking in the plasma IRC channel :)
[19:57] <apachelogger> As I mentioned earlier on - Plasma is more of a platform than an actual application (in contrast to plasma-desktop and plasma-netbook). Plasma is also used in Amarok. And here is the shocking news...
[19:57] <apachelogger> You can run both trollface AND playdget inside Amarok. So with a bit of tweaking you can actually make your JavaScript Plasmoids useable inside Amarok and plasma-desktop and plasma-netbook and plasma-mobile. If that is not a reason to become Plasmoid developer, then I do not know what is :D
[19:58] <apachelogger> For videso on both plasmoids in action take a look at http://people.ubuntu.com/~apachelogger/udw/10.07/videos/
[19:58] <apachelogger> I totally can recommend those running in Amarok ;)
 Question: Can you do this on gmone if you have kdm installed, or you have to switch to kdm completely
[19:58] <apachelogger> this has nothing to do with KDM really
[19:58] <apachelogger> but if you mean KDE...
[19:59] <apachelogger> generally you should be able to run plasma-desktop in a GNOME session and replace the GNOME desktop+panel
[19:59] <apachelogger> also, for development you do not need to run plasma-desktop
[20:00] <apachelogger> well, time is up
[20:00] <apachelogger> if you care to talk a bit more join us in #kde-devel or #kubuntu-devel :)
[20:00] <apachelogger> Thank you everyone! You have been brilliant!
[20:01] <seb128> hey everybody
[20:01] <akgraner> Thank you apachelogger  - and welcom seb128
[20:01] <akgraner> seb128, if you are ready take it away!
[20:01] <seb128> hey akgraner ;-)
[20:01] <seb128> hey everybody else
[20:01] <seb128> so that session is the "Desktop Team overview" one
[20:01] <seb128> I'm Sebastien Bacher and I'm working on the Ubuntu desktop for 6 years now. I'm going to talk to you about the Ubuntu Desktop Team today
[20:01] <seb128> .
[20:01] <seb128> I'm not sure how technical the audience is today
[20:02] <seb128> I will start with an overview of the team
[20:02] <seb128> then speak about some of the work we do
[20:02] <seb128> then we can do questions and answers
[20:02] <seb128> .
[20:02] <seb128> So first who we are and we are doing?
[20:02] <seb128> So first who we are and we are doing, the Ubuntu Desktop Team is the team working on the desktop interfaces of the Ubuntu Desktop and the UNE edition
[20:02] <seb128> We basically:
[20:03] <seb128> - package the best softwares available and try to keep those uptodate
[20:03] <seb128> - triage desktop bugs reports
[20:03] <seb128> - try to fix as many issues as we can
[20:03] <seb128> - take decisions about what softwares are shipped by default
[20:04] <seb128> - try to improve the desktop experience as we can
[20:04] <seb128> .
[20:04] <seb128> Where to find the desktop team:
[20:04] <seb128> - #ubuntu-desktop on this IRC server
[20:04] <seb128> - ubuntu-desktop@lists.ubuntu.com, https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop/
[20:04] <seb128> - launchpad (desktop-bugs and ubuntu-desktop teams)
[20:04] <seb128>  
[20:05] <seb128> So let's speak first about the packages we work on and how we update those
[20:05] <seb128> you can get a rough idea of the default set of things we work on there
[20:05] <seb128> - http://people.canonical.com/~seb128/versions.html
[20:06] <seb128> it basically lists packages the team is interested in with the current upstream and ubuntu versions
[20:06] <seb128> as you can set there are different set of color there
[20:06] <seb128> green is what is uptodate
[20:06] <seb128> everything is outdated either compared to debian or to upstream
[20:07] <seb128> ups
[20:07] <seb128> "everythin else"
[20:07] <seb128> so let's speak a bit about how we update those
[20:07] <seb128> the work is usually discussed on #ubuntu-desktop
[20:08] <seb128> but if you want to claim you are working on a desktop update you can also use the "Open Bug" column on http://people.canonical.com/~seb128/versions.html
[20:08] <seb128> our packages are usually stored in bzr
[20:09] <seb128> we do store only the debian directory so far because having the source there is usually quite slower and we didn't find real benefit since with the current technologies we still have to maintain patches in the debian dir
[20:09] <seb128> so the usual way to update those is to checkout the source
[20:09] <seb128> is lp:~ubuntu-desktop/gconf-editor/ubuntu
[20:09] <seb128> is -> ie
[20:10] <seb128> you get a debian directory while doing that
[20:10] <seb128> it's the base to do an update
[20:10] <seb128> so you can get it doing "bzr checkout lp:~ubuntu-desktop/gconf-editor/ubuntu"
[20:11] <seb128> then you can update the change to the current version doing "dch -v upstream_version-revision"
[20:12] <seb128> where "upstream_version" is the version from the upstream source and "revision" the ubuntu revision (typically -0ubuntu1 for an update)
[20:12] <seb128> the current version of gconf-editor is 2.30.0-2ubuntu1
[20:12] <seb128> so it means you would do "dch -v 2.30.1-0ubuntu1" for the next update
[20:13] <seb128> then run "bzr bd"
[20:13] <seb128> that will download the new tarball source for you and start a build
[20:14] <seb128> it's likely that some changes will not apply or that you will need to update build-depends
[20:14] <seb128> in which case you need to do the required changes in the debian directory
[20:14] <seb128> that should be enough to get you quickly started on trying to build something and updating versions
[20:15] <seb128> I don't want to start now on patch system and packaging details, you will have other sessions about that this week and there is wiki documentations
[20:15] <seb128> but let me know if you have extra questions later on
[20:15] <seb128> https://wiki.ubuntu.com/DesktopTeam/Bzr has details on the current team workflow
[20:15] <seb128>  
[20:15] <seb128> out of updates we do work on desktop bugs
[20:16] <seb128> https://bugs.edge.launchpad.net/~desktop-bugs/+packagebugs
[20:16] <seb128> this url has the lists of components the desktop-bugs is watching
[20:16] <seb128> as you can see it's quite a lot
[20:16] <seb128> if you want to help on some of those feel free to talk to us on #ubuntu-desktop or to ping pedro_ from the bugsquad
[20:17] <seb128> we welcome any help to triage those and especially to raise the issues that should be adressed in priority during the cycle
[20:17] <seb128> since the team working on solving those issues has limited manpower and can't work on everything it's important to prioritize issues
[20:17] <seb128>  
[20:17] <seb128> we also do take decisions about softwares selections
[20:18] <seb128> those discussions are usually made on our list, or IRC channel and decisions taken at UDS
[20:18] <seb128> the lists is https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop/
[20:18] <seb128> if you have any suggestions for the desktop or UNE feel free to come discuss with us
[20:19] <seb128> we do discuss other changes, design decisions, etc on those lists
[20:19] <seb128> so that was a sort of overview of what the team is doing right now
[20:20] <seb128> there is lot to cover in packaging and other areas but I don't think one hour writting there would be enough and would probably not be that useful
[20:20] <seb128> so let's do questions and answers now if something has any questions
[20:21] <seb128> I can continue describing some of the details of our work later one if we run out of questions
[20:21] <seb128> if you have questions use #ubuntu-classroom-chat
 QUESTION: with Gnome-shell, when should be expect a stable version, 10.10 ro 11.04
[20:21] <seb128> that's an excellent questions
[20:21] <seb128> so GNOME3 is quite exciting
[20:21] <seb128> but it's lot of work at the same time
[20:22] <seb128> they do plan to have GNOME3 ready around the same time we will roll 10.10
[20:22] <seb128> but it's adding lot of changes:
[20:22] <seb128> gsettings (dconf)
[20:22] <seb128> gtk3
[20:22] <seb128> gnome-shell
[20:22] <seb128> new gobject introspection
[20:23] <seb128> so lot of technologies changes, lots of softwares to update
[20:23] <seb128> we do believe their schedule is really challenging and while it's exciting we don't have the ressources to follow on everything this cycle
[20:24] <seb128> we do plan to work as well as we can but it's going to take 2 cycles
[20:24] <seb128> so we do plan to have the platform ready this cycle
[20:24] <seb128> ie gtk3 available for 10.10
[20:24] <seb128> the new introspection stack, dconf
[20:24] <seb128> but gtk3 will not be on the CD this cycle
[20:24] <seb128> it's going to be challenging to have 2 gtk stacks on the CD
[20:25] <seb128> gnome-shell will be in universe for 10.10
[20:25] <seb128> then next cycle we will try to move to GNOME3
[20:25] <seb128>  
 QUESTION: Will Unity replace the Gnome Shell vision?
[20:25] <seb128> no
[20:25] <seb128> unity has been made for small screens
[20:25] <seb128> where gnome-shell is for desktop environments
[20:25] <seb128> we do believe those have different needs
[20:26] <seb128> so unity is what UNE will be using
[20:26] <seb128> where the desktop will keep using GNOME
[20:26] <seb128>  
 QUESTION: Since Gnome-shell is being worked on to include Ubuntu's panel design, will we see Compiz support in gnome-shell at all? (I realize gnome-shell wont be default in 10.04)
[20:26] <seb128>  
[20:26] <seb128> right it won't since that version is out for a bit now ;-)
[20:27] <seb128> I doubt compiz will be used in gnome-shell though since they have mutter used as wm there
[20:27] <seb128> you should talk to the gnome-shell guys if you think they should support compiz though
[20:27] <seb128>  
 QUESTION: Is there an effort to ensure that VMs/machines without fast 3D cards will still get good support in the days of gnome-shell etc?
[20:27] <seb128> well
[20:28] <seb128> gnome-shell said from the start they would not impose limits for their softwares just to support "old configurations"
[20:28] <seb128> so gnome-shell will not support those no
[20:28] <seb128> the current desktop will still be around and we will keep a fallback solution available at runtime for those configurations
[20:29] <seb128> it will likely keep being similar to the current desktop
[20:29] <seb128> I doubt much work will go into that though
[20:29] <seb128>  
 QUESTION: Since alot of users enjoy Compiz to a certain extent, seeing it lifted from Ubuntu seems a bit drastic, if this happens do you think a new ubuntu distro will be made to include the older gnome?
[20:29] <seb128> who said it would be lifted?
[20:30] <seb128> it will still be available
[20:30] <seb128> not sure what you are concerned about but mutter do similar effects
[20:30] <seb128> so gnome-shell or unity will have nice effects as well
 Question: Will we see Compiz like compositing via mutter, at least some point in time?
[20:31] <seb128> similar question
[20:31] <seb128> not sure you will see as many effects or crazy things in those
[20:31] <seb128> but the default compiz configuration is quite limited in effects it uses
[20:31] <seb128> the new desktop will likely keep a limited "bling" as well
[20:32] <seb128> the desktop should be nice to use
[20:32] <seb128> not acting as a crazy demo box ;-)
[20:32] <seb128> but those who like compiz will still be able to install it
 seb128: so it'll be compatible with gnome-shell? I meant that if gnome-shell becomes default, instead of re-installing the older gnome to work with compiz, will there be a distro that maintains that gnome isntead of moving to gnome-shell.
[20:33] <seb128>  
[20:33] <seb128> not sure it will be a distro, but nothing stop you to install compiz and use it, it's on package to install
[20:33] <seb128> on -> one
[20:34] <seb128> doesn't seems to warrant doing another distribution
[20:34] <seb128> it will rather be an effect level in the appearance capplet
[20:34] <seb128>  
 QUESTION: Since unity uses mutter does that mean that unity and compiz won't work together either
[20:34] <seb128> righjt
[20:35] <seb128> you can use compiz and unity
[20:35] <seb128> some people have been doing it
[20:35] <seb128> but you will lack some of the effects and integration the unity team work on
[20:35] <seb128> you can still use the unity bar and launcher though
[20:35] <seb128> but if you prefer doing desktop manager yourself using compiz nothing stops you
[20:36] <seb128>  
[20:36] <seb128> other questions?
 QUESTION: ok, giving you a break from Compiz, what can you tell us about the windicators, and the new decoraters? Suggestion if I may, I love the new theme but if I could adjust the window border/header to fit a darker theme that would be awesome
[20:36] <seb128> thanks ;-)
[20:37] <seb128> we do plan to keep working on gtk changes for csd
[20:37] <seb128> client side decoration
[20:37] <seb128> it means it will gtk drawing its decorations directly
[20:37] <seb128> rather than compiz
[20:38] <seb128> but that's quite some work to do and we will need to think about non gtk softwares
[20:38] <seb128> so while this work continue it will not likely go in 10.10
[20:38] <seb128> the changes are often discussed on the ayatana list though
[20:38] <seb128> so feel free to join them to discuss it with them
[20:38] <seb128>  
 <question>how do you select different software to added to desktop?
[20:39] <seb128> we try to listen to our users requests
[20:39] <seb128> there were some requests for a video editor for a while so we got pitivi in lucid
[20:39] <seb128> we try to see what nice softwares are out there and what users like
[20:39] <seb128> if you have any suggestion feel free to come discuss those with us
[20:40] <seb128> chromium has lot of users so we consider it for UNE this cycle
[20:40] <seb128> it's also faster and might fit better on the devices UNE target
[20:40] <seb128> we are consider shotwell as well for photo management since it's a very nice software
[20:41] <seb128>  
 QUESTION: What happened to netbook-launcher-efl? Why isn't it used in UNE?
[20:41] <seb128> not sure if the question is "why is it not used by default in UNE"?
[20:42] <seb128> while it's nice efl is not a technologies used a lot in Ubuntu or maintained
[20:42] <seb128> it also has limitations
[20:42] <seb128> we do believe unity to be a better experience
[20:42] <seb128> it's based on quite some design work, modern technologies and actively being worked
[20:43] <seb128> users feedback has been welcoming it so far
[20:43] <seb128> so let's see how it goes
[20:43] <seb128>  
 QUESTION: as far as functionality Pitivi is alot premature in comparison with software such as OpenShot, was Openshot a consideration?
[20:44] <seb128> I've to admit I don't know openshot
[20:44] <seb128> nobody came with a suggestion to use it previous cycle but pitivi has quite some user tractions
[20:45] <seb128> if you think we should consider openshot feel free to email the mailing list
[20:45] <seb128> or come discuss on the IRC channel
[20:45] <seb128>  
 QUESTION: How will the rootless xserver mean for performance, standard and with GPU card, or is that a different deartment.
[20:45] <seb128> sorry but I don't know about performances impact
[20:45] <seb128> you are welcome to ask on #ubuntu-x though
[20:46] <seb128> I would assume it should not have one to be consider as a valid alternative to use
[20:46] <seb128>  
 QUESTION: Are there any plans to support HDMI Videos and Desktop screen splitters?
[20:46] <seb128> not that I know about but another question that would be rather for #ubuntu-x
[20:46] <seb128> the ubuntu xorg team has limited manpower though
[20:47] <seb128> so I don't think there is any effort coming from ubuntu itself on that topic
[20:47] <seb128>  
 QUESTION: What's the deal concerning BTRFS and possibly BURG?
[20:47] <seb128> I don't know about burg
[20:47] <seb128> but the foundation team is considering btfs for 10.10
[20:47] <seb128> btrfs
[20:47] <seb128> not really a desktop question though
[20:47] <seb128> there is a blueprint about it if you are interested
[20:48] <seb128>  
 QUESTION: What are the plans for the Menu Bar? This is – usability-wise – one of the most crucial parts of the desktop. Currently, it seems clunky and crowded.
[20:48] <seb128> inquata, hum,  what menu bar?
[20:48] <seb128> if you mean the application etc menus?
[20:48] <seb128> it's neither in gnome-shell or unity
[20:49] <seb128> they both have different way to interact with softwares
[20:49] <seb128> there is no effort to work on improving the menus that I know about though
[20:49] <seb128> unity has a "place" view to browse application
[20:50] <seb128> ie a grid with filters you can use
[20:50] <seb128>  
[20:50] <ClassBot> There are are 10 minutes remaining in the current session.
[20:50] <seb128> hum, ok ;-)
 seb128: Ok, who do I need to talk to if I’m interested in improving the Menu Bar for the standard desktop?
[20:51] <seb128> the ubuntu-desktop mailing list
[20:51] <seb128>  
 QUESTION: Why do minimize/maximize, screen size increase/dec, close button are changed for all the browser different normal window format? is that successful adoption?
[20:51] <seb128> I'm not sure to understand the question
[20:51] <seb128> you mean why the lucid theme changes the side and order of buttons?
[20:51] <seb128> design choice
[20:52] <seb128> users get used to it after some days it seems
[20:52] <seb128> it's sort of nice and allow extra changes that will come like windicators
[20:52] <seb128>  
 QUESTION: IMO one of the biggest papercuts the gnoem desktop in general has is that the clipboard doesnt function correctly with non gnome applications, if you install glipper you can fix this but atm it is broken by default. Will this problem ever be resolved?
[20:53] <seb128>  
[20:53] <seb128> excellent question
[20:53] <seb128> to be honest I don't know
[20:53] <seb128> that's not a topic we focussed on until now
[20:53] <seb128> I think there is a gsoc project about it
[20:53] <seb128> it = clipboard
[20:53] <seb128> but that's probably something we should try to fix
[20:54] <seb128> you should come with suggestions or requests for comments on the list
[20:54] <seb128> that would maybe motive some people to get that done
[20:54] <seb128>  
 QUESTION: I know the min/max/close is on the left for a reason now so I want be picky on that but I'm worried about future conflicts because when I change to another theme, they go back to the right.
[20:55] <seb128> let's see how it goes with those theme, they will maybe just not have windicators or improvements on
[20:55] <seb128> but there is no reason the side of theme should be an issue
[20:55] <seb128> it's a gconf key, you can change it for any theme
[20:55] <ClassBot> There are are 5 minutes remaining in the current session.
[20:55] <seb128> so we could force it for other themes as well
[20:55] <seb128>  
 seb128: My suggestion would be for zeitgeist to index your clipboard histroy and for gnome to use that, and allow you to choose what is currently in your clipboard using an indicator
[20:56] <seb128> nice suggestion, somebody should raise it on the ayatana list for comments
[20:56] <seb128>  
 <question>so are the windicators a theme specific feature or generic ubuntu desktop feature
[20:56] <seb128> they will not be theme specific no
[20:56] <seb128>  
[20:57] <seb128> ok, we have a few minutes for remaining questions
 QUESTION:ANy possiblities of adapting APPLE themes?
[20:57] <seb128> dunno about that one
[20:57] <seb128> there is no reason you could make themes similar to the apple ones
[20:58] <seb128>  
[20:58] <seb128> ok, no other question?
[20:58] <seb128> thanks everybody then!
[20:58] <seb128> hum
 Question: We can turn off internet to any given app with the on/offline windicator now right?
[20:59] <seb128> there is no windicator right now
[20:59] <seb128> but seems something they could be doing
[20:59] <seb128> ok
[20:59] <seb128> that's it
[20:59] <seb128> thanks everybody
[20:59] <seb128> it's time for the next session
[20:59] <akgraner> Thanks seb128! Great Session!
[21:00] <slangasek> hey folks
[21:01] <akgraner> hey Steve if you are ready the floor is yours!
[21:02] <slangasek> in this session, I'd like to cover the basics of writing upstart jobs, cover a few examples, look at a few special cases of interest, and then open the floor to questions
[21:03] <slangasek> if you have questions as we go, please ask (the usual method on #ubuntu-classroom-chat)
[21:04] <slangasek> so as written at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions, it is strongly recommended that you read over the init(5) manpage first, to get an understanding of what the various commands are that you can use in an upstart job
[21:05] <slangasek> so I won't repeat here the contents of that manpage; that's a bit too much to cover in detail in a 1h session
[21:05] <slangasek> but if you haven't read it yet, you may still learn something of interest here and can always go read the full details later!
[21:06] <slangasek> but first, a rhetorical question: why would you want to write an upstart job?
[21:06] <slangasek> Ubuntu uses upstart as its init daemon
[21:07] <slangasek> if you want to create a new service on Ubuntu - like a mail daemon, web server, or system audio daemon, for example - the recommended way to do this is by writing an upstart job
[21:07] <slangasek> even running arbitrary commands at startup or shutdown, that have nothing to do with a service, can be implemented as upstart jobs
[21:07] <slangasek> upstart jobs supersede the traditional sysvinit rc system of starting and stopping jobs (those files under /etc/init.d/)
[21:08] <slangasek> both are still supported - as explained at https://help.ubuntu.com/community/UpstartHowto - but for new services, it's definitely recommended to use native upstart jobs for several reasons
[21:09] <slangasek> - upstart is a process supervisor in addition to being an init daemon, so it always knows the state of the job and can handle start/stop directly and respawn services when they die
[21:09] <slangasek> (so no messy bolted-on pid file handling!)
[21:10] <slangasek> - upstart jobs can be declared to start and stop on a number of different conditions, not just on runlevel changes
[21:10] <slangasek> - upstart job syntax is much simpler than sysv init scripts - you *can* write complicated scripts inside of an upstart job, but for the common case, there's much less scripting involved!
[21:12] <slangasek> now let's start with a simple example of an upstart job.  Since you might not have all of these packages installed on your system, I've copied them to the web for convenience: http://people.canonical.com/~vorlon/upstart/
[21:12] <slangasek> the first once we'll look at is http://people.canonical.com/~vorlon/upstart/acpid.conf
[21:12] <slangasek> this is a bog-standard upstart job, nothing too complicated at all
[21:13] <slangasek> it has a description, which is optional but used by upstart in some informational messages
[21:13] <slangasek> two lines tell us when to start and when to stop the service
[21:14] <slangasek> here, the start and stop conditions relate in a pretty straightforward manner to the sysvinit runlevels - start the service on any of runlevels 2, 3, 4, or 5; and stop it on any runlevel *not* in that list
[21:15] <slangasek> (which, if you know your runlevels, means to stop it on runlevels S, 0, 1, or 6: i.e., on shutdown, reboot, single user mode, and runlevel 1 which is a sort of "faux single user mode"
[21:15] <slangasek> )
[21:16] <slangasek> after that we have the line 'expect fork', which tells us how the service starts up in order for upstart to be able to supervise the process correctly, know which process is the master process and when it's done starting up so it can trigger other jobs that depend on it, etc
[21:17] <slangasek> this line is *very important* to get right
[21:17] <slangasek> if you get it wrong, you may not be able to fix it without rebooting your computer!
[21:17] <slangasek> more on that later :)
[21:17] <slangasek> the next line is 'respawn', which tells upstart that if the job stops, it should be restarted
[21:18] <slangasek> there are a number of different options you can use to configure how often upstart will respawn the service
[21:18] <slangasek> all documented in the glorious manpage
[21:18] <slangasek> finally, we have a single line describing what the job itself *does*
[21:18] <slangasek> exec acpid -c /etc/acpi/events -s /var/run/acpid.socket
[21:19] <slangasek> the 'exec' tells upstart to run the following command directly
[21:19] <slangasek> you could also write this as:
[21:19] <slangasek> script
[21:19] <slangasek>    exec acpid -c /etc/acpi/events -s /var/run/acpid.socket
[21:19] <slangasek> end script
[21:19] <slangasek> ... but there's not much point to doing that, the 'script' and 'end script' lines are redundant
[21:20] <slangasek> also, note that this is *not* the same:
[21:20] <slangasek> script
[21:20] <slangasek>    acpid -c /etc/acpi/events -s /var/run/acpid.socket
[21:20] <slangasek> end script
[21:21] <slangasek> it's not the same because when you close the job in 'script', upstart spawns a shell; the shell is a process, which spawns a subprocess when you call acpid by itself, and that confuses upstart because we told it that the process is done starting up as soon as there's a subprocess (expect fork)!
[21:22] <slangasek> looks like there are a couple of good questions queued up, let's get to those before we go on
[21:23] <slangasek> please remember to type 'QUESTION: ' in front of your question, not just 'QUESTION' so the bot can parse it - that'll help us go quicker :)
[21:23] <ClassBot> Omahn18 asked: Does upstart have a toggle switch that can be enabled to log all service transistions to /var/log/daemon or equivalent for debugging purposes?
[21:24] <slangasek> good question - yes, you can make upstart more verbose by running 'sudo initctl log-priority info' or 'sudo initctl log-priority debug'
[21:24] <slangasek> 'info' is normally enough for debugging any problems you might have with new jobs you've written - 'debug' is usually way too verbose for anything other than debugging upstart itself :)
[21:25] <slangasek> and if you need to debug upstart jobs that happen too early in the boot sequence before you're able to *type* 'sudo initctl [...]', you can actually just type '--verbose' or '--debug' on the kernel commandline - upstart will parse that and go into that mode on startup :)
[21:26] <ClassBot> Ram_Yash asked: Whenever I upstart the music player it disappers first time without any processor . Is this is a bug or Am I missing something?
[21:27] <slangasek> Ram_Yash: have you written an upstart job for this?  If so, please post it somewhere that we can look at it (e.g., pastebin.ubuntu.com) and we'll discuss it a little later
[21:27] <slangasek> if you mean "when you start up the music player", then that doesn't have anything to do with upstart jobs...
[21:27] <ClassBot> simar_mohaar asked: Where to place these scripts so that they run automatically ...
[21:27] <slangasek> upstart finds its jobs in /etc/init
[21:28] <slangasek> adding a job file there with a name ending in .conf is enough to get upstart to see it and act on it
[21:28] <slangasek> (but it won't automatically start it for you, because start conditions are defined by events and upstart won't automatically rerun the events for you - so you would need to run 'sudo service $job start' to start it)
[21:30] <slangasek> some more good questions coming in about upstart job authoring - let's go to a couple more examples and see if we can't answer those questions along the way
[21:30] <slangasek> http://people.canonical.com/~vorlon/upstart/upstart-udev-bridge.conf
[21:30] <slangasek> just a couple of interesting differences here from the acpid job
[21:31] <slangasek> instead of 'start on runlevel [...]', it's 'start on starting udev' and 'stop on stopped udev'
[21:31] <slangasek> these events are internal events, documented in the init(5) manpage: whenever an upstart job starts or stops, events are sent that other jobs can trigger on
[21:31] <slangasek> so this way, we can say "upstart-udev-bridge should only run when udev is running"
[21:32] <slangasek> now, 'runlevel' is also an event, but it's not documented in the manpage because it's not an event that's internal to upstart
[21:32] <slangasek> er
[21:32] <slangasek> sorry, that's incorrect - that event *is* internal to upstart, it's emitted whenever you change runlevels :)
[21:33] <slangasek> the other thing that's different here is 'expect daemon' instead of 'expect fork'
[21:33] <slangasek> 'expect daemon' means we expect the service to daemonize (in a nutshell: to fork twice) to let us know that it's ready to go
[21:33] <slangasek> if you *can* use 'expect daemon', that's generally recommended for upstart jobs related to services
[21:34] <slangasek> but sometimes it's not possible because the behavior of the daemon when daemonizing isn't what upstart expects
[21:34] <slangasek> e.g., http://people.canonical.com/~vorlon/upstart/smbd.conf
[21:35] <slangasek> smbd, from the samba package, daemonizes by default... but we have to tell it to run in the foreground here (exec smbd -F) and *not* use an 'expect fork' or 'expect daemon' line, because smbd manages to confuse upstart badly enough that it hangs the job and you have to restart to continue debugging ;0
[21:35] <slangasek> so watch out for that :)
[21:35] <slangasek> another new thing in here is a pre-start script
[21:35] <slangasek> upstart jobs can be told to run commands, or entire scripts, before and after starting, and before and after *stopping*, the main process
[21:36] <slangasek> you can use any combination of these that you need to
[21:36] <slangasek> and should leave out the ones that you don't. :)
[21:36] <slangasek> that brings us to another question....
[21:36] <ClassBot> Omahn18 asked: I've written an upstart job for NIS (bug 569757) and ideally it should trigger a restart of autofs (if installed) to pull down the NIS automount maps. Does upstart have any specific functionality to do this or should it just be included in the script section?
[21:37] <slangasek> yep - just put a command in your post-start script to trigger the reload
[21:37] <slangasek> if autofs is an upstart job itself, you can just run 'restart autofs'
[21:37] <slangasek> but I would recommend thinking carefully about whether this is the right thing to do... should autofs be restarted, or just sent a signal to get it to reload its configuration?
[21:38] <slangasek> if the latter, you can get the pid of the job you want to restart by running 'status autofs'
[21:39] <slangasek> well, actually... as long as the service responds to SIGHUP, you can run 'reload autofs'
[21:40] <ClassBot> tech2077 asked: QUESTION: while looking at the files in /etc/init.d/, they are all system v init daemons, not upstart daemons, are there any ones in teh folder by standard install that are
[21:40] <slangasek> upstart jobs are all in /etc/init, not /etc/init.d.  We will probably eventually get rid of /etc/init.d on a default system, but we're still transitioning...
[21:40] <ClassBot> simar_mohaar asked: Can i see which all upstart jobs are currently running ?
[21:41] <slangasek> great question!  yes, you can run 'sudo initctl list'
[21:41] <slangasek> (if you're not root, you can't see the list - you can only check the status of individual jobs with 'status')
[21:41] <ClassBot> simar_mohaar asked: 'sudo service $job start' to start it  do i need to do it once or every time i start computer ??
[21:42] <slangasek> so earlier I mentioned that upstart won't automatically start a job for you when you create it
[21:42] <slangasek> but, if *after* creating it, the start condition is met, yes - it will be started for you
[21:42] <slangasek> so as long as you set the start condition to something that happens on startup, you don't need to run 'sudo service $job start' again after reboot
[21:43] <slangasek> here's an example of a start condition you can use on startup: http://people.canonical.com/~vorlon/upstart/rsyslog.conf
[21:43] <slangasek> 'start on filesystem'
[21:43] <slangasek> now this one is *not* an upstart built-in event
[21:43] <slangasek> (I'm sure this time :)
[21:43] <slangasek> it's an event that comes from mountall
[21:43] <slangasek> mountall gives us several events letting us know when the filesystem is mounted
[21:44] <slangasek> 'local-filesystems', 'filesystem', 'virtual-filesystems', 'remote-filesystems'... separate events for each separate filesystem that gets mounted
[21:44] <slangasek> now, generally the only one you want to use is 'filesystem'
[21:45] <slangasek> for most jobs, you want to wait for *all* the filesystems in /etc/fstab to be mounted before you start your job
[21:45] <slangasek> starting it any earlier is probably just going to cause contention and slow the system down
[21:45] <slangasek> note that 'start on filesystem' means that your job will start *regardless* of what runlevel you're booting into
[21:45] <slangasek> so even in single user mode, rsyslog is still started
[21:45] <slangasek> and it only stops on shutdown or reboot
[21:46] <slangasek> so if your service doesn't really belong in single user mode, you should use 'start on runlevel [2345]' instead
[21:46] <slangasek> the other mountall signal that's worth mentioning, that you may see in a lot of other jobs, is 'local-filesystems'
[21:46] <slangasek> in fact, we already saw one of these: smbd uses it
[21:47] <slangasek> 'local-filesystems' is different from 'filesystem' in that it's emitted before your remote filesystems are up
[21:47] <slangasek> so you would use 'start on local-filesystems' for *only* those jobs that may be needed in order to get your remote filesystems mounted: networking, filesystem daemons, etc
[21:48] <slangasek> otherwise, the files your job needs to run may be *on* a remote filesystem, and it'll try to start it too early and fail!
[21:48] <slangasek> Moomoc asked: 'Is it possible to use start on file-system [23] e.g.?'
[21:48] <slangasek> well, there's no event named 'file-system 2'
[21:49] <slangasek> there is a 'mounted' and a 'mounting' event emitted for each mount point, when it's mounted
[21:49] <slangasek> *but*, that means the start condition depends on the partition layout of the system!
[21:49] <slangasek> so you don't want to do that for any jobs that go into Ubuntu itself
[21:49] <ClassBot> simar_mohaar asked: What are upstart jobs commonly used for??
[21:50] <slangasek> upstart jobs are used for *everything* to do with starting up your system or shutting it down
[21:50] <slangasek> (with a few exceptions that haven't transitioned yet)
[21:50] <ClassBot> There are are 10 minutes remaining in the current session.
[21:50] <slangasek> mounting filesystems is done by an upstart job
[21:50] <slangasek> starting the X server
[21:50] <slangasek> starting dbus, avahi, cups, ...
[21:50] <slangasek> your clock settings
[21:51] <slangasek> your firewall
[21:51] <slangasek> etc
[21:51] <slangasek> there's a lot of stuff in /etc/init :)
[21:51] <slangasek> speaking of the firewall...
[21:51] <slangasek> http://people.canonical.com/~vorlon/upstart/ufw.conf
[21:51] <slangasek> that's how we start the ufw firewall on Ubuntu
[21:51] <slangasek> notice an interesting thing about this job?
[21:52] <slangasek> there's a pre-start exec and a post-stop exec, but there's no exec!
[21:52] <slangasek> even the main process part of an upstart job is optional
[21:52] <slangasek> you might be wondering why you would want to do that, though
[21:52] <slangasek> it's because we want to know whether the firewall is stopped or started, but there's no daemon we run that's associated with it - it's all in the kernel
[21:53] <slangasek> so instead of making it a 'task' (which upstart would show as stopped once it's finished), we make it a regular service that runs nothing!
[21:53] <slangasek> this also prevents upstart from trying to start it repeatedly
[21:53] <slangasek> notice that the start condition here is:
[21:53] <slangasek> start on (starting network-interface
[21:53] <slangasek>           or starting network-manager
[21:53] <slangasek>           or starting networking)
[21:53] <slangasek> that tells upstart to start it whenever it sees *any* of these events
[21:54] <slangasek> which, since this is a service, means it will start it on the *first* of these events that it sees
[21:54] <slangasek> and then stay "runninG"
[21:54] <slangasek> I have more examples, but no time to go over them... let's go to questions :)
[21:54] <ClassBot> penguin42 asked: What should I ask someone to do to help debug a startup issue on a remote machine with upstart?
[21:55] <slangasek> penguin42: have them turn on the verbosity of upstart with 'sudo initctl log-priority info' and get them to send you /var/log/syslog - and then get good at understanding that output, by practicing on your own system :)
[21:55] <ClassBot> There are are 5 minutes remaining in the current session.
[21:55] <ClassBot> tech2077 asked: Can any command be exicuted as a upstart, or are there limitations to this system
[21:56] <slangasek> well, it's kind of a limitation that upstart jobs are "system-level" services
[21:56] <slangasek> so you wouldn't really want to use it to start per-user services
[21:56] <slangasek> but otherwise, there aren't many limitations
[21:56] <slangasek> if you have questions and you haven't asked them yet, please get them to the bot now :-)
[21:56] <slangasek> I'll be available afterwards to answer questions, too
[21:56] <ClassBot> ktenney asked: where is a list of all such external events available?
[21:57] <slangasek> good question
[21:57] <slangasek> unfortunately, there is no comprehensive list of external events
[21:57] <slangasek> because you can make up event names whenever you want!
[21:57] <slangasek> but many of them are documented in the 'emits' lines in other upstart jobs (grep -r emits /etc/init)
[21:58] <slangasek> some of them also come from ifupdown helpers under /etc/network/if-up.d (grep -r initctl /etc/network)
[21:58] <slangasek> but there's no master list, and yes, this is a problem :/
[21:58] <ClassBot> Ram_Yash asked: Can use UPSTART job to run web application?
[21:58] <slangasek> if the web application runs as its own process, yes
[21:59] <slangasek> though usually, web applications run inside the webserver; in that case, the upstart job would be the webserver itself
[21:59] <ClassBot> zul asked: what if you have a daemon that depends on loopback
[21:59] <slangasek> great illustrative question, though I think zul maybe already knows the answer :)
[22:00] <slangasek> rc-sysinit.conf is an example of this!
[22:00] <ClassBot> Omahn18 asked: Who would be the best person(s) to contact to assist in moving init.d scripts to upstart scripts?
[22:00] <slangasek> in general, the Ubuntu foundations team - and now the Ubuntu server team - have the most experience with this, and I'm sure are happy to help with your questions
[22:01] <slangasek> thanks, everyone - I guess the sessions are over for the day, so I'm happy to take here any questions that we didn't get to
[22:01] <slangasek> sorry, the bot won't feed me any more questions now that the session is over, so I've kinda lost track :-)
[22:04] <simar_mohaar> hi