[03:49] <Flannel> jono: Please test
[03:50] <jono> thanks Flannel
[03:50] <jono> works :)
[03:50] <nigel_nb> great :)
[03:50] <jono> why is it set like this at the moment?
[03:50] <nigel_nb> either someone forgot or spam
[03:50] <jono> gotcha
[03:50] <jono> thanks!
[03:50] <jono> I am just testing some Lernid fixes
[03:51] <nhaines> haha
[03:51] <jono> everything seems to be working pretty well
[03:51] <nhaines> That one was a doozy.  ;)
[03:51] <jono> lol nha
[03:51] <jono> nhaines,
[03:51] <jono> it now has a more native IRC pane
[03:51] <jono> app indicator support
[03:51] <jono> and a bunch of fixes, ready for dev week
[03:51] <nhaines> Ooh!  Just in time.  :)
[03:51] <nigel_nb> oh great :)
[03:51] <jono> just want to fix up some last bits and then release a package
[03:52] <jono> :)
[03:53] <nigel_nb> jono, you got rid of webchat? (native irc?)
[03:53] <jono> nigel_nb, yep
[03:53] <nigel_nb> awesome! looking forward to UDW
[03:56] <paultag> jono, did you fix the IRC backend to fragment the window viewer, so it does not use two nicks?
[03:57] <nigel_nb> paultag, hm, I think so, I only see jonobacon and not lernid_jonobacon ;)
[03:57] <paultag> awesome :)
[03:57] <paultag> Then again I was not in -chat
[03:57] <paultag> Ah, there it is. Well done jono
[03:58] <jono> just finalizing some fixes
[03:58] <jono> and then will pump out a release
[04:01] <persia> Can lernid point at a proxy for client multiplexing, or does it always connect here?
[04:06] <nhaines> I don't understand how to get session information into Lernid.  :)
[04:06] <paultag> Perhaps lernid can ship with bindings for Firefox. So we can send lernid:// URLs to new users
[04:07] <paultag> lernid://irc.freenode.net/#ubuntu-classroom
[04:07] <paultag> and tweet the hell out of it :)
[04:13] <jono> anyone on Karmic here?
[04:13] <paultag> jono, yo
[04:13] <jono> paultag, are you on Karmic?
[04:13] <paultag> jono, yes
[04:13] <jono> paultag, could you check out Lernid and test it?
[04:13] <paultag> jono, sure thing, off your PPA?
[04:14] <jono> bzr branch lp:lernid
[04:14] <jono> and then:
[04:14] <jono> quickly run
[04:14] <paultag> Sure
[04:14] <jono> make sure you have it's dependenices
[04:14] <paultag> jono, sure thing. Let me give it a go
[04:14] <jono> thanks paultag!
[04:14] <paultag> sure thing
[04:21] <jono> paultag, any luck?
[04:22] <paultag> jono, working on getting EventManager in place
[04:22] <paultag> jono, is it in the repos?
[04:22] <jono> paultag, EventManager in place?
[04:22] <jono> no, like I say, I just want you to check out the code and run it
 bzr branch lp:lernid
[04:22] <jono>  and then:
[04:22] <jono>  quickly run
[04:23] <paultag> jono, oh, I was doing setup. Gimme a sec to grab quickly
[04:23] <jono> cool
[04:24] <jono> I just want someone to test it on Karmic
[04:24] <jono> I am running Lucid
[04:24] <paultag> Righto
[04:25] <nhaines> jono: I can test it after the Ubuntu California meeting.
[04:25] <paultag> Jeez, quickly is huge
[04:25] <jono> nhaines, can you test, would be awesome
[04:25] <paultag> nhaines, oh christ. I'm glad I'm not there ;)
[04:25] <paultag> jono, another minute or so
[04:25] <nhaines> jono: I'd be happy to.  :)
[04:26] <jono> thanks paultag
[04:26] <jono> cheers nha
[04:26] <jono> cheers nhaines
[04:29] <paultag> jono, it's up. Let me hammer on her
[04:30] <jono> paultag, cool, join Ubuntu Example Week
[04:30] <paultag> jono, I did, it bombed out. No IRC connection
[04:30] <paultag> Oh, there I am
[04:33] <paultag> jono, looking good so far
[04:34] <jono> paultag, cool, check Lernid
[04:34] <paultag> jono, I have it up :)
[04:40] <nhaines> Heh, longest. LoCo meeting. ever.
[04:49] <nhaines> I'm really looking forward to seeing Bazaar Explorer.  Sounds awesome.
[04:53] <nhandler>  QUESTION: Will I get an error in lernid with this?
[04:54] <paultag> already tried nhandler :)
[04:54] <paultag> night nhandler, nhandler_lernid :)
[04:54] <nhandler> ANSWER: Nope. But it might be a good idea to add an anchor at the start of the UDW schedule so that lernid can display the timetable portion of the page (which is the most interesting part)
[04:59] <nhaines> Looks like I'm missing gtkmozembed
[04:59] <nhandler> nhaines: If you are running the bzr version, it won't pull in the dependencies. Install lernid from a ppa first, and then run it from bzr
[05:00] <nhaines> Details!
[05:01] <nhaines> Hehe, let me do that.
[05:14] <thebwt> test...
[05:14] <nhaines> Hm, seems to be working.
[05:14] <nhaines> Maybe.  :)
[05:31] <nhaines> Quickly is so awesome.
[07:17] <cjohnston> test
[07:59] <linuxnoob> hallo
[08:08] <nhaines> Hello
[08:21] <qwebirc51456> -
[08:23] <Omar87__> Hi all
[08:23] <Omar87__> I wanted to ask, the times of the classes are based on what timezone?
[08:24] <Hammerhard> they are based on the UTC timezone
[08:25] <Omar87__> Hammerhard: So, there's going to be a Django class today?
[08:25] <Hammerhard> yes
[08:26] <Hammerhard> maybe this can help you, but it's in german
[08:26] <Hammerhard> http://ikhaya.ubuntuusers.de/2010/01/24/ubuntu-developer-week-im-januar-2010/
[08:26] <Omar87__> Hammerhard: thank you very much. I will do my best to attend as many of the classes as possible.
[08:47] <nhaines> Omar8714: this might help: https://wiki.ubuntu.com/Lernid
[09:44] <Omar87> For some reason, when I open lernid, I automatically get connected to a an Ubuntu chatroom in Spannish.
[09:44] <Omar87> How do I fix that?
[09:44] <jpds> jono: ^--.
[09:47] <Omar87> ahh.. no that was nothing. Sorry. :)
[09:48] <jono> Omar87, np :)
[09:53] <AlanBell> !ping
[09:53] <ubot2> Here I am, brain the size of a planet and you expect me to respond to a ping? How depressing.
[10:08] <AlanBell> and this is the classroom where the instructor will speak
[10:23] <netritious> Has the classroom event been canceled?
[10:23] <persia> No.  It hasn't started yet.
[10:23] <persia> Check the wiki, but I think it starts around 15:00 UTC.
[10:23] <persia> Right now, it's about half past ten.
[10:24] <netritious> persia: thank you for clearing that up...I had no idea why I thought it was at 10 UTC
[10:24] <netritious> *have no idea why
[10:27] <AlanBell> first is at 16:00 utc
[10:27] <AlanBell> @now
[10:28] <netritious> I seem to know why now..somehow when I imported the iCal available at the wiki into thunderbird everything starts at "10 a.m."..not sure why that happened
[10:31] <netritious> I must be losing it..that is exactly when the classes start in my timezone..10 a.m. CST
[10:32] <persia> Then you better sleep fast :)
[10:32] <netritious> heading that way now :)
[10:32] <push_ebx_> or get some coffee ;)
[10:34] <netritious> nah, think I'll opt for sleep..won't retain much after being awake 24+ hours :D
[10:34] <push_ebx_> :D
[11:10] <gudvin> hi all
[11:12] <gudvin> есь кто живой?
[11:53] <mbudde> http://ubuntu.com
[12:58] <Omar87> Hi all.
[13:21] <AlanBell> good afternoon everyone, todays sessions will begin at 16:00 UTC
[13:21] <AlanBell> @now
[13:55] <thebwt> @now
[14:54] <rodge> ls
[14:55] <cjohnston> @now
[14:57] <bulldog98> übrigens ist tiledqt in meinem PPA nun nutzbar
[15:13] <thetofucube> date -u
[15:14] <nigel_nb> thetofucube, in your terminal
[15:14] <nigel_nb> @now
[15:16] <thetofucube> opps wrong window
[15:16] <thetofucube> @now
[15:16] <thetofucube> thanks
[15:49] <xteejx> Hi all!
[15:49]  * thebwt waves at xteejx
[15:50] <shadeslayer> hey
[15:50] <thebwt> I think chatter is supposed to go to #ubuntu-classroom-chat
[15:50] <alecu> testing...
[15:52] <cjohnston> thebwt: yes.. it is :-)
[15:55] <xteejx> Hi thebtw :)
[15:56] <dholbach> [SLIDE 1]
[16:00] <dholbach> HELLO EVERYBODY! WELCOME TO UBUNTU DEVELOPER WEEK!
[16:00] <dholbach> I'm very very happy you all made it here
[16:00] <dholbach> First I'll talk about a few organisational things before we dive into session 1 "Getting Started with Ubuntu Development"!
[16:01] <dholbach> first of all: for those of you who are not using lernid to connect to Ubuntu developer week:
[16:01] <dholbach>  - #ubuntu-classroom is for the presentation only, so please keep chatter out of the channel
[16:02] <dholbach>  - #ubuntu-classroom-chat for discussion and for questions (please prefix with QUESTION:, ie: "QUESTION: What does xyz mean?")
[16:03] <dholbach>  - I put up some slides at http://people.canonical.com/~dholbach/ubuntu-development-getting-started.pdf which should at least give you a nice link collection - lernid users will see those slides as we move on through the session
[16:03] <dholbach> if you have general questions about the schedule, you can find it at https://wiki.ubuntu.com/UbuntuDeveloperWeek
[16:03] <dholbach> [SLIDE 1]
[16:04] <Omar87> dholbach: nothing here.
[16:04] <dholbach> another organisational note:
[16:04] <dholbach> if you plan to be here the full week and speak more languages than just English, consider adding yourself to the bottom of https://wiki.ubuntu.com/UbuntuDeveloperWeek
[16:05] <thebwt> rmunn_: lernid only clients can't get to #lernid
[16:05] <BluesKaj> howdy
[16:06] <dholbach> so for example:
[16:06] <dholbach> Catalan: #ubuntu-cat
[16:06] <dholbach> Danish: #ubuntu-nordic-dev
[16:06] <dholbach> Finnish: #ubuntu-fi-devel
[16:06] <dholbach> German: #ubuntu-classroom-chat-de
[16:06] <dholbach> Spanish: #ubuntu-classroom-chat-es
[16:06] <dholbach> French: #u-classroom
[16:07] <dholbach> it'd be great if you would help out translating questions and answers for those who are not comfortable speaking in English yet :)
[16:07] <dholbach> (thanks in advance)
[16:07] <dholbach> [SLIDE 1]
[16:07] <qwebirc98256> when it will start?
[16:08] <dholbach> thanks a lot jussi01
[16:08] <dholbach> ok... let's get started :)
[16:09] <dholbach> so what we're going to cover during the session is the following:
[16:09] <dholbach>  - get a basic development environment set up (gpg key, tell the packaging tools who we are, get pbuilder set up, etc.)
[16:09] <dholbach>  - cover the basics of contributing
[16:09] <dholbach>  - and hopefully answer lots of questions :)
[16:10] <dholbach> [SLIDE 2]
[16:10] <dholbach> so first of all, please run:
[16:10] <dholbach>  sudo apt-get install --no-install-recommends ubuntu-dev-tools build-essential pbuilder dpkg-dev gnupg
[16:10] <dholbach> this will install a bunch of packages we are going to need
[16:11] <dholbach> build-essential will pull in compilers and general tools for building packages
[16:11] <dholbach> gnupg we will need to sign packages (or encrypt data generally)
[16:12] <dholbach> ubuntu-dev-tools itself contains a lot of useful tools and will pull in a few others we are going to need to packaging and every-day tasks
[16:12] <dholbach> also please enable "Source code" in System -> Software Sources -> Ubuntu Software
[16:13] <dholbach> a question that is asked a lot of times is: "Do I really need to run the current development release? Won't that break my system?"
[16:13] <dholbach> The answer is "yes, for building and testing you need one form 'latest development release'"
[16:13] <dholbach> to do that in a sane way, you better check out https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[16:14] <dholbach> Also we do have these very fine sessions lined up for this week which talk about a similar topic:
[16:14] <dholbach>    TODAY, 19.00 UTC - Working on the Bleeding Edge -- kees
[16:14] <dholbach>    Wed 27th Jan, 19.00 UTC, Developing and Testing in KVM --kirkland
 QUESTION: Do any of the classes cover how to use debhelper and CDBS?
[16:15] <dholbach> xteejx71: there is no explicit "debhelper and cdbs" session, but I'm sure that some sessions will cover it briefly
[16:15] <dholbach> in any case I can recommend https://wiki.ubuntu.com/PackagingGuide
[16:15] <dholbach> [SLIDE 3]
[16:16] <dholbach> ok, let's start with setting up a gpg key
[16:17] <dholbach> gnupg stands for GNU privacy guard and can be used to sign and encrypt data in general (you'll see it in use very often with emails, but also general files)
[16:17] <dholbach> we use it to prove that one person (and nobody else) made a particular change to a file
[16:18] <cjohnston> < LumpyCustard> Question: What is the command to show the current gpg keys on the system?
[16:19] <dholbach> thanks cjohnston
[16:19] <dholbach> LumpyCustard: gpg --list-keys <email address>         should do that
[16:19] <cjohnston> < xteejx71> QUESTION: Do the gpg keys *have* to be registered with Launchpad?
[16:19] <dholbach> so if you already have a key set up, you can skip this step obviously
[16:20] <dholbach> xteejx71: it's necessary to use a PPA (Personal Package Archive) or to upload a package to Ubuntu (once you are part of any of the uploader teams)
[16:20] <dholbach> ok... so to generate a key you run the following
[16:21] <dholbach>   gpg --gen-key
[16:21] <dholbach> it's generally safe to just stick to the defaults
[16:21] <dholbach> if you want to have more information on setting gpg up, check out https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[16:22] <dholbach> now you tell gpg your name and your email address
[16:22] <dholbach> a comment is not necessary
[16:22] <dholbach> now it will create the key and that's likely going to take a bit longer
[16:23] <dholbach> (it will take random numbers from whatever your machine is doing right now to put that key together)
[16:23] <cjohnston> < Navaneeth> QUESTION: How can I upload a package to ubuntu repository? Where is that information documented?
[16:23] <dholbach> Navaneeth: we'll get to that later on
[16:23] <cjohnston> < bullgard> QUESTION I obtain: "public key not found." What should I do?
[16:24] <dholbach> bullgard: it likely means that you have no key set up yet?
[16:24] <dholbach> bullgard: I don't know what you just did, so can somebody please try to debug the problem with bullgard in #ubuntu-classroom-chat?
[16:24] <dholbach> cjohnston: next?
[16:24] <cjohnston> < bullgard> QUESTION I obtain: "public key not found." What should I do?
[16:24] <dholbach> cjohnston: next?
[16:25] <cjohnston> < Paddy_NI> QUESTION: What is the comment generally used for?
[16:25] <cjohnston> sorry
[16:25] <dholbach> Paddy_NI: gpg is used to create the key with which we sign data, files and emails or encrypt and decrypt them - you actually don't use the command itself very often, but there's other tools which rely on it
[16:26] <dholbach> alright, so let's move on to the next topic :)
[16:26] <dholbach> pbuilde
[16:26] <dholbach> pbuilder
[16:26] <dholbach> [SLIDE 4]
[16:26] <dholbach> pbuilder is a great tool to test-build packages in a clean and minimal environment
[16:27] <cjohnston> < fubarrrr44> QUESTION: Why do I need root permissions to (just) build a .deb package? (wi    th rpm this is not needed)
[16:27] <dholbach> whenever you start a build it will set up a minimal environment, install the build-dependencies, start the build itself and remove the build-dependencies afterwards again (it will cache them though)
[16:27] <dholbach> fubarrrr44: pbuilder uses chroot internally
[16:28] <dholbach> fubarrrr44: if you use just "debuild" (and install the build-dependencies on your "live system"), you don't need root permissions either
[16:28] <dholbach> the maint points of pbuilder are:
[16:28] <dholbach>  - keep your live system clean (you don't need to install 427697426246 build dependencies)
[16:29] <dholbach>  - make sure the package builds in a minimal, unmodified environment
[16:29] <dholbach> there are other tools that do similar jobs, and there's pbuilder-dist (in the ubuntu-dev-tools package), which is great
[16:29] <dholbach> there's more info on https://wiki.ubuntu.com/PbuilderHowto
[16:30] <dholbach> please edit ~/.pbuilderrc in your favourite editor
[16:30] <dholbach> and add this to it:
[16:30] <dholbach> COMPONENTS="main universe multiverse restricted"
[16:30] <dholbach> then save the file
[16:30] <dholbach> then run
[16:30] <dholbach>    sudo pbuilder create
[16:30] <dholbach> this, too, will take a while
[16:30] <dholbach> as it will create a minimal system "from scratch"
[16:31] <dholbach> ok, let's crack on
[16:31] <dholbach> [SLIDE 5]
[16:31] <dholbach> now we'll tell the development tools who we are
[16:31] <dholbach> please edit ~/.bashrc with your favourite editor
[16:32] <dholbach> and add something like this to the end of it:
[16:32] <dholbach>  export DEBFULLNAME='Daniel Holbach'
[16:32] <dholbach>  export DEBEMAIL='daniel.holbach@ubuntu.com'
[16:32] <dholbach> afterwards please save the file
[16:32] <dholbach> and run
[16:32] <dholbach>   source ~/.bashrc
[16:32] <dholbach> (or restart your terminal)
[16:32] <dholbach> by setting DEBFULLNAME and DEBEMAIL:
[16:33] <dholbach>  - you don't have to type in your email address
[16:33] <dholbach>  - and name
[16:33] <cjohnston> < xteejx71> QUESTION: I never done the COMPONENTS bit before...does this make a difference when using pbuilder?
[16:33] <dholbach>  - and gpg key id all the time
[16:33] <dholbach> and ... PLEASE ... use your own name and email address!
[16:33] <dholbach> :-)
[16:33] <dholbach> xteejx71: if you want to use universe and multiverse to build packages, then yes, you need it
[16:34] <dholbach> are there any more questions? please keep them coming in #ubuntu-classroom-chat
[16:34] <dholbach> if not, I'll keep on talking about a few things while pbuilder and gpg are doing their thing
[16:34] <cjohnston> < ulysses> QUESTIN: Can I use characters in DEBFULLNAME like 'ó' and 'á'?
[16:35] <dholbach> ulysses: yes, I'd be surprised if that wouldn't work :)
[16:35] <cjohnston> < xteejx71> QUESTION: Can pbuilder be used to create anything other the the Lucid environment?
[16:36] <dholbach> xteejx71: yes, have a look at https://wiki.ubuntu.com/PbuilderHowto - there's some variable you need to set, or use pbuilder-dist which can easily cope with multiple parallel pbuilders
[16:36] <dholbach> alright... let's talk about the release schedule for a bit
[16:36] <cjohnston> < xteejx71> QUESTION: If I already have run 'sudo pbuilder create' will this overwrite the old one or create a new one?
[16:36] <dholbach> xteejx71: I think I creates a new one
[16:36] <dholbach> xteejx71: might be best to check the manpage
[16:37] <dholbach> [SLIDE 6]
[16:37] <dholbach> https://wiki.ubuntu.com/LucidReleaseSchedule
[16:37] <dholbach> that's the current release schedule we have for this cycle
[16:37] <dholbach> you can see that we're in the "yellow phase" right now
[16:37] <dholbach> in every cycle we roughly do the following:
[16:38] <dholbach>  - set up the toolchain (the core build tools)
[16:38] <dholbach>  - discuss features at the Ubuntu Developer Summit
[16:38] <dholbach>  - merge changes from Upstream and Debian
[16:38] <dholbach>  - work on features
[16:38] <dholbach>  - debug problems
[16:38] <dholbach>  - polish
[16:38] <dholbach>  - release
[16:39] <dholbach> it was just pointed out that we're in the orange phase... yeah, that's right :)
[16:39] <cjohnston> < kjele> Question: When I build with pbuilder it pulls down the required dependencies to compile the program. Is it possible to make sure it does not download each time I try to build?
[16:39] <dholbach> as you can easily see, the later it gets in the release cycle, the more conservative we get about changes
[16:39] <dholbach> towards the end we focus more on testing and obvious good bugfixes than on "crack of the day"
[16:40] <dholbach> kjele: it does cache those build-depends by default
[16:40] <dholbach> so if you ask the question "How can I help out?" or "What can I do?" it heavily depends on where we stand in the release cycle
[16:40] <cjohnston> < Navaneeth> QUESTION: I heard ubuntu is not contributing to upstream. is that correct? If yes, why?
[16:41] <dholbach> Navaneeth: that's not correct
[16:41] <dholbach> Navaneeth: if you have a look at https://wiki.ubuntu.com/Upstream you can see that we put a lot of energy in collaborating effectively with upstreams
[16:41] <dholbach> maybe I should clarify what "upstreams" are and how everything fits in one picture
[16:42] <dholbach> if you imagine millions of Ubuntu users on the one side
[16:42] <dholbach> and thousands of software projects like the kernel, like X, like GNOME, KDE, like Mozilla, like the authors of the crack-attack game and lots of others
[16:42] <dholbach> on the other side
[16:43] <dholbach> then Ubuntu (and other distributions) stand in the middle and try to make the conversation happen between the two of them
[16:43] <dholbach> those "software authors" on the other side are our upstreams
[16:44] <dholbach> here's a list of things we contribute to upstream projects:
[16:44] <dholbach>  - exposure of their software (distributions are the best way to get great software without hassle)
[16:45] <dholbach>  - well-researched bug reports: we get LOADS and LOADS of bug reports every day and we put a lot of work into making them top-notch reports by automatically getting debug stacktraces, etc etc - basically we filter "defect reports" for upstream project
[16:45] <dholbach> s
[16:45] <dholbach>  - we test their software in lots of different scenarios
[16:45] <dholbach>  - and we forward patches
[16:46] <dholbach> sure there's not a group of Ubuntu developers for every piece of software that exists
[16:46] <dholbach> but we put a lot of hard work into working with Upstream projects
[16:46] <cjohnston> < fubarrrr44> QUESTION: How do I prevent pbuilder from doing clean up after work (to look at the generated chroot environment)?
[16:46] <dholbach> check out "Adopt-an-Upstream" by jcastro and dholbach on Thursday
[16:47] <dholbach> fubarrrr44: you can use    sudo pbuilder login   or just chroot for testing
[16:47] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases might be helpful oto
[16:47] <dholbach> too
[16:47] <cjohnston> < LumpyCustard> Qn: How do I register the gpg key I've just made with Launchpad?
[16:47] <dholbach> LumpyCustard: great question!
[16:48] <dholbach> so first of all to find out your gpg key id, do the following: run
[16:48] <dholbach>    gpg --fingerprint your.name@email.com
[16:48] <dholbach> for me it displays the following:
[16:48] <dholbach>  pub   1024D/059DD5EB 2007-09-29
[16:48] <dholbach>        Schl.-Fingerabdruck = 3E5C 0B3C 8987 79B9 A504  D7A5 463A E59D 059D D5EB
[16:48] <dholbach>  uid                  Daniel Holbach .......
[16:48] <dholbach> 059DD5EB is my "KEY ID"
[16:48] <dholbach> now to send you public key (your private key will always stay safe) to the keyservers so others can verify your signatures:
[16:49] <dholbach> gpg --send-keys KEYID
[16:49] <dholbach> and to register your key with Launchpad, head to https://launchpad.net/people/+me/+editpgpkeys
[16:50] <dholbach> Ok... if your pbuilder is set up, you might want to try the following:
[16:50] <dholbach>  apt-get source hello
[16:50] <dholbach>  sudo pbuilder build hello_*.dsc
[16:51] <dholbach> if you follow the output from pbuilder closely you will see how it first sets up the initial minimal environment, then download additional build dependencies, then build the package, then remove the build environment again
[16:51] <dholbach> depending on your net connection and the speed of your CPU and disk it might take a little bit
[16:52] <cjohnston> < IdleOne> QIESTION sorry if you covered this already but what if I already have a key uploaded to launchpad, how do I use it?
[16:52] <dholbach> IdleOne: just head to https://launchpad.net/people/+me/+editpgpkeys and use your existing key
[16:52] <dholbach> https://help.launchpad.net/YourAccount/ImportingYourPGPKey will help too
[16:53] <dholbach> something I forgot to mention when we were talking about the relase cycle
[16:53] <dholbach> really really important fixes we need after a release is "out there" are SRUs
[16:53] <dholbach> SRU is short for Stable Release Updates
[16:54] <dholbach> basically it's for REALLY IMPORTANT stuff, and the packages that you get through xyz-updates
[16:54] <dholbach> the procedure and criteria for SRUs are listed here: https://wiki.ubuntu.com/StableReleaseUpdates
[16:54] <cjohnston> < n3rd> Question : Is there a way to make a single deb out of multiple binaries, say for example i call it server.deb it must install few binaries ask per my tweaks like apache, tomcat, activemq so on
[16:55] <dholbach> also there's a small cheat-sheet regarding the release cycle over here: http://people.canonical.com/~dholbach/cheatsheet.pdf
[16:55] <dholbach> [SLIDE 7]
[16:55] <dholbach> n3rd: yes, you would create an empty binary package that has the following line in debian/control: "Depends: apache, tomcat, activemq"
[16:55] <dholbach> we'll talk a bit more about that in the next session
[16:56] <dholbach> there's two final things I'd like to mention in this session (before we start the next one):
[16:56] <dholbach>  - head to #ubuntu-motu on irc.freenode.net if you have any problems - there's great people who are able to help and who will become friends after a while :-)
[16:56] <dholbach>  - bookmark https://wiki.ubuntu.com/MOTU/GettingStarted - it links to everything that's important
[16:57] <dholbach> let's all take a few minutes break before move on to "Fixing small bugs in Ubuntu" :-)
[17:02] <dholbach> Alrighty... welcome back to Ubuntu Developer Week - this time it's "Fixing small bugs in Ubuntu" :-)
[17:02] <dholbach> I picked a few small bugs and I hope a few things will be clearer:
[17:03] <dholbach>  - how to use basic tools in every day situations later on
[17:03] <dholbach>  - learn the process of fixing something, how to propose the fix to get accepted, etc.
[17:03] <dholbach> so we're not going to cover kernel hacks, crazy C++ stuff or anything else in here :-)
[17:04] <dholbach> ok... the first bug I want us to have a look at is: https://bugs.launchpad.net/ubuntu/+source/fsniper/+bug/486612
[17:05] <dholbach> if you check it out, you'll see that indeed it is a small bug, it's about a typo in the package description of fsniper
[17:05] <dholbach> to confirm it, just run
[17:05] <dholbach>   apt-cache show fsniper
[17:05] <dholbach> and it says this towards the end:
[17:05] <dholbach>  This packages comes with no generic rules, so you must write
[17:05] <dholbach>  them yourself.
[17:05] <dholbach> so... we're going to fix it!
[17:06] <dholbach> first of all, let's get the package source:
[17:06] <dholbach>   apt-get source fsniper
[17:06] <dholbach> if you run  ls   you will see that it downloaded a .orig.tar.gz, a .diff.gz and a .dsc file
[17:06] <dholbach> and that it created a directory called fsniper-1.3.1
[17:07] <dholbach> ok, here's how it all fits together:
[17:07] <cjohnston> < vishalrao_dsktop> QUESTION: where does apt-get source store source files?
[17:07] <dholbach>  - orig.tar.gz is the file that the upstream authors released on their website as the source code
[17:07] <dholbach>  - .diff.gz is the compressed set of changes we make to make the package build the "debian or ubuntu way"
[17:08] <dholbach>  - .dsc is just meta-data like md5sums etc
[17:08] <dholbach> apt-get downloaded the source from the archive, checked the md5sum, untarred the .orig.tar.gz file and applied the .diff.gz changes
[17:09] <dholbach> ok... let's fix this bug now :)
[17:09] <dholbach>   cd fsniper-1.3.1/
[17:09] <dholbach>   cat debian/control
[17:09] <dholbach> debian/control was added (among other things) by the Debian/Ubuntu maintainers of the package
[17:10] <dholbach> and it describes the source and the resulting binary package (in this simple case just one binary package)
[17:10] <cjohnston> < michae> QUESTION : no fsniper dir . Normal?
[17:10] <dholbach> the description at the bottom is what we need to fix
[17:10] <dholbach> this call ought to fix it for us:
[17:10] <dholbach>   sed -i 's/packages/package/g' debian/control
[17:11] <dholbach> michae: I'm sorry, I don't understand your question... can somebody help michae debug the problem in #ubuntu-classroom-chat please?
[17:11] <cjohnston> < thebwt-lernid> QUESTION: couldn't we just open our favorite editor and fix it as well? Why use sed?
[17:12] <dholbach> thebwt-lernid: yes, that'd work too and we'll make more use of the editor in due course :)
[17:12] <dholbach> ok... some folks said they ran into trouble because dpkg-dev was not installed - please make sure you have it
[17:13] <dholbach> so now that we fixed the problem, we need to document the changes we did
[17:13] <dholbach> please run
[17:13] <dholbach>   dch -i
[17:13] <dholbach> (you need devscripts installed for that - session 1)
[17:14] <dholbach> if you attended the first session, you will see your name and email address now, if you weren't here or did something wrong, you need to type it in manually
[17:15] <dholbach> ok, let's go through the changelog entry one by one
[17:15] <dholbach> the first line looks like the following over here:
[17:15] <dholbach> fsniper (1.3.1-0ubuntu3) lucid; urgency=low
[17:15] <dholbach> first the name of the source package, next the version, then the version of Ubuntu where we want to fix it in and an urgency setting which we can ignore for now
[17:16] <dholbach> let's have another look at the version name
[17:16] <dholbach> 1.3.1-0ubuntu3 means: 1.3.1 release by upstream, package was not in Ubuntu yet, 3 revisions in Ubuntu
[17:17] <dholbach> oops, sorry make that "package was not in Debian yet"
[17:17] <dholbach> 0.6-4 would mean: 0.6 release by upstream, 4 revisions in Debian, no changes in Ubuntu
[17:17] <dholbach> 1.2.3-4ubuntu5 would mean: 1.2.3 as released by upstream, 4 revisions in Debian, 5 changes following changes in Ubuntu
[17:17] <dholbach> etc.
[17:18] <dholbach> I hope it gets clearer as we work our way through a few examples
[17:18] <dholbach> next up is the description... dch leaves it empty for us, but I put something like this in there:
[17:18] <dholbach>   * debian/control: replaced "This packages" with "This package" (LP: #486612)
[17:18] <dholbach> when I write a changelog entry, I usually try to:
[17:18] <dholbach>  - mention which files I changes
[17:18] <dholbach>  - mention which files I changed
[17:18] <cjohnston> < SoftwareExplorer> QUESTION:Do the numbers after ubuntu reset when debian releases a new version?
[17:18] <dholbach>  - mention what I changed
[17:19] <dholbach>  - mention where the change was discussed (bug report, mailing list post, etc.)
[17:19] <dholbach>  - and as (LP: #486612) means "Launchpad bug 4855112", in this special notation the bug will get automatically closed on upload :)
[17:20] <dholbach> SoftwareExplorer: no, if we introduce changes in Ubuntu, we need to either manually merge our changes with Debian changes or we need to decide to drop our changes altogehter and overwrite our package with that from Debian - in the latter case, yes, the version is "reset"
[17:21] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/Merging has more info
[17:21] <cjohnston> < venuz> QUESTION:how do we resolve cyclic dependency?
[17:21] <dholbach> and on Friday, 17 UTC we will have a dedicated session about that
[17:21] <dholbach> venuz: that's a more complicated subject and nothing we can discuss in this session, can you please head to #ubuntu-devel and ask there?
[17:21] <dholbach> ok, let's move on
[17:22] <cjohnston> < strycore74> QUESTION: Is there a way to quickly view all the changes I made in the source code while I'm writing the source code ? Should I keep an intact verison of the source to diff with my
[17:22] <cjohnston>                     version ?
[17:22] <dholbach> so once you wrote something nice into the changelog entry, please save the file
[17:22] <dholbach> and run
[17:22] <dholbach>   debuild -S
[17:22] <dholbach> strycore74: I'm going to mention that in just a sec :)
[17:23] <cjohnston> < xteejx71> QUESTION: what is the difference between the -S and the -S -sa commands?
[17:23] <dholbach> xteejx71: -S will build the source package, -sa is something we can ignore for now - it's just relevant if you want to upload the package somewhere (-sa will also upload the .orig.tar.gz tarball) - please refer to the debuild or dpkg-buildpackage manpage :)
[17:24] <dholbach> please run
[17:24] <dholbach>   sudo apt-get install quilt
[17:24] <dholbach> if   "debuild -S"   gave you an error message
[17:24] <dholbach> and try again
[17:24] <dholbach> thanks dbell
[17:25] <dholbach> please let me know in #ubuntu-classroom-chat if that worked out for you :)
[17:25] <dholbach> ok, some of you seem to have got a debsign error. we can ignore that for now.
[17:26] <dholbach> it likely means that you either didn't set up your gpg key correctly, or you gave a different name and email address in your gpg set up and in DEBEMAIL/DEBFULLNAME in ~/.bashrc
[17:26] <dholbach> we don't need to sign it now, so please ignore it for now :)
[17:26] <dholbach> some of you might also need to run:
[17:26] <dholbach>   sudo apt-get install debhelper
[17:26] <dholbach> sorry :)
[17:27] <dholbach> thanks vishalrao_dsktop
[17:27] <dholbach> you can run all these commands as regular user, 'sudo' should just be required for pbuilder
[17:28] <dholbach> alright, let's crack on, please rerun "debuild -S" once you install debhelper and quilt
[17:28] <dholbach> then please run
[17:28] <dholbach>  cd ..
[17:28] <dholbach> now please run
[17:28] <dholbach>   debdiff fsniper_1.3.1-0ubuntu2.dsc fsniper_1.3.1-0ubuntu3.dsc > fsniper.debdiff
[17:28] <cjohnston> < mhall119|work> QUESTION: I get a gpg error saying "secret key not available"
[17:29] <dholbach> mhall119|work: very likely whatever you have in DEBEMAIL / DEBFULLNAME in ~/.bashrc and in your gpg key set up don't match - please ignore it for now or try to debug it in #ubuntu-classroom-chat
[17:30] <dholbach> you might also need the  patchutils  package, so please install that too
[17:30] <dholbach> ok............
[17:31] <dholbach> once you have all that sorted out, please copy the content of fsniper.debdiff to http://paste.ubuntu.com
[17:31] <dholbach> and say something like          MY-PATCH: http://paste.ubuntu.com/......      in #ubuntu-classroom-chat and I'll take a look at it
[17:32] <dholbach> if we did everything right, we might all have a nice patch ready now :)
[17:32] <dholbach> xteejx71: http://paste.ubuntu.com/362732/ looks great
[17:33] <dholbach> alastair: http://paste.ubuntu.com/362734/ looks good, just replace "karmic" with "lucid", karmic is release already - apart from that: great work!
[17:33] <dholbach> strycore74: http://paste.ubuntu.com/362731/ looks great
[17:34] <dholbach> vishalrao_dsktop: http://paste.ubuntu.com/362735/ looks great (just karmic -> lucid)
[17:35] <dholbach> netritious: http://pastebin.com/f28cffa07 looks good (karmic -> lucid too and maybe your realname :-))
[17:35] <cjohnston> < Ravm> QUESTION: So, if I made a mistake, do I just alter the patch, or redo the sequence?
[17:35] <dholbach> rmunn: http://paste.ubuntu.com/362740/ looks good, karmic->lucid too and I'd mention which file you changed :)
[17:36] <dholbach> Ravm: re-do the sequence in almost all circumstances
[17:36] <dholbach> Ravm: it's very easy to botch up the patch file and whoever is reviewing the patch later on can't apply it
[17:37] <dholbach> I'm proud of you guys! Awesome work! First patch done! YEEEEEEHAW! :-)
[17:37] <dholbach> ok, let's do another one... we have 23 minutes left :-D
[17:37] <cjohnston> < dbell> QUESTION: do we need to go through the whole process again to change karmic to lucid, do we need to run lucid, or can we just edit the debdiff and change it there?
[17:37] <dholbach> dbell: just update karmic to lucid, then run "debuild -S" again
[17:38] <dholbach> (and run "debdiff ...")
[17:38] <dholbach> the next bug I found it a bit more complicated :-)
[17:38] <cjohnston>  < mhall119|work> QUESTION you wouldn't have to re-do the dch part unless it's been uploaded, right?
[17:38] <dholbach> mhall119|work: yes, you'd just run edit debian/changelog instead
[17:39] <dholbach> ok... here's the next bug:  https://bugs.launchpad.net/ubuntu/+source/meld/+bug/417369
[17:39] <dholbach> somebody requests the meld package to be updated
[17:39] <cjohnston>  < Navaneeth> QUESTION: Is this the same procedure to fix defects even if they are in code (C or C++)? If yes, Once they are fixed, will it goto original projects source repository?
[17:40] <dholbach> Navaneeth: the procedure can change somewhat, and the change needs to be forwarded to upstream authors by you manually
[17:40] <dholbach> ok... let's fix up meld now
[17:41] <dholbach> the bug requests 1.3.1
[17:41] <dholbach> in lucid I get the following:
[17:41] <dholbach> daniel@miyazaki:~$ apt-cache showsrc meld | grep ^V
[17:41] <dholbach> Version: 1.3.0-2
[17:41] <dholbach> daniel@miyazaki:~$
[17:41] <cjohnston> < xteejx71> QUESTION: Should we now remove all the old build files for hello and fsniper?
[17:41] <dholbach> xteejx71: as you like it
[17:41] <dholbach> ok, so we indeed have to fix meld
[17:41] <dholbach>   apt-get source meld
[17:41] <dholbach>   cd meld-1.3.0
[17:42] <cjohnston> < lbrinkma> QESTION: Should this upgrade performed upstream(debian)?
[17:42] <dholbach> now you need devscripts installed
[17:42] <dholbach> lbrinkma: in theory, yes, as much in Debian as possible
[17:42] <dholbach> lbrinkma: sometimes you will find that Debian is in a freeze period or that we need a fix urgently - in that case we upload to Ubuntu directly
[17:42] <dholbach> or if the Debian maintainer is on holidays, etc :)
[17:43] <dholbach> now please run:
[17:43] <dholbach>   uscan
[17:43] <dholbach> if you run
[17:43] <dholbach>   ls ..
[17:43] <cjohnston> < xteejx71> QUESTION: Does it make a difference if we update an Ubuntu package, since Ubuntu and Debian sync each other right?
[17:43] <dholbach> it will show you that it downloaded meld-1.3.1.tar.gz from the upstream website - cool, eh?
[17:44] <dholbach> (debian/watch does thaT)
[17:44] <dholbach> xteejx71: check out https://wiki.ubuntu.com/SyncRequestProcess and https://wiki.ubuntu.com/UbuntuDevelopment/Merging - Jorge and I will cover that explicitly in Adopt-An-Upstream :)
[17:45] <dholbach> next we use that tarball to "update the package"
[17:45] <dholbach> please run
[17:45] <dholbach>   uupdate ../meld_1.3.1.orig.tar.gz
[17:46] <dholbach> what it does it the following:
[17:46] <dholbach>  - untar the mentioned tarball
[17:46] <dholbach>  - apply the current set of changes (1.3.0 .diff.gz)
[17:46] <dholbach>  - add a template changelog entry
[17:46] <dholbach> nice, eh? :-)
[17:46] <dholbach> now please:
[17:46] <dholbach>   cd ../
[17:46] <dholbach>   diff -u meld-1.3.{0,1}/INSTALL
[17:47] <dholbach> what that command does is show you the differences between the INSTALL file (a document provided by upstream) between the two releases
[17:48] <dholbach> the important information we filter out now is:
[17:48] <dholbach> -##  * pygtk-2.6.0
[17:48] <dholbach> -##  * gnome-python-2.6.0
[17:48] <dholbach> +##  * pygtk-2.8.0
[17:48] <dholbach> +##  * gnome-python-2.8.0
[17:48] <dholbach> (it tells us that new versions of gnome-python and pygtk are required)
[17:48] <dholbach> if you intend to take care of a package update, be sure to check what changed internally so your users aren't confused afterwards :-)
[17:48] <dholbach> now
[17:48] <dholbach>   cd meld-1.3.1
[17:48] <dholbach> and edit debian/control.in
[17:49] <dholbach> (in this case it's debian/control.in and not debian/control because of specialties in the Debian GNOME team)
[17:50] <dholbach> I'll now change this line          python-gtk2 (>= 2.4),            to use 2.8
[17:50] <dholbach> also I'll update                python-gnome2,              to have (>= 2.8)
[17:50] <dholbach> now save the file
[17:50] <dholbach> and run
[17:50] <dholbach>   rm debian/patches/pythonpath.patch
[17:51] <dholbach> (this is a patch that is not required any more... I'm just saying it now as we only have 9 minutes left - I tested this before :-))
[17:52] <dholbach> now please edit debian/changelog and document your changes :)
[17:53] <dholbach> now please run
[17:53] <dholbach>   update-maintainer
[17:53] <dholbach> (from the ubuntu-dev-tools package)
[17:53] <dholbach> rationale: the Debian maintainers asked us to set an ubuntu.com email address as the Maintainer whenever we introduce a change over Debian so they don't get email for it :-)
[17:53] <dholbach> https://wiki.ubuntu.com/DebianMaintainerField
[17:54] <dholbach> also please edit debian/rules
[17:54] <dholbach> and remove the following line
[17:54] <dholbach>    DEB_INSTALL_CHANGELOGS_ALL += changelog
[17:54] <dholbach> save the file
[17:54] <dholbach> and run
[17:54] <dholbach>   debuild -S -sa
[17:55] <dholbach> you might need gnome-pkg-tools installed
[17:55] <dholbach> once you're done with this, you can build the package by running the following
[17:55] <dholbach>   sudo pbuilder build meld_1.3.1-0ubuntu1.dsc
[17:55] <dholbach> or rather:
[17:55] <dholbach>  cd ..
[17:55] <dholbach>  sudo pbuilder build meld_1.3.1-0ubuntu1.dsc
[17:56] <dholbach> sorry for ploughing through this like this but we were running out of time
[17:56] <cjohnston> < Navaneeth> QUESTION: If I submitted a patch to launch pad and didn't send that to original authors. So does that lead into multiple versions of package? And what happens if the patch submitted to launch pad is not the one the real authors like to include? How ubuntu handles such scenarios?
[17:56] <dholbach> normally we would have fixed the bugs one by one
[17:56] <dholbach> Navaneeth: first of all the patch is not automatically sent upstream
[17:57] <dholbach> https://wiki.ubuntu.com/SponsorshipProcess explains how to get a patch reviewed for inclusion by Ubuntu developers
[17:57] <dholbach> sometimes they are going to ask you to get in touch with upstream developers and forward the patch there first (if it's not obvious)
[17:57] <dholbach> generally we prefer to stay in sync with upstream
[17:57] <dholbach> and want good reasons to deviate
[17:57] <dholbach> cjohnston: next
[17:57] <cjohnston> < Quintasan> QUESTION: what is the Build-Depends-Indep line?
[17:59] <dholbach> Quintasan: Build-Depends and Build-Depends-Indep are packages that are necessary to build packages
[17:59] <dholbach> if a package is Architecture: all, you list under Build-Depends all the packages that are necessary to run the clean target and the rest under build-depends-indep (sorry it's a bit short, but we#re out of time, sorry)
[18:00] <dholbach> have a look at https://wiki.ubuntu.com/PackagingGuide for more info
[18:00] <dholbach> https://wiki.ubuntu.com/MOTU/GettingStarted is what you need to bookmark :)
[18:00] <dholbach> and THANKS EVERYBODY
[18:00] <dholbach> this session was awesome! :-)
[18:01] <Daviey> thank you sir
[18:01] <dholbach> next up is Dave Walker who will talk about a fantastic piece of software to write (web) software: Django!
[18:01] <Daviey> Hello everyone, and thanks for being here!
[18:01] <Daviey> I'm happy to have questions as they come, so if you have a question - please feel free to interupt me
[18:02] <Daviey> via QUESTION: Some question ---> in #ubuntu-classroom-chat
[18:02] <Daviey> (hope that makes sense)
[18:02] <Daviey> I'll start.
[18:02] <Daviey> Django is a "Web Framework".. I'm sure many of you have an idea what this is
[18:02]  * dholbach hugs Daviey
[18:03] <Daviey> However, some people (including myself) were totally baffled when we first tried to start with it
[18:03] <Daviey> In this session, i hope to give a good introduction and allow everyone to make thier first app
[18:03] <Daviey> Django has a slogan of "The Webframework for perfectionists with deadlines"
[18:04] <Daviey> This is kinda catchy :)
[18:04] <Daviey> If we try to start a project, hopefully people can follow.
[18:04] <Daviey> I'll explain what each part is inside the "project"
[18:04] <Daviey> many people install django from the repositories via "sudo apt-get install python-django"
[18:05] <Daviey> However, many people feel that it doesn't provide a new enough version - so they install it other ways
[18:05] <Daviey> I'll get more onto that later.
[18:05] <Daviey> Once it is installed, we have an extra app that we can run.
[18:05] <Daviey> If you installed via the repositories it is called django-admin
[18:05] <Daviey> If you installed via source it is called django-admin.py
[18:06] <Daviey> If we try and create a very simple blog i wold od
[18:06] <Daviey> dave@boogie:~/django$ django-admin startproject blogsite
[18:07] <Daviey> this then creates the following:
[18:07] <Daviey> dave@boogie:~/django/blogsite$ ls
[18:07] <Daviey> __init__.py  manage.py  settings.py  urls.py
[18:07] <Daviey> This is the basis of our application
[18:07] <Daviey> manage.py is our application we use to RUN certain commands
[18:07] <Daviey> so it's the only executable we will use from now on
[18:08] <Daviey> The default settings file called, settings.py is here http://pastebin.com/f4533df0f
[18:08] <Daviey> As you can see it's very well documented.
[18:09] <Daviey> The database backends provide abstraction, so we really don't care what the actual database type is
[18:09] <Daviey> it could be sqlite3, mysql, postgres (my fav.) or oracle
[18:09] <Daviey> We won't need to care about SQL commands, that are normally associated with web applications
[18:09] <Daviey> urls.py is here, http://pastebin.com/f64110653
[18:10] <Daviey> It allos us to describe via a regex where to direct http requests
[18:10] <Daviey> Everyone following ok?
[18:10] <Pendulum>  < Navaneeth> QUESTION: If we don't care about SQL statements, how specific optimizations on SQL can be applied?
[18:11] <Daviey> Navaneeth: Good question..  Because everything is an object, if we code our applications in a sane way it should be quite optimal in the SQL queries
[18:11] <Daviey> you can manually run sql commands, but you often don't need to
[18:11] <Pendulum> < n3rd> Question:manage.py is our application we use to RUN certain commands..like?
[18:12] <Daviey> django can also cache the requests to mean that it doesn't need to do the same query multiple times
[18:12] <Daviey> n3rd: that comes next :)
[18:12] <Daviey> dave@boogie:~/django/blogsite$ ./manage.py startapp blog
[18:13] <Daviey> So what we have done now is create a app inside our project called blog
[18:13] <Daviey> dave@boogie:~/django/blogsite/blog$ ls
[18:13] <Daviey> __init__.py  models.py  tests.py  views.py
[18:13] <Daviey> That stuff was all included automatically
[18:13] <Daviey> but before i explain what each of those does, i would like to show you all the admin interface
[18:14] <Daviey> dave@boogie:~/django/blogsite$ ./manage.py syncdb
[18:14] <Daviey> This will create all our database tables that we require
[18:14] <Daviey> As i've only enabled the admin, via adding "django.contrib.admin" to the INSTALLED_APPS section of settings.py
[18:14] <Daviey> it will only create that
[18:15] <Daviey> FLOOD:
[18:15] <Daviey> dave@boogie:~/django/blogsite$ ./manage.py syncdb
[18:15] <Daviey> Creating table django_admin_log
[18:15] <Daviey> Creating table auth_permission
[18:15] <Daviey> Creating table auth_group
[18:15] <Daviey> Creating table auth_user
[18:15] <Daviey> Creating table auth_message
[18:15] <Pendulum> Question : got this error : django.core.exceptions.ImproperlyConfigured: You haven't set the database ENGINE setting yet.
[18:15] <Daviey> Creating table django_content_type
[18:15] <Daviey> Creating table django_session
[18:15] <Daviey> Creating table django_site
[18:15] <Daviey> You just installed Django's auth system, which means you don't have any superusers defined.
[18:15] <Daviey> Would you like to create one now? (yes/no): yes
[18:15] <Daviey> Username (Leave blank to use 'dave'):
[18:15] <Daviey> E-mail address: davewalker@ubuntu.com
[18:15] <Daviey> Password:
[18:15] <Daviey> Password (again):
[18:15] <Daviey> Superuser created successfully.
[18:15] <Daviey> Installing index for admin.LogEntry model
[18:15] <Daviey> Installing index for auth.Permission model
[18:15] <Daviey> Installing index for auth.Message model
[18:16] <Daviey> As you can see, manage.py created the database tables
[18:16] <Daviey> Okay, i did add one more change
[18:16] <Daviey> in settings.py add:
[18:16] <Daviey> DATABASE_ENGINE = 'sqlite3'           # 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
[18:16] <Daviey> DATABASE_NAME = 'database.sql3'             # Or path to database file if using sqlite3.
[18:16] <Daviey> That will mean it will use sqlite3, and a file called database.sql3
[18:16] <Daviey> okay?
[18:17] <Daviey> so whoever that was, now run syncdb
[18:17] <Daviey> now if i do:
[18:17] <Daviey> ./manage.py runserver
[18:17] <Daviey> I get an development webserver built in for free!
[18:18] <Daviey> http://ubuntu.dev.week.daviey.com:8000/
[18:18] <Daviey> However, there isn't a whole lot going on there (yet)
[18:18] <Daviey> feel free to have a look
[18:18] <Daviey> Okay, now back to the blog app we started
[18:19] <Daviey> dave@boogie:~/django/blogsite/blog$ ls
[18:19] <Daviey> __init__.py  models.py  tests.py  views.py
[18:19] <Daviey> __init__.py - runs when the app is loaded
[18:19] <Daviey> it's empty by default, and tends to stay that way
[18:19] <Daviey> models.py - This is where we describe our database structure.  You can do much more
[18:20] <Daviey> But for this, we will limit it to simply describing your database as objects
[18:20] <Daviey> http://pastebin.com/f295abd14 <-- pretty much empty
[18:20] <Daviey> We have our views.py - http://pastebin.com/f50aad6cb
[18:21] <Daviey> This is how we describe how our data is shown to the user.
[18:21] <Daviey> lets start putting some content in there
[18:22] <Daviey> http://pastebin.com/f5d4145da <-- that is the contents of my models.py
[18:22] <Daviey> Now, we need to tell the project we are actually using it.
[18:22] <Daviey> If everyone doing ok so far?
[18:22] <Daviey> ok
[18:23] <Daviey> dave@boogie:~/django/blogsite$ nano settings.py
[18:23] <Daviey> I'm adding "    'blogsite.blog',
[18:23] <Daviey> "
[18:23] <Daviey> inside the INSTALLED_APPS section.
[18:23] <cjohnston> < tiemonster> QUESTION: the admin.site.register doesn't necessarily have to go in an admin.py?
[18:24] <Daviey> tiemonster: hmm, you could put it in __init__.py
[18:24] <Daviey> but it makes sense to put it in the admin.py
[18:24] <Daviey> admin.py is a fairly new feature that was introduced in 1.0 iirc..
[18:24] <Daviey> anyway, we don't need to cover that atm
[18:25] <Daviey> KISS :)
[18:25] <cjohnston>  < tiemonster> QUESTION: So it doesn't matter where you declare the admin.site.register?
[18:25] <Daviey> I'll wait for the netsplit to finish before continuing
[18:26] <Daviey> Okay, i think i will continue
[18:27] <Daviey> tiemonster: technically it doesn't matter where you register it
[18:27] <Daviey> All it's doing is telling the admin interface to be aware of these objects
[18:27] <Daviey> i tend to do it in models.py i think
[18:27] <Daviey> but you could put it anywhere that is aware of the model
[18:27] <Daviey> dave@boogie:~/django/blogsite$ ./manage.py syncdb
[18:27] <Daviey> Creating table blog_blogpost
[18:27] <Daviey> Installing index for blog.Blogpost model
[18:28] <Daviey> As you can see, the blog object has been created in the database
[18:28] <Daviey> you can't see this at the moment, so i'll open up the web interface
[18:28] <Daviey> in order to enable the worst kept secret of django.. we need to open urls.py
[18:28] <Daviey> we need to uncomment:
[18:29] <Daviey> # from django.contrib import admin
[18:29] <Daviey> # admin.autodiscover()
[18:29] <Daviey> (remove the #)
[18:29] <Daviey> and also from the     # (r'^admin/', include(admin.site.urls)),
[18:29] <Daviey> http://pastebin.com/f24559b5f <-- like so
[18:29] <Daviey> now, if people want to log into the admin interface and have a look - log in here
[18:29] <Daviey> http://ubuntu.dev.week.daviey.com:8000/admin/
[18:30] <Daviey> I might add, that i hope i can trust you all not to abuse this :)
[18:30] <Daviey> the username is: dave
[18:30] <Daviey> and the password is: password
[18:30] <Daviey> (secure huh?)
[18:30] <cjohnston> < SmartSsa> Question: I'm seeing some differences in what my django is creating vs. what you're showing. What version are you using and how can I find out what version I'm using?
[18:30] <Daviey> i set that when i first sync'db
[18:31] <Daviey> SmartSsa: What differences are you seeing?
[18:31] <Daviey> dave@boogie:~/django/blogsite$ apt-cache show python-django | grep Version
[18:31] <Daviey> Version: 1.1.1-1ubuntu1
[18:31] <Daviey> That is the one i have installed on this box
[18:32] <Daviey> SmartSsa: if you can list your differences, we'll come back to it if that is ok?
[18:32] <cjohnston>  < SmartSsa> Daviey, I don't have tests.py or the line with 'admin.site.urls' .. i have 'admin.site.root in my urls.py file.
[18:32] <Daviey> cjohnston: Ah, that was a change with 1.1 i believe
[18:33] <cjohnston> < Navaneeth> QUESTION: Django has support for running on a server farm? Like sharing session etc..
[18:33] <Daviey> Are people seeing the webinterface?
[18:35] <Daviey> Okay, i'm running that under the dev server which isn't designed for large use.. so perhaps it may be falling over slightly
[18:36] <Daviey> However, you will see the "Blog" application listed there
[18:36] <Daviey> feel free to "Add blogpost"
[18:36] <Daviey> that luiX_
[18:36] <Daviey> thanks*
[18:37] <Daviey> okay.. hopefully everyone can see the potential of the admin interface
[18:38] <Daviey> Now we need a way to show that to a user, who isn't authenticated
[18:38] <Daviey> we do this via a "view"
[18:38] <Daviey> so in "blogsite/blog/views.py"
[18:38] <Daviey> I'm going to put in a function
[18:39] <cjohnston> < luiX_> QUESTION: Can you filter what apps are showed up to each user or profile in the admin page?
[18:39] <Daviey> http://pastebin.com/f19ccde62
[18:39] <Daviey> luiX_: yes, you can
[18:40] <Daviey> so as you can see, if the function posts() gets called
[18:40] <Daviey> posts = Blogpost.objects.all()
[18:40] <Daviey> Which under the wrappers does a SELECT * FROM blogpost, for example
[18:40] <Daviey> it then pushes the data to a html file that is created called posts.html
[18:41] <Daviey> However, first we need to let the app know how to send a HTTP request there
[18:41] <Daviey> nano blogsite/blog/urls.py
[18:42] <Daviey> http://pastebin.com/f34534c6d <---
[18:42] <Daviey> Everyone following ok?
[18:42] <Daviey> ok
[18:43] <Daviey> so, posts.html is a "template"
[18:43] <Daviey> so lets create a template folder
[18:43] <Daviey> dave@boogie:~/django/blogsite$ mkdir templates
[18:43] <Daviey> and we need to tell the settings where this is
[18:44] <Daviey> TEMPLATE_DIRS needs to have something added
[18:44] <Daviey> to keep things simple:
[18:44] <Daviey> TEMPLATE_DIRS = (
[18:44] <Daviey>     # Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
[18:44] <Daviey>     # Always use forward slashes, even on Windows.
[18:44] <Daviey>     # Don't forget to use absolute paths, not relative paths.
[18:44] <Daviey>    '/home/dave/django/blogsite/templates/',
[18:44] <Daviey> )
[18:44] <Daviey> (you can do clever things such as working from current postion + 'templates'
[18:44] <Daviey> but for this we'll keep it simple
[18:44] <Daviey> adjust the following to what suites your dir layout
[18:46] <Daviey> dave@boogie:~/django/blogsite$ nano templates/posts.html
[18:46] <Daviey> http://pastebin.com/f6a0156a4
[18:46] <Daviey> okay, everyone following ok?
[18:47] <Daviey> Now, lets add an entry to "blogsite/urls.py
[18:47] <Daviey> (r'^', include('blogsite.blog.urls')), <--
[18:47] <Daviey> add it above or below the admin one:
[18:47] <Daviey> (r'^admin/', include(admin.site.urls)),
[18:48] <Daviey> http://pastebin.com/f6f95c0b
[18:48] <Daviey> ^^ urls.py
[18:48] <Daviey> Now, if we do our runserver again
[18:48] <Daviey> ./manage.py runserver
[18:48] <Daviey> we should see: http://ubuntu.dev.week.daviey.com:8000/
[18:49] <Daviey> We have made a simple blog \o/
[18:49] <Daviey> we can add and remove these via http://ubuntu.dev.week.daviey.com:8000/admin/blog/blogpost/
[18:49] <Daviey> I hope everyone is keeping up okay
[18:50] <Daviey> I won't touch on theming today, or any other stuff like that..
[18:50] <Daviey> if we look at our templates/posts.html
[18:50] <Daviey> we can see there is a mini language in itself
[18:50] <Daviey> {% for post in posts %}
[18:50] <Daviey> for loop
[18:51] <Daviey> post.title , post.content <-- this is the models.py we described earlier
[18:51] <Daviey> Everything is an object!
[18:51] <Daviey> Some of the things that makes django particualry cool for us ubuntu folk, is some of the awesome apps we already have
[18:52] <Daviey> It is VERY easy to add openid auth support that uses launchpad for signing in.
[18:52] <Daviey> You can see examples of this in UbuntuOne web interface, UDS planner, and the community created project of http://loco.ubuntu.com
[18:53] <Daviey> Other things that are exciting to us, is that it's python - so we can tie into bzr and things like the launchpad api
[18:53] <Daviey> menaing oru web applicationc an do real time cool stuff.
[18:53] <Daviey> our*
[18:53] <Daviey> I was going to cover django-auth-openid, but i somehow feel that adding things like that right now, might cause people to explode :)
[18:54] <Daviey> Other cool things are deployment methods, such as using fabric, virtualenv and pip
[18:54] <Daviey> Other ways of installing django include pip, this is like easy_install or for the perl types cpan
[18:55] <Daviey> It installs python things, but not necessarily in a clean place
[18:55] <cjohnston> < strycore66> QUESTION : Any good book on Django to suggest ?
[18:55] <Daviey> strycore66: THE best book i would recommend is http://docs.djangoproject.com/en/1.1/
[18:56] <Daviey> the documentation is updated so regulary and there are many tutorials
[18:56] <Daviey> http://www.djangobook.com/ <-- is another good source
[18:56] <cjohnston> < SmartSsa> Question: What's the "Sites" section for in the admin?
[18:56] <Daviey> ^^ that is a real print book, avaliable for no cost online
[18:57] <Daviey> SmartSsa: We can tie projects to a specific site and use that to make a difference.
[18:57] <Daviey> Ie, we could have had 15 different blog sites going there
[18:57] <Daviey> in this instance, we didn't use it
[18:57] <Daviey> Shall i just fall back to questions now, and perhaps have a more advance session another time?
[18:57] <Daviey> Questions?!
[18:58] <cjohnston> < n3rd> QUESTION :How can we use web2.0 like features with this framework
[18:58] <Daviey> n3rd: Django won't make an app look web2.0-y on it's own, you do still need css and javascript.. django can help, but it does help if you have an arty influcence
[18:58] <Daviey> (i odn't)
[18:58] <Daviey> don't*
[18:58] <Daviey> sadly
[18:59] <Daviey> things like plugging into twitter are also easy!
[18:59] <Daviey> next?
[18:59] <cjohnston> That's all that I have for now Daviey
[18:59] <Daviey> okay, i'll end it there
[18:59] <Daviey> but!
[18:59] <Daviey> loco directory (loco.ubuntu.com) is open source
[19:00] <Daviey> If you want to come and help, the water is warm
[19:00] <Daviey> jump in a #ubuntu-locoteam
[19:00] <Daviey> at*
[19:00] <Daviey> Thanks all for listening
[19:00] <Daviey> Next we have kees_lernid for an exciting, and cool subject!
[19:00] <cjohnston> Daviey: #ubuntu-locoteams ?
[19:00] <Daviey> cjohnston: my mistake, yes
[19:01] <cjohnston> :-)
[19:01] <kees> well, just me, not kees_lernid, that's just me following along
[19:01] <kees> Hello!  I'm Kees Cook, an Ubuntu Developer, Security Team member, and Canonical employee.
[19:01] <kees> I'm trying to figure out how to get my slides into lernid...
[19:02] <kees> This presentation is about how to run the development version of Ubuntu (currently Lucid) and how to get yourself out of jams.
[19:02] <kees> The slides I'll be using to keep me on topic come from 2007, and I'll update a few links as I go.
[19:02] <kees> Nearly everything still applies, but just mentally swap in "Lucid" when you see "Gutsy".  :)
[19:03] <kees> They are here: http://outflux.net/ul07/bleeding-edge.pdf (or .odp if you want the raw slides)
[19:03]  * kees attempts to trigger lernid somehow...
[19:03] <kees> [SLIDES: http://outflux.net/ul07/bleeding-edge.pdf]
[19:03] <kees> dang
[19:03] <kees> http://outflux.net/ul07/bleeding-edge.pdf
[19:04] <kees> one moment, trying to get the slides into iCal...
[19:04] <kees> [SLIDE 1]
[19:04] <kees> hrm
[19:06] <kees> okay... so, this should work, or reload lernid:  wget -O $HOME/.cache/lernid/slides.pdf http://outflux.net/ul07/bleeding-edge.pdf
[19:06] <kees> anyway, no more delays.  :)
[19:06] <kees> [SLIDE 1]
[19:06] <kees> The bulk of this content was written by cjwatson; I just cleaned them up.  Blame me for any mistakes, though.  :)
[19:06] <kees> [SLIDE 2]
[19:07] <kees> so, people like running the devel release, but there are a lot of reasons not to
[19:07] <kees> in particular, if you need a new package, and there is no PPA for it, you can just build it on a stable release
[19:07] <kees> the only thing you need to find generally is the ".dsc" file, and "dget" will do the work of fetching it all
[19:08] <kees> in this slide, I show the commands to do a package build; it's a few steps, but it gets it done, and gives you a working package usually.
[19:08] <kees> [SLIDE 3]
[19:08] <kees> now, there are reasons TO run the devel release; and I love having people helping with it.
[19:08] <kees> the biggest reason is helping with development and testing.
[19:09] <kees> it's very hard to do testing without actually running the software you're working on.  :)
[19:09] <kees> generally, though, if you're interested in this topic, you should be running the devel release.  :)
[19:10] <kees> oh! before I forget, please feel free to ask questions with [QUESTION] in the #ubuntu-classroom-chat channel as I go.
[19:10] <kees> [SLIDE 4]
[19:10] <kees> so, we're working on Lucid now, so you'll want https://wiki.ubuntu.com/LucidReleaseSchedule
[19:11] <kees> prior to import freeze, we're pulling in new software versions from Debian daily.
[19:11] <kees> and people are, of course, working on all kinds of fixes and changes.
[19:11] <kees> that said, we stop for regular milestones and release bootable and installable "alpha" liveCDs.
[19:12] <kees> after feature freeze, we try to focus on bug fixing.  with Lucid being an LTS, we're actually trying to focus more on bug fixing than features too.
[19:12] <kees> it's really important to get testing in before the end of this schedule, usually before beta because it's very hard to fix some bugs without enough time to test them.
[19:12] <kees> [SLIDE 5]
[19:14] <kees> given how much the release changes from day to day, it's important to stay updated.  I try to update twice a week.  Others do it multiple times a day.  I would recommend at least once a week.  I find Wed the best time so that if things have gone weird, there are a weekdays left before the weekend to try to get help with fixing stuff.
[19:14] <kees> following that rule, I don't update on fridays.  ;)
[19:14] <kees> please help out with the testing and liveCD testing.  the included links in the slides are good starting points.
[19:14] <kees> [SLIDE 6]
[19:15] <kees> so, the liveCDs are important.  they're the best indicator of what the ubuntu install experience is going to be.
[19:15] <kees> you can also build bootable USB disks from liveCD isos
[19:15] <kees> or, with a VM, you can boot isos for testing.
[19:15] <kees> my favorite for this is testdrive: http://blog.dustinkirkland.com/2009/11/introducing-testdrive.html
[19:16] <kees> it lets you trivially try out an ubuntu image if you don't want to install it or be running the devel release
[19:17] <kees> the USB live disk details are probably best described here: http://en.wikipedia.org/wiki/Ubuntu_Live_USB_creator
[19:17] <kees> [SLIDE 7]
[19:17] <kees> another option is dual-booting, a separate system, etc.
[19:18] <kees> [SLIDE 8]
[19:18] <kees> I'm personally a fan of using VMs.  libvirt and "virt-manager" is my friend.  All my VMs are there, though it does start taking up a fair bit of disk space.
[19:18] <kees> $ du -sh /vm-images/
[19:18] <kees> 84G	/vm-images/
[19:18] <kees> that said, I have amd64 and i386 of every stable release.  :)
[19:19] <kees> [SLIDE 9]
[19:19] <kees> now, with all the focus on install testing, upgrade testing is sometimes overlooked
[19:19] <kees> upgrading a VM from the prior stable release to the devel release needs to be tested often, since there are library changes, package relationship changes, etc, that might need to be manually tweaked by update-manager.
[19:20] <kees> filing bugs about this area is very important.
[19:20] <kees> [SLIDE 10]
[19:20] <kees> the "right" way to do upgrades is with update-manager.
[19:20] <kees> it has additional logic that apt-get and aptitude do not contain.
[19:21] <cjohnston> < strycore66> QUESTION : Is it good practice to keep a pristine VM for bug testing (updated but with no additonal packages or data) ?
[19:21] <kees> if you get into a jam, you may need to using apt-get manually.  After a dist-upgrade, I also usually try an "apt-get install ubuntu-desktop" in case the manual upgrade missed anything
[19:22] <kees> strycore66: so, I try to do both.  A pristine VM is good for being able to compare between version of Ubuntu, for example, but a "messy" VM is good for finding corner-cases, etc.
[19:22] <kees> doing testing on your real system is best because you've customized it, and that's usually where bugs come from.
[19:22] <kees> that said, it's good to start from the same pristine VM when you're trying to reproduce problems, etc.
[19:22] <cjohnston> < alvarezp> QUESTION : What is that additional logic that update-manager provides? What do we miss if we use plain APT tools?
[19:22] <kees> the "virt-clone" command is handy for this.
[19:24] <kees> alvarezp: there are sometimes transititions or file clean ups that are hard to handle strictly in apt.  things I'm thinking of off the top of my head are: old kernel version cleanups, the open-office version bump a while back, stuff like that.
[19:24] <kees> I don't have very good examples, but if you want more, find "mvo" online in #ubuntu-devel later and ask him, he tends to be the person handling those things for update-manager.
[19:24] <kees> [SLIDE 11]
[19:25] <kees> there's a lot that can break...
[19:25] <kees> hopefully the rest of this presentation can help you with those issues
[19:25] <kees> [SLIDE 12]
[19:25] <cjohnston> < n3rd> QUESTION: What if i want to take a tgz of "/" and restore it ?
[19:25] <kees> n3rd: let me answer that in a moment
[19:26] <kees> so, if mirrors blow up, there can be checksum failures.  don't ignore these issues; they're real problems.
[19:26] <kees> wait for the next update push (about an hour usually) and try again
[19:26] <kees> or switch to the non-mirror briefly.
[19:27] <kees> n3rd: you can take tarball snapshots of / if you want.  the main areas of package management are in /var/lib/dpkg and /var/lib/apt
[19:27] <kees> I'll mention those in a moment
[19:27] <kees> [SLIDE 13]
[19:27] <kees> sometimes there are mistakes made when packages take over files from older packages.  all of these glitches need to be reported so they can be fixed.
[19:27] <kees> [SLIDE 14]
[19:28] <kees> you can force installations anyway, but if maintainer scripts misbehave, you'll likely need to debug and edit them by hand
[19:28] <kees> the important bit is /var/lig/dpkg/info/ which contains all the maintainer scripts.
[19:29] <kees> my favorite reference for how maintainer scripts are calls is here: http://women.debian.org/wiki/English/MaintainerScripts
[19:29] <kees> the "Upgrading" diagram is extremely helpful in understanding when/how the scripts are run
[19:29] <kees> [SLIDE 15]
[19:30] <kees> after unpack and install, the postinst runs, and if it blows up, it'll leave the package unconfigured.  you may need to edit it and re-configure.
[19:30] <kees> (again, always file a bug if you run into this kind of thing)
[19:30] <kees> [SLIDE 16]
[19:30] <kees> sometimes debugging maintainer scripts is a pain.
[19:31] <kees> adding a "set -x" to maintainer scripts can help you see what it's trying to do.  some fail very silently, and this is probably the simplest way to get insight into how they're working
[19:31] <kees> [SLIDE 17]
[19:32] <kees> when something goes wrong during interactive questions (debconf), you can enable debugging to see what debconf is up to.
[19:32] <kees> soemtimes a debconf item is misnamed, or wasn't created yet.
[19:32] <kees> these things are also in /var/lib/dpkg/info, with the .config and .template extensions
[19:32] <kees> [SLIDE 18]
[19:33] <kees> in the worst-case situation, maybe dpkg itself is doing something wrong.  in that case, break out the big guns and run dpkg under strace to see all the syscalls.
[19:33] <kees> I like adding "-s 1024" to strace so I can see some more details on "exec" and "open" calls.
[19:34] <kees> dpkg has debugging options too, but they're really only for dpkg itself.
[19:34] <kees> [SLIDE 19]
[19:34] <kees> if you're prompted to remove stuff, just be careful.  :)
[19:34] <kees> if you ever see "essential packages will be removed" just say no.  :)
[19:35] <kees> you will almost always wreck your system and need extensive rescue CD help if you drop essential packages.
[19:36] <kees> I really like "apt-cache policy [packagename]" to tell me about where a package came from, what versions are available, etc
[19:36] <kees> really handy for debugging issues with software from other PPAs, etc
[19:36] <kees> it only looks at your apt sources, which is handy.
[19:37] <kees> another tool I like for undoing insanity is downgrade-all: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/annotate/head%3A/utilities/downgrade-all
[19:37] <kees> this will remove all the third party versions of everything.
[19:37] <kees> use it carefully, but I love it for restoring a system back to a known-good state.  read the downgrade/removal list _carefully_ if you use it.
[19:38] <kees> [SLIDE 20]
[19:38] <kees> if you need to force a removal, you can do that, but it's best to tell apt-get to attempt to get things back to normal afterwards (apt-get -f install)
[19:39] <kees> sometimes 3rd party software can get in the way of an upgrade.  or in the way of a normally operating system.
[19:39] <kees> recently I saw someone trying to run the Debian experimental ifupdown package.  if lacked the needed Ubuntu modifications, so it rendered their networking unusable.
[19:39] <kees> downgrade-all fixed that.  :)
[19:39] <kees> [SLIDE 21]
[19:40] <mhall119|work> < Omar87> [QUESTION] Why do I always get partial upgrades only?
[19:40] <kees> so, if you lose power in the middle of an install, or the system hangs, you'll need to try to get dpkg and apt to finish the job once you're booted back up.
[19:40] <kees> dpkg --configure -a  is the first step to handle any unconfigured packages
[19:41] <kees> and then apt-get -f install  to finish any installations
[19:41] <kees> Omar87: partial upgrades?  if that's from update-manager, it's been conservative about doing package upgrades.  (it was mostly made to handle stable release updates and full-distro-upgrades).  For day-to-day use of the devel release, I recommend just "apt-get dist-upgrade"
[19:42] <kees> if a package is really hosed, you can manually install it with dpkg
[19:42] <kees> if the package _database_ gets hosed, you need to examine /var/lib/dpkg/ and /var/backups
[19:42] <kees> the status and status-old files are imporant.
[19:42] <kees> *important
[19:43] <kees> if "status" is corrupted, try using prior versions in its place (status-old, then stuff in /var/backups)
[19:43] <kees> I've had to manually repair my status file before when XFS tried to eat my harddrive.  it's a bit crazy, but once you have something mostly sane in "status" again, you can just reinstall any weird or missing packages
[19:43] <kees> [SLIDE 22]
[19:44] <kees> if your status file is out of date with what actually got installed, you can look at /var/log/dpkg.log and find the package that were installed since your last good status file.
[19:44] <kees> then you can just do an  apt-get install --reinstall $package   for the stuff that got missed.
[19:45] <kees> when I was trying to restore sanity to a particularly busted machine, I repairs the status file, used downgrade-all, and then did a --reinstall on all the package on the system.
[19:45] <kees> took a while, but it was mostly ok after that.
[19:46] <kees> dpkg-reconfigure is handy too if a question gets missed or corrupted.
[19:46] <kees> [SLIDE 23]
[19:46] <kees> in the case of hardware-specific breakage, it gets harder to have people helping you because they likely don't have your hardware
[19:47] <kees> video and network are the trouble-areas here.
[19:47] <kees> I tend to boot older kernels or try earlier Xorg versions.  sometimes you'll need to help find the problem by "bisecting" a source branch and building several versions of a package.
[19:47] <kees> having a good bug report with all the hardware details helps a great deal.
[19:48] <kees> [SLIDE 24]
[19:48] <kees> when the ABI of a kernel changes, you'll have the older one still installed.  handy to boot from that when a newer kernel breaks something
[19:48] <cjohnston> < rmunn> QUESTION: Any advice on how best to report hardware-related bugs? Specifically, which log file(s) would likely be useful to put in the bug report?
[19:49] <kees> "apport" and the "ubuntu-bug" tools are very handy for reporting all kinds issues, but especially good for the kernel.
[19:49] <kees> rmunn_: answering that now.  :)
[19:49] <kees> running "ubuntu-bug linux" will gather dmesg output, lspci output, etc.
[19:50] <kees> the "ubuntu-bug" tool tries to include everything that is mentioned on the various wiki pages for Debuging____
[19:50] <kees> dmesg and lspci tends to be the most important pieces
[19:50] <kees> we also have the kerneloops handler too.
[19:50] <kees> [SLIDE 25]
[19:51] <kees> when X breaks, it's time to start including all sorts of logs.  again. ubuntu-bug is your friend.  :)  "ubuntu-bug xorg-server" will tend to collect many of the needed pieces
[19:51] <kees> falling back to VESA can help get you back up and running in the meantime.  /var/log/gdm may have clues
[19:52] <cjohnston> < n3rd> QUESTION:xorg.conf why no such file in Karmic ? And is there any open drivers for ATI Technologies Inc Radeon HD 3200 Graphics?
[19:52] <kees> [SLIDE 26]
[19:52] <kees> this slide is out of date.  NetworkManager is in /etc/init now, so "service network-manager stop" is the way to disable it
[19:53] <kees> configuration in /etc/networking/interfaces is used by the "networking", "networkinger-interface", and "network-manager" services, so it's the best place to start.
[19:53] <kees> also, network names are remembered in /etc/udev/rules.d/70-persistent-net.rules
[19:54] <kees> n3rd: xorg.conf isn't really needed any more because X can autodetect almost everything now.
[19:54] <kees> having an xorg.conf almost always causes X to misdetect stuff, so instead, it's just been removed.
[19:54] <kees> [SLIDE 27]
[19:54] <cjohnston> < rmunn> QUESTION: I've had a hard time finding good documentation on network-manager and how it relates to (say) /etc/network/interfaces and the like. Any recommended reading?
[19:55] <kees> in a really tight pinch, you can get into your system by changing the grub boot line to init=/bin/sh or by adding "break=mount" to land in the initramfs to debug issues with booting
[19:55] <kees> I got very familiar with this while debugging RAID and LVM support :)
[19:56] <kees> rmunn: the problem with network-manager is that its integration with Debian-like systems has always been troublesome.  each release it behaves slightly differently, which makes good documentation hard to find.  :(
[19:57] <kees> I recommend asking "asac" in #ubuntu-devel, but hopefully it's mostly settled now.  I _think_ n-m will only manage stuff that is "auto" in /etc/network/interfaces
[19:57] <kees> (or missing from interfaces)
[19:57] <kees> [SLIDE 28]
[19:57] <kees> if you're running devel on a remote machine, you're in for a world of hurt if it doesn't boot :)  be careful, get a console server, etc.
[19:57] <kees> [SLIDE 29]
[19:58] <kees> here's where to report bugs.  start with "ubuntu-bug $Package" first, and go from there.
[19:58] <kees> [SLIDE 30]
[19:58] <kees> that's it from me!
[19:58] <cjohnston> < Guillo> QUESTION: What hapen with python-xml this librari don't install?
[19:58] <kees> I've only got 2 minutes left, but I'll try to answer that
[19:59] <kees> Guillo: I'd start my investigations by looking at what apt-cache has to say.  here's a quick demo:
[19:59] <kees> $ apt-cache madison python-xml
[19:59] <kees> and I see it's missing.
[19:59] <kees> then I go to launchpad and look for it:
[20:00] <kees> https://launchpad.net/ubuntu/+source/python-xml
[20:00] <kees> I see it's missing since karmic
[20:00] <kees> then I check Debian for it:
[20:00] <kees> http://packages.qa.debian.org/p/python-xml.html
[20:00] <kees> I see it was removed.
[20:01] <kees> and then I read the Debian reasoning for it.
[20:01] <kees> gotta go!  thanks everyone!
[20:02] <mathiaz> allright - let's keep the ball rolling
[20:02] <mathiaz> kees: thanks for your presentation
[20:03] <mathiaz> Hello everyone!
[20:03] <mathiaz> My name is Mathias Gug and am part of the Ubuntu Server team:
[20:03] <mathiaz> https://wiki.ubuntu.com/ServerTeam
[20:03] <mathiaz> During the next (and final) hour of today's Ubuntu Developer week I'll talk about Server related packages.
[20:04] <mathiaz> These are packages that usually provide services running in the background as daemon. They should be operating smoothly unattended by the system administrator.
[20:04] <mathiaz> I'll cover different topics relevant to server packages. I'll answer any questio
[20:04] <mathiaz> ns on the topic after I've covered it before moving on to the next one.
[20:05] <mathiaz> let's get started with the first topic:
[20:05] <mathiaz> Log files
[20:06] <mathiaz> The location of log files should be /var/log/package.log or /var/log/package/.
[20:06] <mathiaz> The latter version is more frequent for daemons as log files are essential for these programs and multiple logs files are usually created.
[20:07] <mathiaz> For example the apache2 package stores all its log files in /var/log/apache2/:
[20:07] <mathiaz> The access logs are available in one file while the error log is stored in another one.
[20:08] <mathiaz> The Filesystem Hierarchy Standard is followed by Debian and Ubuntu and has a section about the location about log files:
[20:08] <mathiaz> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOGLOGFILESANDDIRECTORIES
[20:08] <mathiaz> Since daemons can generate a lot of information while running rotating the logs are important.
[20:09] <mathiaz> The package maintainer should provide a default log rotation policy during package installation.
[20:09] <mathiaz> Some daemons will take care of rotating their logs automatically. Most of them won't though.
[20:10] <mathiaz> The recommended way is to include a configuration file for logrorate.
[20:10] <mathiaz> Let's have a look at the apache2 default logrotate configuration:
[20:10] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/apache2/lucid/annotate/head%3A/debian/logrotate
[20:11] <mathiaz> Note that apache2 is reloaded once log files have been rotated. This is a common operation for daemons as they tend to keep their log files opened and need to be told to reopen their log files once logrotate has rotated them.
[20:12] <mathiaz> The logrotate configuration file should be installed as /etc/logrotate.d/package-name:
[20:12] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/apache2/lucid/annotate/head%3A/debian/rules#L265
[20:12] <mathiaz> There is a debhelper command that can help automate this: dh_installlogrotate
[20:12] <mathiaz> The logrotate man page has more information about the options for log rotation.
[20:13] <mathiaz> Log directories are usually included in the package themselves.
[20:13] <mathiaz> For example, /var/log/apache2/ is part of the apache2-common package:
[20:13] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/apache2/lucid/annotate/head%3A/debian/apache2.2-common.dirs
[20:14] <mathiaz> However they often need to be changed by maintainer scripts:
[20:14] <mathiaz> In the postinst, ownership and permissions are updated since daemons usually run as a non-root user:
[20:14] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/apache2/lucid/annotate/head%3A/debian/apache2.2-common.postinst#L18
[20:14] <mathiaz> Log files should also be deleted with the package is purged:
[20:15] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/apache2/lucid/annotate/head%3A/debian/apache2.2-common.postrm#L8
[20:15] <mathiaz> More information about log files can be found in the relevant section of the Debian policy:
[20:15] <mathiaz> http://www.debian.org/doc/debian-policy/ch-files.html#s10.8
[20:15] <mathiaz> Any questions related to log files?
[20:16] <cjohnston> < toabctl_> mathiaz, QUESTION: but the apache2 package does not use the dh_installlogrotate command, right?
[20:16] <mathiaz> toabctl_: yes - that is correct
[20:16] <cjohnston> < n3rd> QUESTION: Is there a mechanism to replicate server configurations from one machine to another, helps in avoiding reinstalling and setting up all the parameters, for example a machine had
[20:16] <mathiaz> toabctl_: if it would, it would be done in the debian/rules file
[20:16] <cjohnston>               apache configured with bug tracking system, SCM etc, the same needs to be setup in another machine so it would be easy if we could just replicate the same.
[20:16] <cjohnston> sorry...
[20:17] <mathiaz> n3rd: this is a more generic question - related to configuration management system
[20:17] <mathiaz> n3rd: I'd look into things like puppet, chef or cfengine
[20:17] <mathiaz> cjohnston: next
[20:17] <cjohnston> < toabctl_> QUESTION: does debhelper provide more function to take care for logfile handling? for example package purge..
[20:18] <mathiaz> toabctl_: I don't think so
[20:18] <mathiaz> anything other questions related to log files before we move on?
[20:19] <cjohnston> That looks like it. :-)
[20:19] <mathiaz> nope - let's move on to the next topic then:
[20:19] <mathiaz> Configuration files
[20:19] <mathiaz> Dealing with configuration files should be guided by the following principles:
[20:19] <mathiaz> 1. Keep the user modification during upgrades
[20:20] <mathiaz> 2. Have a default working configuration after package install
[20:20] <mathiaz> Per the Debian Policy:
[20:20] <mathiaz> A configuration file """affects the operation of a program, or provides site- or host-specific information, or otherwise customizes the behavior of a program. Typically, configuration files are intended to be modified by the system administrator (if needed or desired) to conform to local policy or to provide more useful site-specific behavior."""
[20:20] <mathiaz> http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
[20:21] <mathiaz> All configuration files must reside in /etc/.
[20:21] <mathiaz> Configuration files must only be removed on package *purge*, not on package *removal*.
[20:21] <mathiaz> Packages should not modify configuration files belonging to other packages.
[20:22] <mathiaz> In order to have a working configuration file by default the package can either ship a default configuration file or generate one during installation by asking questions to the user.
[20:22] <mathiaz> The first option should be used if possible. Shipping a default configuration file as part of the package itself under /etc/ is the easiest way.
[20:22] <mathiaz> Files will be considered as conffile by dpkg which will handle them for you during package upgrades.
[20:23] <mathiaz> This is appropriate only if it is possible to distribute a default version that will work for most installations, although some system administrators may choose to modify it.
[20:23] <mathiaz> This implies that the default version will be part of the package distribution, and must not be modified by the maintainer scripts during installation (or at any other time).
[20:23] <mathiaz> For example /etc/apache2/apache2.conf is a conffile:
[20:24] <mathiaz> http://packages.ubuntu.com/lucid/amd64/apache2.2-common/filelist
[20:24] <mathiaz> It's installed during the package build via a rule:
[20:24] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/apache2/lucid/annotate/head%3A/debian/rules#L264
[20:24] <mathiaz> The other solution to provide a default working configuration file is to generate a valid one during package installation.
[20:25] <mathiaz> Various maintainer scripts are used to ask questions to the end user (optional) and then create a configuration file.
[20:25] <mathiaz> They will also handle all configuration changes during package upgrade.
[20:25] <mathiaz> One option is to generate the configuration file directly in the postinst script as done by the openssh-server package:
[20:25] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/openssh/lucid/annotate/head%3A/debian/openssh-server.postinst#L295
[20:26] <mathiaz> Quite often this is combined with debconf questions.
[20:26] <mathiaz> The user is asked for information by the package .config script. The postinst script generates the configuration file according to the user answers.
[20:27] <mathiaz> Another great practice for configuration is the use of /etc/package.d/ include directories.
[20:27] <mathiaz> If the program supports configuration file inclusion I strongly recommend to ship a default file that include a /etc/package.d/ directory.
[20:27] <mathiaz> That often helps other packages to integrate with your program by dropping their own configuration file in the /etc/package.d/ directory.
[20:27] <mathiaz> For example apache2 includes a configuration directory in its default configuration file:
[20:27] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/apache2/lucid/annotate/head%3A/debian/config-dir/apache2.conf#L232
[20:28] <mathiaz> The apache2 package actually provides multiple .d directories:
[20:28] <mathiaz> A conf.d for generic options:
[20:28] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/apache2/lucid/files/head%3A/debian/config-dir/conf.d/
[20:28] <mathiaz> A modules.d (called mods-available) to enable specific modules:
[20:28] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/apache2/lucid/files/head%3A/debian/config-dir/mods-available/
[20:29] <mathiaz> Thanks to this directory packages providing a specific apache2 modules can just ship a configuration file in /etc/apache2/mods-available/. There is no need to edit a configuration file.
[20:29] <mathiaz> A sites.d (called sites-available) to manage virtual hosts:
[20:29] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/apache2/lucid/files/head%3A/debian/config-dir/sites-available/
[20:29] <mathiaz> This is more targeted at sysadmin rather than package maintainers.
[20:30] <mathiaz> The apache2 package is a great example to look at how a package can provide the infrastructure to help other packages integrated with it.
[20:30] <mathiaz> More detailed about configuration files handling can be found in the Debian policy:
[20:30] <mathiaz> http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
[20:30] <mathiaz> For more information about Debconf:
[20:30] <mathiaz> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-config-mgmt
[20:30] <mathiaz> Any questions related to configuration files?
[20:31] <mathiaz> QUESTION: how to handle a file which is needed in the directory /usr/share/pyshared/testprogram/settings.py ? just add a symlink from /usr/share/pyshared/testprogram to /etc/testprogram/settings.py ?
[20:32] <mathiaz> toabctl_: yes - that usually how things should be done
[20:32] <mathiaz> toabctl_: all configuration files should be in /etc/
[20:32] <cjohnston> < n3rd> Q: how can i avoid trailing slashes in conf files
[20:33] <mathiaz> toabctl_: if programs are not able to handle, that it's advised to use symlink from /etc/ to the expected location
[20:33] <mathiaz> n3rd: I'm not sure I understand your question
[20:33] <cjohnston> < n3rd> Q: why some refer to httpd.conf and some to apache.conf, how exactly they work?
[20:34] <mathiaz> n3rd: this is specific to how apache2 is working
[20:34] <mathiaz> n3rd: IIRC httpd.conf is around for historical reasons
[20:34] <mathiaz> n3rd: apache.conf should include httpd.conf
[20:35] <cjohnston> < n3rd> Question : instead of localhost/test, how can i configure apache2 to point localhost:port to test dir in /var/www
[20:35] <mathiaz> n3rd: that's a support question for apache2 - I won't address it here
[20:35] <mathiaz> n3rd: I'd suggest to ask the question in #ubuntu-server
[20:36] <mathiaz> I think that's all for this topic - let'sm ove on
[20:36] <mathiaz> next topic: Upstart job
[20:36] <mathiaz> The init script subsystem in Ubuntu has seen a lot of activity in the past releases as we're moving more and more to upstart jobs.
[20:36] <mathiaz> I'll give an overview on some features from upstart that are very helpful in managing daemons.
[20:37] <mathiaz> Upstart is able to supervise services: if a process dies Upstart can be configured to restart it.
[20:37] <mathiaz> For example, the openssh-server upstart job:
[20:37] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/openssh/lucid/annotate/head%3A/debian/openssh-server.upstart
[20:37] <mathiaz> Using the respawn keywork instructs upstart to restart the sshd process if it disappears:
[20:38] <mathiaz> Line11
[20:38] <mathiaz> Upstart also supports forking daemons and will supervise them correctly:
[20:38] <mathiaz> Line10
[20:38] <mathiaz> Some daemons could also be run in the foreground by upstart:
[20:38] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/eucalyptus/lucid/annotate/head%3A/debian/eucalyptus-cc.upstart#L56
[20:38] <mathiaz> Another strength of Upstart is its dependency system. If a service is restarted other daemons may need to be restarted as well.
[20:39] <mathiaz> For example if the portmap service is restarted, gssd and statd will automatically be restarted by upstart as well:
[20:39] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/nfs-utils/lucid/annotate/head%3A/debian/nfs-common.gssd.upstart#L9
[20:39] <mathiaz> Upstart has built-in support for oom handling:
[20:39] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/openssh/lucid/annotate/head%3A/debian/openssh-server.upstart#L14
[20:39] <mathiaz> Other features include nicing  and setting limits. See init(5) manpage for more information.
[20:40] <mathiaz> Traditionally daemon init scripts would source /etc/default/servicename. The default file provides an easy way to customize major options for the system administrator.
[20:40] <mathiaz> In Upstart it's suggested to modify directly the upstart job instead.
[20:40] <mathiaz> Upstart jobs should be defined in debian/package.upstart. They will be automatically handled by the relevant debhelper scripts (such dh_installinit).
[20:41] <mathiaz> More information can be found in the init(5) manpage  and the Debian policy.
[20:41] <mathiaz> And don't forget the upstart website at:
[20:41] <mathiaz> http://upstart.ubuntu.com/
[20:42] <mathiaz> Any question related to upstart?
[20:43] <cjohnston> < bullgard> QUESTION: What do you mean by "service" here?
[20:43] <mathiaz> bullgard: I think this has already been well answered in -chat
[20:44] <cjohnston> That's all I see
[20:44] <mathiaz> rmunn_: thanks
[20:44] <cjohnston> < zul> QUESTION: when would you use fork and when would you use daemon?
[20:44] <mathiaz> zul: not sure
[20:45] <cjohnston> < rmunn> QUESTION re upstart: How difficult is a typical init-to-upstart conversion? E.g., if I have a package using init scripts, is it usually worth the effort of rewriting its init scripts to use
[20:45] <cjohnston>                upstart instead? How much is gained to offset the cost of the rewrite?
[20:45] <mathiaz> rmunn_: it depends on complex the init script is
[20:46] <mathiaz> rmunn_: usually it's worth the effort - as there is bunch of new features that upstart handles automatically for you
[20:46] <mathiaz> rmunn_: and if you do a lot of funky stuff in the init script (like modify configuration files), you can just use the same code in the pre/post-script stanzy in the upstart job
[20:46] <mathiaz> rmunn_: so quite often you can just copy and paste the code
[20:47] <mathiaz> all right - let's move on
[20:47] <mathiaz> Next topic: UFW profile
[20:47] <mathiaz> The security team wrote a simple host-based firewall tool named UFW:
[20:47] <mathiaz> https://wiki.ubuntu.com/UncomplicatedFirewall
[20:47] <mathiaz> Package integration is now available by dropping a file in /etc/ufw/applications.d/ to tell ufw how to configure firewalling rules for the services.
[20:47] <mathiaz> For example here is openssh-server ufw profile:
[20:47] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/openssh/lucid/annotate/head%3A/debian/openssh-server.ufw.profile
[20:48] <mathiaz> And how to install it during the package build:
[20:48] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/openssh/lucid/annotate/head%3A/debian/rules#L198
[20:48] <mathiaz> For more information see the ufw wiki page at:
[20:48] <mathiaz> https://wiki.ubuntu.com/UncomplicatedFirewall
[20:49] <mathiaz> any question related to UFW?
[20:50] <cjohnston> None seen
[20:50] <mathiaz> allright then - let's move on
[20:50] <mathiaz> Next topic: AppArmor profile
[20:50] <mathiaz> Another tool that the security team is maintaining and the proves to be useful for services is AppArmor.
[20:50] <mathiaz> It can be seen as an alternative to chroots for daemons.
[20:51] <mathiaz> For example here is the ntp apparmor profile:
[20:51] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/ntp/lucid/annotate/head%3A/debian/apparmor-profile
[20:51] <mathiaz> It should be installed in /etc/apparmor.d/path.to.daemon.binary:
[20:51] <mathiaz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/ntp/lucid/annotate/head%3A/debian/rules#L72
[20:51] <mathiaz> Some care needs to be taken during package upgrade especially when a new profile is introduced as we don't want to break existing systems.
[20:52] <mathiaz> More information about migrating a profile can be found on the wiki page:
[20:52] <mathiaz> https://wiki.ubuntu.com/ApparmorProfileMigration
[20:52] <mathiaz> And you can find more info on the AppArmor wiki page:
[20:53] <mathiaz> https://wiki.ubuntu.com/AppArmor
[20:53] <mathiaz> any question related to AppArmor profiles?
[20:53] <cjohnston> None seen
[20:54] <mathiaz> ok - let's move on
[20:54] <mathiaz> next topic: system users
[20:54] <mathiaz> One of the Ubuntu goal is to try to run as many daemons as possible as non-root users.
[20:54] <mathiaz> That brings the need to create system users. The best practice is to not delete users on package purge. Otherwise the uid could be reallocated, potentially giving access to files from the previous package to the new program.
[20:55] <mathiaz> For example the openssh-server postinst creates the ssshd user if the user doesn't already exists:
[20:55] <mathiaz> http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/openssh/lucid/annotate/head%3A/debian/openssh-server.postinst#L401
[20:55] <mathiaz> If the daemon requires to be run as root try to write an AppArmor profile for it.
[20:56] <mathiaz> More information about system users can be found in the Debian policy:
[20:56] <mathiaz> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2
[20:56] <mathiaz> Any question related to system users?
[20:57] <mathiaz> nope - let's move on then
[20:57] <mathiaz> Next topic: Cron jobs
[20:57] <mathiaz> Cron jobs should installed in /etc/cron.d/ or any of the regular cron directory (ex: /etc/cron.daily/).
[20:58] <mathiaz> There is a debhelper script available for packager: dh_installcron.
[20:58] <mathiaz> The Debian policy has more information:
[20:58] <mathiaz> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.5
[20:58] <mathiaz> Any questions related to cron jobs?
[20:59] <cjohnston> None seen...
[20:59] <mathiaz> allrigh then
[20:59] <mathiaz> that's all for now then
[20:59] <mathiaz> you can find more information in the following guides:
[20:59] <mathiaz>  * Debian policy: - http://www.debian.org/doc/debian-policy/ - debian-policy package
[20:59] <mathiaz>  * Debian Developer's Reference: - http://www.debian.org/doc/manuals/developers-reference/index.en.html
[20:59] <mathiaz>  * Debian New Maintainers' Guide: - http://www.debian.org/doc/manuals/maint-guide/index.en.html
[20:59] <mathiaz>  * Ubuntu Policy: - ubuntu-policy package
[21:00] <mathiaz>  * Ubuntu Package Guide: - https://wiki.ubuntu.com/PackagingGuide/
[21:00] <mathiaz>  * Mailing lists and IRC channels: - ubuntu-devel@, ubuntu-server@ - #ubuntu-devel, #ubuntu-server
[21:00] <mathiaz>  * Ubuntu wiki: - https://wiki.ubuntu.com
[21:00] <mathiaz> And one last page that I often use when I have my packager hat:
[21:00] <mathiaz> http://women.debian.org/wiki/English/MaintainerScripts
[21:00] <mathiaz> this one outlines the sequence in which maintainer scripts are called
[21:01] <mathiaz> and with that the first day of the Ubuntu Developer Week is ending
[21:01] <mathiaz> come back for more tomorrow, same place at 16:00 UTC
[21:02] <mathiaz> you'll learn about java libraries, ubuntu one support, automated server testing and other things
[21:02] <mathiaz> https://wiki.ubuntu.com/UbuntuDeveloperWeek/
[21:02] <mathiaz> thanks all and bye!
[21:37] <davidboy>  
[22:43] <rzanebr10> já começou a aula
[22:44] <rzanebr10> oi
[22:45] <rzanebr10> oi
[22:46] <rzanebr10> alguem sabe das aulas do ubuntu???
[22:46] <IdleOne> !br
[22:48] <rzanebr10> IdleOne: There is no problem if I need to talk in english
[22:48] <rzanebr10> ubottu: it is ok if it is talking in english
[22:50] <IdleOne> rzanebr10: this channel is not fir support
[22:50] <IdleOne> for*
[22:50] <rzanebr10> não entendi/
[22:50] <rzanebr10> ?
[22:51] <IdleOne> por eso que te dijo de usar #ubuntu-br
[22:52] <rzanebr10> mas as aulas são neste canal, sim ou não?
[22:52] <IdleOne> nao
[22:52] <rzanebr10> IdleOne: então veja: http://www.ubuntu-sp.org/
[22:54] <rzanebr10> e no me deixes olvidar
[22:55] <IdleOne> rzanebr10: I don't speak portuguese please type /join #ubuntu-br for more help
[22:55] <rzanebr10> ok
[22:55] <IdleOne> thank you :)
[22:55] <rzanebr10> no problem, we can share ideas about ubuntu in english
[22:56] <rzanebr10> or in spanish!!!
[22:56] <IdleOne> rzanebr10: I am going to have dinner but if you would like to chat there is also #ubuntu-offtopic (english only )
[23:03] <mercutio22> rzanebr10: E ae, oque tá acontecendo?
[23:14] <mhall119> test
[23:14] <paultag> FAIL
[23:14] <paultag> howdy mhall119
[23:14] <mhall119> not this time!
[23:14] <mhall119> hiya pak33m
[23:14] <mhall119> bah
[23:14] <mhall119> paultag,
[23:14] <paultag> haha
[23:15] <mhall119> I really wish I could use lernid at work, there's gotta be a way...
[23:50] <athanacius> ñ