[03:51] <dbuiviet> what's on Ubuntu Open Week this week? :-)
[03:58] <dbuiviet> what's on Ubuntu Open Week this week? :-)
[04:00] <nalioth> dbuiviet: the /topic exists for your infomation
[04:02] <dbuiviet> @nalioth: thanks
[05:12] <wissler> hi
[05:12] <wissler> is anyone here
[05:17] <seravitae> hi
[05:18] <oly562> hello :)
[05:20] <seravitae> Flannel - okay so my previous issue is this. i installed egroupware and it worked fine, except the db messed up somehow so i went to uninstall it. it wouldn't uninstall (because i didnt know about purge). so right now ive tried to remove *everything*, by doing aptitude purge apache2 egroupware php5
[05:20] <seravitae> which works
[05:20] <seravitae> yet apache doesnt remove, and it's still running, for starters.
[05:20] <seravitae> so purge isn't working?
[05:21] <Flannel> seravitae: apache2 includes apache2.2-common, apache2-mpm-worer
[05:21] <seravitae> how come purging doesnt purge  dependancies?
[05:21] <Flannel> seravitae: "apache2" isn't quite a metapackage, but it certainly acts that way for a good portion of "apache"
[05:21] <seravitae> ah.
[05:21] <Flannel> seravitae: Because that would also purge stuff like libc, etc.
[05:22] <seravitae> right
[05:22] <seravitae> okay ive purged that too
[05:22] <seravitae> so to install egroupware i should now do aptitude install apache2 php5 egroupware
[05:23] <seravitae> at this point with egroupware purged, /etc/egroupware still exists and is populated btw
[05:23] <Flannel> seravitae: Are you sure you got all of the groupware stuff?  What particular config files did you delete?
[05:24] <oly562> :|
[05:24] <seravitae> well, ive only ever removed/purged the package, so i think the package is missing deleting some config
[05:24] <Flannel> seravitae: How did you lose your original apache config?
[05:25] <seravitae> to be honest im not sure. trying to get egroupware reinstalled (with full deletion of its configs)
[05:25] <Flannel> seravitae: Alright.  Well, go ahead and do this then: dpkg -S /etc/egroupware
[05:26] <Flannel> seravitae: that should list all the packages that have put something in that directory, so you can purge them
[05:27] <seravitae> k nothings left
[05:27] <Flannel> seravitae: alright, go ahead and reinstall egroupware and apache then.
[05:28] <seravitae> ok
[05:28] <seravitae> packages install fine, apache comes up
[05:28] <seravitae> but egroupware fails silently. the packages install but usually it comes up with a setup program
[05:28] <seravitae> and myserver/egroupware 404's
[05:29] <Flannel> seravitae: I've never used egroupware, have you looked in the DEBIAN.Readme file?
[05:29] <Flannel> seravitae: It normally does that on Ubuntu? or in other distros?
[05:30] <seravitae> it did it this morning when i installed it for the first time, now it doesnt
[05:30] <seravitae> http://ubuntuforums.org/showthread.php?t=373644 <-- that is what im experiencing, with possible solution,
[05:31] <Flannel> seravitae: Do you have libapache2-mod-php5 installed?
[05:32] <seravitae> yep
[05:33] <seravitae> doing a force-reload on apache2 shows apache2: Syntax error on line 295 of /etc/apache2/apache2.conf: Could not open configuration file /etc/apache2/conf.d/egroupware: No such file or directory
[05:33] <seravitae>    ...fail!
[05:33] <seravitae> do i need to make a link?
[05:33] <Flannel> Ah, there you go.
[05:33] <Flannel> Um, check the README.Debian file, see what it says.
[05:33] <seravitae> ok
[05:35] <seravitae> didn't help. it talks about changing the yourhostname/egroupware/ path in /etc/egroupware/apache.conf
[05:36] <seravitae> /etc/egroupware exists, but it's empty.
[05:36] <Flannel> seravitae: You might be able to get more help in #ubuntu-server, someone who's familiar with egroupware should be able to sort it out pretty quickly.
[05:36] <seravitae> ok, ill try there, thanks :)
[05:43] <seravitae> Flannel: ps, i really think the issue is that even after purging the package, it doesn't ever reload the setup script, whihc i bet creates the apache.conf file.
[05:45] <Flannel> seravitae: that means you're not getting rid of the 'right' package (the one that handles the set up script, whether the file itself, or in post-install), *or* theres some other flag being set which is causnig the setup to not run
[06:50] <irish> hi
[06:51] <irish> Could somebody explain why when I connect my Olympus Sp510 photocam via USB it doesn't automounts ?
[06:53] <irish> The device suddenly appears in dev like /dev/sdb and /dev/sdb1 the kde says: whow! I've found your Cam! Then dolphin says: no such device :(
[06:54] <irish> when I try to look at /dev/ there is no more /dev/sdb
[06:55] <irish> BUT! If hal daemon is stopped device is still present and I can mount it by hands. But it is not so comfortable to stop hal and mount using console command
[06:57] <xHans> irish: try asking in #ubuntu or #kde, I think this channel is just for this week's conference/classes
[06:58] <xHans> check to see if it shows up in /proc/scsi/scsi, but that's the only suggestion I have and it's not terribly useful :)
[07:08] <irish>  xHans: thanks, i'll try! have a nice week!
[07:12] <xHans> bitte
[09:18] <isimluk> hi all
[09:27] <sub> :9
[11:11] <kod65> hello
[11:25] <Frippe>  /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS 
[11:31] <tuspak> hi
[12:09] <geNx> when its begin?
[12:11] <ys76> geNx: https://wiki.ubuntu.com/UbuntuDeveloperWeek
[12:21] <Lops88> salve a tutti
[13:05] <Lops88> ma dov'è la conferenza ?
[13:14] <almighurt> Lops88: https://wiki.ubuntu.com/UbuntuOpenWeek
[13:16] <hethi> /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[13:36] <NexusGS> ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[13:37] <NexusGS> hi all
[13:38] <isk> ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[13:38] <afro22> what utc time is it?
[13:38] <nuvolari> 13:38
[13:39] <afro22> thx
[13:39] <nuvolari> np
[13:39] <jrib> ignore #ubuntu-classroom FAILED_IGNORES
[13:59] <Lops88> ma è qui?..se è sei nn dovrebbe essere gia iniziato?
[14:01] <Tolchi> 14:00 UTC now... 1 hour to go.... still
[14:01] <x_dimitri> yay
[14:02] <remfarkas> patiente is a great feature in life ^^
[14:03] <Lops88> ok thx
[14:05] <milos_> Omg, I'm so nervous.
[14:06] <esters> milos_: Why ?
[14:06] <stefanlsd> nervous or excited?
[14:06] <milos_> My first time, yeah excited :)
[14:07] <esters> Like loosing your geek virginity :)
[14:07] <milos_> hhh
[14:08] <stefanlsd> milos_, oh yeah. its great. it can be long thou, so dont worry bout having to miss some and read the logs online later.
[14:09] <milos_> yeah, great everything is logged
[14:12] <weboide> is it legally possible to reuse the channel logs, modify them and post it on a website for example? or there is privacy/licence problem?
[14:13] <jrib> weboide: "The content of all Ubuntu channels, whether official logs or otherwise, are considered to be in the public domain" https://help.ubuntu.com/community/InternetRelayChat
[14:14] <weboide> okay, so i could reuse them, and just tell i got it from #ubuntu-classroom at freenode.
[14:15] <jrib> weboide: sure, that sounds fine
[14:15] <snuxoll> did you not read 'public domain' ?
[14:15] <snuxoll> no need to say where they were from, even
[14:15] <weboide> Well i want people to know about the ubuntu-classroom anyway ; )
[14:16] <weboide> I might make something like a sum up of some classes, and post it on my website, and tell that they can visit #ubuntu-classroom if they want to participate
[14:19] <weboide> thanks for your help jrib and snuxoll  : )
[14:19] <snuxoll> :)
[14:34] <nuvolari> hey morgs
[14:35] <morgs> hey nuvolari!
[14:35] <nuvolari> morgs: i think i studied enough for today... so i might sit in a couple of sessions here :P
[14:35] <morgs> :)
[14:37] <matthewi>  /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[14:38] <djiezes> classroom starts in 20 minutes, right?
[14:38] <milos_> djiezes, yup
[14:38] <djiezes> okay, thanks. just making sure with the timetable and all.
[14:38] <Odd-rationale> what's the question room again?
[14:39] <esters> See the topic Odd-rationale ;)
[14:40] <manolis> today is the big day?
[14:40] <djiezes> I'm reading up on this: https://wiki.ubuntu.com/Classroom/Guidelines
[14:40] <matthewi>  /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[14:40] <Fierelin> no, 6th nov will be
[14:40] <esters> Maybe
[14:40] <esters> Ya, when Mark shows up :)
[14:40] <Odd-rationale> matthewi: you need to take out the space in front...
[14:41] <manolis> thx
[14:41] <matthewi> thx
[14:42] <zever>  /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[14:42] <Lapaj> ﻿/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[14:42] <zever> that doesn't work
[14:42] <Odd-rationale> Lapaj: take out the space in front..
[14:42] <Lapaj> oh sorry
[14:43] <Odd-rationale> oops.. zever i meant...
[14:43] <zever> Odd-rationale: done, but then whole channel gets ignored
[14:43] <Fierelin> zever, except normal talk
[14:44] <zever> hmm, let's see
[14:44] <afro22> ﻿﻿/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[14:45] <zever> ok, xchat gave misleading information: #ubuntu-classroom added to ignorelist
[14:45] <djiezes> it'd be great if we could ignore the wrongly typed /ignore messages ;)
[14:46] <manolis> how many users will come?
[14:46] <Maurici1> Hello good morining for all
[14:47] <Fierelin> manolis, perhaps "more than nine thousands" ) not known exactly
[14:48] <snuxoll> if users_coming > 900: party
[14:49] <Odd-rationale> i edited the wiki page to take out the traailing space in the /ignore .... command...
[14:49] <djiezes> so, for clarity, if we have a question, we pose that in #ubuntu-classroom-chat , with the prefix "QUESTION: ... " ? right?
[14:49] <Odd-rationale> *leading space
[14:49] <weboide> Odd-rationale: can you give a link to that wiki ?
[14:50] <Odd-rationale> weboide: https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn
[14:50] <weboide> Odd-rationale: thx
[14:51] <Lapaj> ﻿/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[14:57] <tuspak> hi
[14:57] <telebovich1> ;-)
[15:01] <Tolchi> ???
[15:01] <Tolchi> ???
[15:07] <isk> test
[15:08] <djiezes> i hear you isk ;)
[15:08] <esters> 1..2..3
[15:08] <tuspak> :)
[15:09] <jcastro> Welcome everyone
[15:09] <jcastro> Straightening a few things out on our end, we'll begin shortly!
[15:10] <esters> \o/
[15:10] <Fierelin> old classic netsplit )
[15:10] <snuxoll> where would we be without them?
[15:10] <Slugg> /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[15:10] <snuxoll> oh, right
[15:11] <Maurici1> Ok, jcastro...I still on line
[15:12] <jono> hi all!
[15:12] <BB-wolf> hi jono
[15:12] <Tech00> morning *sips coffee*
[15:12] <rgreening> o/
[15:12] <jono> sorry I am a little late
[15:12] <jono> hope everyone is great today
[15:13] <dholbach> everybody hug Jono!
[15:13] <jono> all set for he greatness that is Ubuntu Open Week?
[15:13]  * dholbach hugs jono :-)
[15:13]  * lool hugs jono
[15:13] <Tech00> *hugs Jono*
[15:13]  * techno_freak hugs jono 
[15:13] <isk> where is the chat room to be found, plz
[15:14] <jono> ok, welcome to Ubuntu Open Week -  a week of tuition sessions about how to get involved in the Ubuntu community
[15:14] <jcastro> isk: #ubuntu-classroom-chat
[15:14] <jono> the reason why we put this week together is to make it as easy as possible to join the Ubuntu commmunity
[15:15] <jono> we want to ensure that getting involved in any part of the Ubuntu community is simple, easy and as fun as possible
[15:15] <jono> as such, every release cycle we put together a week a long of IRC sessions that cover a huge range of sessions
[15:16] <jono> so, the first thing you should do is go and look at the range of sessions available at https://wiki.ubuntu.com/UbuntuOpenWeek
[15:16] <jono> it will show you all the different sessions and when they are running
[15:16] <jono> but now, let me explain how it works:
[15:16] <jono> every Ubuntu Open Week session takes place in #ubuntu-classroom (here)
[15:17] <jono> this is where the person running the session will lead it
[15:17] <jono> but also join #ubuntu-classroom-chat too - that is where you can discuss the session as it runs
[15:18] <jono> throughout the session you will no doubt want to ask questions, and questions are encouraged
[15:18] <jono> to do this, ask your question in #ubuntu-classroom-chat and begin it with 'QUESTION'
[15:18] <jono> example:
[15:19] <jono> QUESTION: Why is metal so great?
[15:19] <BUGabundo_work> QUESTION: what's the topic today ?
[15:20] <jono> and then, when questions appear, the leader of the session will paste it in here and answer
[15:20] <jono> e.g.:
 QUESTION: Why is metal so great?
[15:20] <jono> bhk_f, energy my friend, energy :)
[15:20] <jono> don't ask questions in h ere
[15:20] <jono> they should be asked in #ubuntu-classroom-chat
[15:22] <jono> so that is how Open Week works, its pretty simple - just hang here and enjoy the session, and then ask questions in #ubuntu-classroom-chat
[15:22] <jono> as the week progresses, each session will be archived and logged too and logs will be placed on https://wiki.ubuntu.com/UbuntuOpenWeek
 QUESTION: why isnt #ubuntu-classroom moderated and only giving voice to the speaker? maybe then the speaker wont get off topic with people asking questions in there and not in here
[15:23] <jono> billybigrigger, we do that if it gets a little loud in here, but only if needed
[15:23] <jono> you can see how quiet it has been here so far :)
[15:23] <jono> so, I just want to talk a few mins about our community
[15:23] <jono> and I want to talk about why we run events such as Ubuntu Open Week
[15:24] <CuriousMe> holding my breath jono :-)
[15:24] <jono> as many of you will have heard me babble on about before, I see community as a collection of dots - different sets of people with different interests and skills
[15:25] <jono> each of us has something we can bring to Ubuntu
[15:25] <jono> some of us can write code, or produce packages, or do tests, or organise events, or write documentation, or translate things...each of us has a brick we can place into the wall
[15:27] <jono> at Canonical I lead the community team (which are known in the community and Canonical as the Horsemen), and my goals with the team are to ensure the community is as diverse as possible, encouraging participation at every level, that it is as intuitive and simple to get involved as possible, and that people have a great time while here
[15:28] <jono> we want everyone who gets involved in Ubuntu to also feel an unbridled sense of family - a sense that we are all on the same road, heading in the same direction, moving to the same rhythm
[15:28] <jono> this is in essence the greatest attribute of community - when we are all moving to the same rhythm, anything is possible
[15:28] <jono> the trick...is coordination
[15:28] <thiebaude> Hi jono
[15:29] <jono> coordination is the key to successful community - a well coordinated, engaged community can achieve things like...resolving bug #1
[15:30] <jono> so with this in mind, we have looked at pretty much every aspect of the community contribution process to make it easier
[15:30] <jono> a few examples:
[15:31] <jono>  * we have wanted to make bugs more manageable distributable through the community, so we created 5-A-Day
[15:31] <jono>  * we have been doing extensive work in bug workflow and optimisation, producing resources such as the Ubuntu Upstream Report
[15:32] <jono>  * we have been working to grow our developer base with MOTU, improving the sponsorship queue, developer documentation, and more
[15:32] <jono>  * we want to help educate people in how to contribute to Ubuntu, so we have organised events such as Ubuntu Open Week, packaging jams, bug jams and more
[15:33] <jono>  * later in the cycle we organise another week of IRC sessions called 'Ubuntu Developer Week', which is like UBuntu Open Week, but focused on technical developer sessions only
[15:34] <jono>  * we want to make Ubuntu more visible in terms of content and education, so we created the YouTube Ubuntu Developer Channel
[15:34] <jono> and there are many, many more initiatives and programmes going on to grow our wickedly cool community
[15:36] <jono> so, I am not going to babble on for too long this morning and will answer any questions you may have about Ubuntu, this week or anything else - send your questions to #ubuntu-classroom-chat
 QUESTION: Can we comment on the happening in #ubuntu-classroom in #ubuntu-classroom or are those supposed to be here aswell?
[15:37] <jono> kippy, nope, just in #ubuntu-classroom-chat
 QUESTION: what's the topic today ?
[15:37] <jono> BUGabundo, check https://wiki.ubuntu.com/UbuntuOpenWeek
 QUESTION: why is open week held largely during business hours in the USA? Can't we diversify the times for global participation?
[15:37] <jono> BB-wolf, heh, its not business hours on the West Coast!
[15:38] <jono> BB-wolf, we hold Ubuntu Open Week in largely European afternoon hours as it hits most timezones with reasonable convenience, but it will mean some people in the world having to get up a bit early or stay a bit late
 QUESTION: WHat is bug #1
[15:39] <jono> yusuf_, https://launchpad.net/ubuntu/+bug/1
[15:39] <ubot5`> jono: Error: Could not parse data returned by Launchpad: The read operation timed out
[15:39] <jono> heh
[15:40] <jono> this is the very first bug that Mark registered in Ubuntu
[15:40] <jono> Microsoft has a majority market share
[15:40] <Milyardo> I can confirm this bug
[15:40] <jono> this is one of the bugs we really want to solve :)
 QUESTION: Why #1 is so important ?
[15:41] <jono> esters, well, bug #1 is not the  sole reason many of us work on Ubuntu, but the  huge Microsoft majority market share is a significant reason why as their majority actually makes computing less accessible to people
[15:41] <jono> there is a lot of research and documentation available which outlines why, and  recommend you check it out
 QUESTION: why the ubuntu website is updated slowly? somebody is translating ubuntu to my language, but he is not in the list.
[15:43] <jono> telebovich, I assume you mean Launchpad's Rosetta tool - those translations are updated periodically - I  recommend you come to Make Rooney's session on Friday - he will be talking translations there
 QUESTION: What is the best way to start helping as a non-programmer? What projects are most open to newbies?
[15:44] <jono> djiezes, lots and lots of ways!
[15:44] <jono> if you want to talk to people, you can join our LoCo teams
[15:44] <jono> or if you want to contribute to software, you can translate, or write documentation, or do testing, or do bug triage
[15:45] <jono> each of these teams needs help, I think the best thing to do is to figure out what your main interest is, join the team and have a go :)
 QUESTION: What is 5-A-DAY
[15:45] <jono> 5-A-Day (https://wiki.ubuntu.com/5-A-Day) is a programme we kicked off to help spread the load with bug triage
[15:46] <jono> the idea is fairly simple - everyone who participates in 5-A-Day helps weith five bugs every day
[15:46] <jono> this can be triaging a bug, helping to explain how to reproduce the bug or something else
[15:46] <jono> see https://wiki.ubuntu.com/5-A-Day for more details
[15:47] <jono> 5-A-Day has been a rocking success and has seen consistent growth :)
 QUESTION: Many people are quite wary to jump into an already busy, highly active community. In such a situation, how do you think a very new entrant into Ubuntu communtiy can start his contributions? I have heard lot of people say "I want to contribute, but don't know where to start?"
[15:49] <jono> techno_freak, the best way to get involved is to just get involved - I know it sounds obvious, but I feel the Ubuntu community is such a warm and welcoming place, that anyone can get involved and  if you make some mistakes, we expect that
[15:49] <jono> the hardest part is figuring out what you want to do and where you can contribute
[15:49] <jono> if anyone is uncertain, email me at jono AT ubuntu DOT com and I will help :)
[15:49] <Kolyan_ufalug_> jono: When in Ubuntu there will be a control centre of system with set of utilities which can work both in GUI, and in the console?
[15:50] <jono> Kolyan_ufalug_, not here please, ask in #ubuntu
[15:50] <Kolyan_ufalug_> Ok, thanks
 QUESTION: how do a programmer start contributing?
[15:51] <jono> CuriousMe, a great way is to fix bugs - many programmers like to write patches that fix bugs so that our packages can apply them and upload them to the archive
[15:51] <jono> we also have people working on websites such as Brainstorm, contributing unit tests in the QA team and much more
[15:51] <jono> we have plenty of areas in which coders can get involved :)
 QUESTION: why is there no explanation of what these talks are each about? (Ex: Ubuntu behind the scenes)
[15:52] <jono> it explains it on https://wiki.ubuntu.com/UbuntuOpenWeek
[15:52] <jono> any last q's ?
[15:53] <jono> cybernoutles> QUESTION : is there any thought about how to speedup ubuntu, there was some news about it getting slower and slower, is there a way to see how the disk layout of the systems install is affecting the performance, might we need to have dynamic loading of kernel modules, whats needed to speed things up?
[15:54] <jono> cybernoutles, boot time is a key goal for Jaunty and we want to work on some real improvements there
[15:54] <jono> so it is planned for part of the next cycle
 QUESTION: for the uninitiated, can we have a clear outline of say first n steps to take to start contributing? like do we need to register for some accounts or find a mentor or other questions on similar lines, as someone who has been trying to get started i feel its all too fragmented to start and not so intuitive
[15:55] <jono> kippy, so the first thing to do is to get an idea of which team you want to join, when you have picked a team, I recommend you join their mailing list (http://lists.ubuntu.com) and join their IRC channel if they have one - then write a message asking how to get involved
[15:56] <jono> this is a great way of making contact with the team and a quick introduction to getting involved :)
[15:57] <jono> ok, I think we ar done
[15:57] <jono> are done
[15:57] <jono> thanks everyone, and  have a great Ubuntu Open Week!
[15:57] <jono> woo! :)
[15:57] <jcastro> Alright thanks jono
[15:57] <jcastro> we're going to give everyone ~4 minutes or so until the top of the hour
[15:57] <jcastro> and then we'll kick off with the next session
[15:57] <jcastro> which is Ubuntu Behind the Scenes with Nicolas Valcarcel
[16:00] <jcastro> ok nxvl, take it away!
[16:01] <nxvl> here
[16:01] <nxvl> \o/
[16:01] <nxvl> who is here to know how ubuntu works under the hood?
[16:01] <BlueCamel> +1
[16:01] <esters> I'm here :)
[16:01] <mrooney> o/
[16:01] <vestera> i am
[16:01] <nxvl> ok, let's start
[16:02] <sloopy> <- has seen most of /etc in vim
[16:02] <CuriousMe> ++
[16:02] <nxvl> as you might know ubuntu is sponsored by Canonical, and has some Canonical employees working on the distro
[16:02] <nxvl> but a lot of the work is driven by the community effort
[16:03] <nxvl> we are not much people in Canonical to manage all the weight of the development
[16:03] <nxvl> also
[16:03] <nxvl> we have releases every 6 months
[16:03] <nxvl> without exceptions
[16:03] <nxvl> but, how do we do that?
[16:03] <nxvl> it's a matter of organization and well marked stages on the development
[16:04] <nxvl> we can't just do whatever we want all the time
[16:04] <nxvl> we have freezes, milestones and all kind of things that help us have an organized and well structured development
[16:04] <nxvl> but first we need to understand what our goals are
[16:05] <nxvl> first thing in the Ubuntu pholosiphy is that it should be available for everyone
[16:05] <nxvl> any normal user should be able to use it without much pain
[16:05] <nxvl> also not so normal user should be able too
[16:05] <nxvl> as gandmas
[16:06] <nxvl> they are don't understand computers as easy as most of ut
[16:06] <nxvl> and we need to make our software as easy as we can so they can understand it
[16:06] <nxvl> also we have a lot of effort in accesibility
[16:07] <nxvl> that means that there is a whole team working on maintaining toold for people with disorders (as blindness) to be able to use it
[16:07] <nxvl> also we have a lot of efforts on documentation
[16:07] <nxvl> so people can find answers easlily
[16:07] <nxvl> another point of the ubuntu philosiphy is that it should be available in your language
[16:08] <nxvl> for that we have a large number of translators working on the software
[16:08] <nxvl> 11:07 < Kolyan_ufalug_> QUESTION: When in Ubuntu there will be a control centre  of system with set of utilities which can work both in  GUI, and in the console?
[16:08] <nxvl> Kolyan_ufalug_: that a good question and i don't have the answer right now
[16:09] <nxvl> Kolyan_ufalug_: last UDS we talk about such a tool for server administration that can be easily extended to the desktop
[16:09] <nxvl> Kolyan_ufalug_: our goal is to have it for 10.04, our next LTS
[16:09] <knome>     *
[16:10] <nxvl> Kolyan_ufalug_: you can check more info on https://wiki.ubuntu.com/UbuntuCentralizedServiceAdministrator
[16:10] <nxvl> help is welcomed
[16:10] <nxvl> you can contact me for this, since i'm the one behind it
[16:10] <nxvl> so
[16:11] <nxvl> we were talking about translations
[16:11] <nxvl> we have a lot of people working on it
[16:11] <nxvl> most of that work is being held by LoCo teams
[16:11] <nxvl> that organize translation sprint
[16:11] <enterneo> is there a pidgin PPA for Intrepid Ibex?
[16:11] <nxvl> for that we use launchpad
[16:12] <nxvl> translation.launchpad.net
[16:12] <nxvl> so it's easier for people wanting to help
[16:12] <cyphermox> actually, it's translations.launchpad.net
[16:12] <nxvl> they don't need to handle any code or work directly with .po files, just with strings
[16:12] <nxvl> cyphermox: thank you!
[16:12]  * nxvl HUGS cyphermox 
[16:13] <nxvl> so
[16:13] <nxvl> let's dive into the process of a release
[16:14] <nxvl> 11:14 < bcurtiswx> QUESTION: how much work is being put forward to integrate  things like instant messaging and video/voice chat into the  gnome user interface (like the FUSA for example)
[16:14] <nxvl> bcurtiswx: i don't really know, i'm a server guy not a desktop one
[16:14] <nxvl> but i think gnome put a lot of effort on that
[16:15] <igor_>     *
[16:15] <igor_>       /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[16:15] <nxvl> and empathy is being able to have some video and voice support
[16:15] <nxvl> i haven't try it yet, but i've read it has
[16:15] <bcurtiswx> nxvl, ty
[16:15] <nxvl> so
[16:15] <nxvl> the release process
[16:15] <nxvl> as i said before, we have a release every 6 month, with no exceptions
[16:16] <nxvl> and we have strongly marked stages in the development
[16:16] <nxvl> all of that stages are hardly influenced by the Gnome Calendar
[16:17] <nxvl> as we have Gnome as our primarly desktop we somehow depend of them
[16:17] <nxvl> (if someone send me a private mesage please resend)
[16:18] <nxvl> 11:17 < cybernoutles> QUESTION : how would ubuntu server fit into the new idea  of "cloud computing" can ubuntu server run services like  programs , or total ubuntu desktops from a server to an  terminal over the net?
[16:18] <nxvl> cybernoutles: we are putting efforts on that
[16:18] <nxvl> so, yes it will fit in the near future if it doesn't fit now, but a better place to ask that is in mathiaz's session
[16:19] <nxvl> which is tomorrow at 18 UTC
[16:19] <igor_>     *
[16:19] <igor_>       /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
 does this mandated release schedule ever compromise the quality  of a given release?
[16:20] <nxvl> igor_: please stop that
[16:20] <nxvl> sloopy: no it doesn't and you will see why in a bit :D
[16:21] <nxvl> so
[16:21] <nxvl> the first stage: Planification
[16:22] <nxvl> we start a development cycle planificating what are we going to do
[16:22] <nxvl> we propose new features and give them a strategic priority in the distribution
[16:22] <nxvl> thos proposal are being done by the community using brainstorm (brainstorm.ubuntu.com)
[16:23] <nxvl> but they need a developer to adopt them so they can be done
[16:23] <nxvl> actually anyone can adopt an idea and develop/deploy it
[16:23] <nxvl> and then it will become a developer
[16:23] <nxvl> so if you have some ideas send them to brainstorm
[16:23] <nxvl> and develop/deploy them
[16:25] <nxvl> 11:21 < kippy> QUESTION: Like UbuntuOpenWeek and UbuntuDeveloperWeek do we have  some sessions that help the users learn how ubuntu works (as an  operating system as opposed to community)?  Don't you think this  kind of session that explains the inner workings of Ubuntu as an  operating system, that would help breed geeks who can contribute  to certain sections of the community better?
[16:26] <nxvl> well, that's why UbuntuOpenWeek and UbuntuDeveloperWeek are for
[16:26] <nxvl> we also have LoCo team running events locally
[16:26] <nxvl> and some QA sessions
[16:26] <nxvl> and ubuntu classroom
[16:26] <nxvl> we try to cover everything
[16:26] <nxvl> and if we don't feel free to run some or send us your ideas to cover them
[16:27] <nxvl> :D
[16:28] <nxvl> 11:28 < kippy> QUESTION (FOLLOWUP): nxvl, have lots of requests for such  sessions, where to post them?
[16:28] <nxvl> you should ping our ubuntu-classroom dean and discuss them
[16:28] <nxvl> sfor that james_w will we your guy
[16:29] <nxvl> we also have ubuntu-classroom mailing list
[16:29] <nxvl> so
[16:29] <nxvl> about planification
[16:30] <nxvl> we meet each 6 months on the Ubuntu Developer Submit to discuss our ideas
[16:30] <knome> nxvl, *planning :]
[16:30] <nxvl> this time we are going to have it on MountainView California, and google offices
[16:30] <nxvl> knome: yes, that, sorry
[16:30] <nxvl> :D
[16:30] <nxvl> not native english speaker
[16:31] <nxvl> it will be from 8th to 12 December
[16:31] <nxvl> everyone is welcome to come
[16:31] <nxvl> it's an open event
[16:31] <nxvl> where you can help plan Jaunty (out next release)
[16:32] <nxvl> we have 1 hour BoF session
[16:32] <nxvl> where we discuss the proposed ideas, after that discussion we write the blueprints
[16:32] <nxvl> and start developing new feautures
[16:33] <nxvl> we have that every 6 months as i said before
[16:33]  * x_dimitri is quite surprised that nxvl is not a native english speaker
[16:33] <nxvl> and if you aren't able to travel you can always go into the IRC channels we have for UDS and/or use VOIP
[16:34] <nxvl> or the streaming of the sessions
[16:34] <Tolchi> ty nxvl
[16:34] <nxvl> so you can hear everything we discuss and/or give us ideas comments by IRC
[16:34] <Tolchi> gracias nicolas
[16:34] <nxvl> 11:33 < cybernoutles> QUESTION : how much effect  does ubuntu brainstorm have  on the planning of next releases? Is that the best way to  influence the way ubuntu goes, or are there other options
[16:34] <nxvl> cybernoutles: a lot, before UDS and while we wait for new archives to open, we do brainstorm triaging
[16:35] <ciprian_topala> ignore #ubuntu-classroom CRAP
[16:35] <nxvl> where we see what new ideas are posted
[16:35] <nxvl> and we develop the list of the best to be taken in account and discuss them at UDS
[16:35] <nxvl> so
[16:36] <nxvl> after we have plan, discuss on UDS and write down the spects
[16:36] <nxvl> the development starts
[16:36] <nxvl> first stage of the development is Merging
[16:36] <nxvl> where we sync our repos with debian ones
[16:36] <nxvl> for that we take the package we haven't touch from debian, that's called a sync
[16:37] <nxvl> or we take the new debian package, patch it with our changes and upload the new ubuntu version, that's called a merge
[16:37] <nxvl> we also find us at some points where we have a modified ubuntu package that has all of it's changes already applied by upstream or by debian
[16:38] <nxvl> then we sync them too
[16:38] <nxvl> the idea is to have almost all the package just synced
[16:38] <nxvl> that save us a lot of work we can use in another thing
[16:38] <nxvl> so if you make a patch or a change it would be a really good idea to send it back to upstream
[16:38] <nxvl> 11:37 < bcurtiswx> QUESTION: (for testers), is it at this point (the debain  sync) that the most breakage can happen?
[16:38] <nxvl> bcurtiswx: yes
[16:38] <nxvl> :D
[16:39] <nxvl> in the merge time the development release breakes a lot
[16:39] <nxvl> so, after merges time the feature development start
[16:39] <nxvl> (actually it starts in the merge stage, but you got the idea)
[16:40] <nxvl> at this point we can't sync or merge with debian anymore
[16:40] <nxvl> and you will need to ask for a Freeze exception to to so
[16:40] <nxvl> just in the cases that it's needed
[16:40] <nxvl> in this stage we start developing the new feature discussed at UDS and with an approved blueprint
[16:41] <nxvl> after that we have the feature freeze
[16:41] <nxvl> where no more development can be done
[16:41] <nxvl> at that stage almost all the package must be usable and in a good shape
[16:41] <nxvl> this goes in the 17th week of the development
[16:41] <nxvl> then we start to fix bugs
[16:41] <nxvl> 11:41 < telebovich> QUESTION: Why Ubuntu has 6 month developing cycle?
[16:42] <nxvl> telebovich: because Gnome is
[16:42] <nxvl> :D
[16:42] <nxvl> 11:41 < weboide> QUESTION: when is situated the beta release?
[16:42] <nxvl> weboide: i will got into that soon
[16:42] <nxvl> 11:42 < Yasumoto> QUESTION: How often is the Debian freeze broken to allow for  new syncs? Is it relatively easy?
[16:42] <nxvl> Yasumoto: you mean debian freeze expetions?
[16:42] <nxvl> exceptions*
[16:42] <Yasumoto> yep
[16:43] <nxvl> it's not a hard process
[16:43] <nxvl> you just need to have a rationale of why
[16:43] <nxvl> for universe it's quite easy
[16:43] <nxvl> for main it's a little harder
[16:43] <nxvl> but, no it's not hard or painful at all
[16:43] <nxvl> so, then we start developing new stuff
[16:43] <Yasumoto> alright, sweet. makes sense, thanks :)
[16:44] <nxvl> and we have the Ubuntu Developer Sprint
[16:44] <nxvl> for that spring only the developers that need to finish something are supposed to attend
[16:44] <nxvl> it's a week where canonical put all the developers together to don't get any distraction and finish their stuff for the release
[16:45] <nxvl> after that we have the feature freeze
[16:45] <nxvl> where no new features can go in
[16:45] <nxvl> that's on the 17th week as i said before
[16:45] <nxvl> 11:45 < Tina_Russell> QUESTION: How much of Ubuntu is synced back into Debian  in turn?
[16:45] <nxvl> Tina_Russell: all that fits
[16:45] <nxvl> Tina_Russell: and we try to make it all
[16:46] <nxvl> after the feature freeze we start hunting bugs
[16:46] <nxvl> and 2 weeks after that we have the User interface freeze
[16:46] <nxvl> where interfaces can't be changed
[16:46] <nxvl> so the documentation team can take screenshots for their documents
[16:46] <nxvl> :D
[16:46] <nxvl> 11:46 < igor_> QUESTION: How do you manage packages that are orphaned in Debian  ?
[16:47] <nxvl> igor_: we fix them and send patches back
[16:47] <nxvl> the next freeze in place is the Beta Freeze
[16:47] <nxvl> wich is the 21th week
[16:47] <nxvl> after that we start to fix high priority bugs
[16:47] <nxvl> and start getting the final release into shape
[16:48] <nxvl> 11:47 < telebovich> QUESTION: if the team find some improvement that worth to  add in the version after freez time, do they change the  code or UI?
[16:48] <nxvl> telebovich: you need a freeze exception with a rationale that worth it
[16:49] <nxvl> 11:48 < syslogd> QUESTION: Ubuntu Mobile is based on GNOME, right? Do the  changes reflux into the main project (-> GNOME) so that there  are going to be other distributions that focus on those mobile  computers?
[16:49] <nxvl> syslogd: AFAIK, yes
[16:49] <nxvl> 11:48 < xjazz> QUESTION: What about kde-devel guys. Is comfortable they to  adapt for planing, depend on ubuntu and gnome schedule?
[16:49] <nxvl> xjazz: i think they are, yes
[16:49] <nxvl> so
[16:49] <nxvl> after beta freeze we start testing
[16:50] <nxvl> we have a beta release, then a RC and images being builded for massive testing
[16:50] <nxvl> 11:49 < bhk_f> QUESTION: what kind of changes is ubuntu doing to vanilla kernel
[16:50] <nxvl> bhk_f: don't really know i don't touch the kernel at all
[16:50] <nxvl> then a lot of effort on testing is being done
[16:51] <nxvl> so we can be sure all the worst bugs are fixed
[16:51] <nxvl> then, we have the final freeze
[16:51] <nxvl> where only showstopper bugs are fixed
[16:51] <nxvl> and a lot of testing is being done
[16:51] <nxvl> and then we have a release
[16:51] <nxvl> all the parties start all around the world
[16:52] <nxvl> and we are have nice CD's comming to our houses
[16:52] <thiebaude> yup
[16:52] <nxvl> but, what about bugs in the stable release?
[16:52] <nxvl> we have a process called SRU's
[16:52] <nxvl> which stands for Stable Release Update
[16:52] <nxvl> that goes to the ubuntu-sru team, motu-sru and sru-verification teams
[16:53] <nxvl> if we fix something in a stable release we need to ask for those teams to review it
[16:53] <nxvl> and if they are accepted we can have it in our main repos
[16:53] <thiebaude> QUESTION:has a SRU been done for 8.10?
[16:53] <nxvl> thiebaude: yes, we already have some
[16:53] <nxvl> :D
[16:53] <nxvl> SRU's are mostly for security vulnerabilities, severe regressions
[16:54] <nxvl> and user data lost
[16:54] <nxvl> and all kind of ugly bugs
[16:54] <thiebaude> nxvl:QUESTION:what is your ubuntu xpertise?
[16:54] <nxvl> 11:51 < gourgi> QUESTION: if the high priority bugs aren't fix until final  release what happens next? do they are re-assigned for next  release ?
[16:54] <nxvl> gourgi: that SRU's :D
[16:55] <nxvl> 11:52 < igor_> QUESTION: Ubuntu aimed to be as synced to Debian as possible  (technicaly). Are there points available in the DFSG (Debian  Free Software Guideline) and/or the Social Contract that are not  synced with Ubuntu aims ?
[16:55] <nxvl> igor_: we stick to DFSG for packaging our stuff with some exceptions
[16:55] <nxvl> so almost all of our work is debian compilant
[16:56] <nxvl> 11:54 < kippy> QUESTION: Like there is a problem with Intel 845 integrated  graphics chip (and many others) and compiz in 8.10, so according  to the cycle, can we hope to see a fix for this in 8.10 or do we  have to wait till jaunty
[16:56] <nxvl> kippy: we can hope to get a fix, but that's kernel, so ask that question to ogasawara in next session
[16:56] <nxvl> :D
[16:56] <nxvl> thiebaude: i'm a server team guy
[16:56] <nxvl> thiebaude: and a security guy
[16:56] <thiebaude> nxvl:kewl
[16:56] <nxvl> ok, so i think i have time for one more question
[16:57]  * sebner winks the security guy :P
[16:57] <nxvl> ogasawara: have i?
[16:57] <nxvl> 11:56 < biomass> QUESTION: Is there a difference in preparing for a LTS release  compared to the releases inbetween LTS ?
[16:57] <ogasawara> nxvl: go for it
[16:57] <nxvl> biomass: oh yes, it is
[16:57] <nxvl> biomass: for LTS we are more carefull on what we have into it
[16:57] <nxvl> biomass: and we have a lot more of carefull on what new stuff to add to it
[16:58] <nxvl> but for the schedule is the same
[16:58] <thiebaude> nxvl:QUESTION:how long is 8.04 supported?
[16:58] <nxvl> 11:57 < syslogd> QUESTION: Will there be a rolling-release version of Ubuntu?
[16:58] <nxvl> syslogd: i don't get your question? how rolling-release?
[16:58] <jcastro> let's wrap it up!
[16:58] <nxvl> ok
[16:58] <nxvl> i'm out of time
[16:58] <nxvl> thank you guys for attending
[16:59] <gouki> nxvl, why hasn't 8.04.2 been released yet?
[16:59] <thiebaude> thank you,nxvl
[16:59] <jcastro> ok thanks nxvl!
[16:59] <tkoerfer> thanks
[16:59] <Tolchi> gracias nxvl
[16:59] <esters> Thx nxvl
[16:59] <nxvl> let's give the channel to our lovely kernel QA girl!
[16:59] <esters> \o/
[16:59] <jcastro> Alright next up is Leann Ogasawara, who will talk about the kernel
[16:59] <SplItz> ty nxvl
[16:59] <Tolchi> girl???
[16:59] <jcastro> quick announcement
[16:59] <Tolchi> wow
[16:59] <ogasawara> thanks nxvl!
[16:59] <lool> gouki: 8.04.2 will be 6 months after .1, aronud January IIRC
[16:59] <igor_> thanks nxvl
[16:59] <bhk_f> pix or it didn't ....
[16:59]  * snuxoll blinks
[16:59] <esters> Happened
[16:59] <jcastro> There is an added session on Wednesday at 2200 UTC - Training
[16:59] <jcastro> so please check the schedule
[17:00] <Maurici1> Thanks nxvl, was a great information about ubuntu...have a nice day
[17:00] <jcastro> ok, ogasawara take it away, everyone else, please keep the channel clear
[17:00] <ogasawara> Hi Everyone!
[17:00] <thiebaude> ok
[17:00] <CuriousMe> hello there
[17:00] <ogasawara> Welcome to the session on Reporting and Fixing Kernel Bugs!
[17:00] <Tolchi> hi
[17:00] <ogasawara> My name is Leann Ogasawara and I work for Canonical as a member of the Ubuntu QA Team.  My primary focus is on the Ubuntu kernel bugs.
[17:00] <thiebaude> hi
[17:00] <ogasawara> I'd really like to spend the next hour highlighting some kernel bug reporting best practices and getting fixes incorporated into the Ubuntu kernel.
[17:01] <ogasawara> If anyone has questions along the way, feel free to post them in #ubuntu-classroom-chat and I'll try to answer as many as I can.
[17:01] <ogasawara> Let's gets started.
[17:01] <ogasawara> Beginning with the Hardy Heron 8.04 release the Ubuntu kernel package naming convention in Launchpad changed from linux-source-2.6.xx to just linux.
[17:01] <ogasawara> Ubuntu kernel bugs should be filed against the "linux" kernel package.  This can be done using the following link:
[17:01] <ogasawara> https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
[17:02] <ogasawara> It's important to make sure the bug is filed against the linux package to help ensure it gets looked at by the kernel team.
[17:02] <ogasawara> When filing a bug, please make sure the title of the bug report is descriptive.
[17:02] <ogasawara> Don't use something like "Suspend Fails" or "Wireless is broken".
[17:02] <drunkenkilla> ogasawara: Question: some notebooks have problems with the brightness for example the samsung and sony notebooks. i created a bug report but nothin happened. is this problem combined with the kernel or is it a driver problem of samsung...?
[17:02] <gouki> drunkenkilla, questions in #ubuntu-classroom-chat!
[17:02] <ogasawara> drunkenkilla: ^^
[17:03] <ogasawara> It's better to use for example "Suspend fails to resume on a Dell Inspiron 1420".
[17:03] <drunkenkilla> ok sry^^
[17:03] <ogasawara> Always include hardware or driver information in a kernel bug's title when applicable.
[17:03] <ogasawara> The reason I say this is because kernel bugs are often hardware specific.
[17:03] <ogasawara> Even though someone may be experiencing the same symptom of a bug, they should really open a new report if they have different hardware than the original bug reporter.
[17:03] <ogasawara> Different hardware uses different drivers which likely require different fixes, hence the reason for separate bug reports.
[17:03] <ogasawara> This is why I stress the importance of a descriptive bug title.  When something like "Suspend Fails" is used as the title, everyone with suspend/resume issues ends up subscribing to the bug.
[17:04] <ogasawara> This invites others to post completely unrelated information to the bug.  Even worse, the bug will often get a flurry of "me too" comments posted.
[17:04] <ogasawara> This results in impossible to follow bug reports which are not likely to get much attention from the kernel team.
[17:04] <ogasawara> Also, please refrain from posting the "I think I'm having the same bug . . ." type of comments.  If someone is unsure if they have the same bug, open a new report.
[17:04] <ogasawara> Hijacking another person's bug report is bad.
[17:05] <ogasawara> We can always mark a bug as a duplicate of another bug later on.
[17:05] <ogasawara> If someone does have the same bug but has nothing additional to add other than a "me too", please don't post a "me too" comment.
[17:05] <ogasawara> Launchpad now has an +affectsmetoo functionality.  Just click on the "change" link next to "This bug doesn't affect me" under a bug's title.
[17:05] <jcastro> Session details here: https://wiki.ubuntu.com/UbuntuOpenWeek
[17:05] <ogasawara> Also, be sure to subscribe to the bug to get notifications of any updates made to the bug.
[17:06] <ogasawara> To subscribe to a bug, click on the "Subscribe/Unsubscribe" link on the right hand side of the bug report.
[17:06] <ogasawara> For the bug's description, it's always great to include steps to reproduce the issue if possible.
[17:06] <KarlsBerg87> someone have one AcerAspire one with ubuntu?
[17:06] <ogasawara> This helps others to confirm they do indeed have the same bug.
[17:06] <ogasawara> Additionally, it will help the developers debug the situation by either being able to reproduce the issue or get an idea what might be the root cause of the issue.
[17:07] <ogasawara> Also, in the bug description it's great to mention if this is a regression or not.
[17:07] <ogasawara> Specifically noting the most recent version of the kernel where the bug did not occur and the version where the bug was first introduced is helpful.
[17:07] <ogasawara> This can help isolate the set of kernel patches which should be examined.
[17:07] <ogasawara> With this version information a git bisect could also be used to determine the specific patch which introduced the regression.
[17:07] <ogasawara> If a bug reporter is able to perform a git bisect, it's extremely helpful to the kernel team and very much appreciated.
[17:08] <ogasawara> For those of you who don't know, git is the revision control system which is used by the upstream kernel as well as the Ubuntu kernel.  For more information on git refer to:
[17:08] <ogasawara> http://www.kernel.org/pub/software/scm/git/docs/
[17:08] <ogasawara> Regarding the git bisect, it's basically a multi-step process to systematically narrow down a specific commit which introduced a regression.
[17:08] <ogasawara> It involves a series of steps of marking a known "good" and "bad" kernel version and proceeding to build and test kernels.  It usually only takes a few iterations to narrow down a specific patch which is causing issues.
[17:08] <ogasawara> For more information please refer to:
[17:08] <ogasawara> http://www.kernel.org/doc/local/git-quick.html#bisect
[17:09] <ogasawara> As a general rule of thumb, along with a good bug title and description, kernel bug reports should at a minimum include the following information:
[17:09] <ogasawara>  * cat /proc/version_signature > version.log
[17:09] <ogasawara>  * dmesg > dmesg.log
[17:09] <ogasawara>  * sudo lspci -vvnn > lspci-vvnn.log
[17:09] <ogasawara> /proc/version_signature lets us know the exact kernel version the bug is against.  It also helps us know that the most recent kernel available is being used.
[17:09] <ogasawara> dmesg provides a log of kernel messages that often contain helpful debugging information for the kernel team.
[17:09] <ogasawara> sudo lspci -vvnn lets us know about a system's hardware.
[17:10] <ogasawara> When providing the above information, please be sure to *attach* each text file *separately*.
[17:10] <ogasawara> Do not tar up the files, do not zip the files, do not paste the output directly as a comment.
[17:10] <ogasawara> When developers are looking at numerous bugs each day this can get annoying having to untar files, unzip files, or expand comments to view debug output.
[17:10] <ogasawara> Also, please please please follow directions when they're given.  If someone asks for the output of 'sudo lspci -vvnn' don't give the output of 'sudo lspci -vv'.
[17:11] <ogasawara> I know it's silly that I have to specifically point this out, but it's amazing how many people fail to post the requested information or fail to report any information at all even when asked.
[17:11] <ogasawara> I do understand that sometimes there are language barriers involved, but for the most part using english is a non issue.
[17:11] <ogasawara> Some additional tips to also help the kernel team is to make sure bug reports are kept up to date.  Even a small comment that the issue still exists against the latest 2.6.xx-yy.zz kernel is useful.
[17:11] <ogasawara> Also, when asked to test the latest development kernel, please don't be difficult and reply with "I can't believe you want me to test a newer kernel!  This bug is against Hardy, which is an LTS release so it should be fixed there!"
[17:12] <ogasawara> We understand where the frustration is coming from, but the hostile remark does not help solve the bug.
[17:12] <ogasawara> The fact of the matter is that before any kernel bug can qualify for a Stable Release Update, the bug must be confirmed as fixed in the actively developed kernel.
[17:12] <ogasawara> Refer to http://wiki.ubuntu.com/StableReleaseUpdates for the Stable Release Update bug criteria and procedures.
[17:12] <ogasawara> Also, if a bug has been resolved, don't be afraid to close the bug report.  Marking the bug "Fix Released" helps make the kernel team's (and bug control team's) triaging efforts one step easier.
[17:13] <ogasawara> We can always use additional help triaging kernel bugs.
[17:13] <ogasawara> The volume of kernel bugs can be daunting.  Especially considering the limited number of resources the kernel team has.
[17:13] <ogasawara> The following wiki's are good starting places for those looking to get involved.
[17:13] <ogasawara> https://wiki.ubuntu.com/KernelTeamBugPolicies
[17:13] <ogasawara> https://wiki.ubuntu.com/DebuggingProcedures#Kernel
[17:13] <ogasawara> The first link describes the general kernel team bug policy and the second link is a series of docs for help with debugging specific kernel issues.
[17:13] <ogasawara> Ok, lets stop and field any questions you may have so far (remember to post them in #ubuntu-classroom-chat - I'll copy and reply to them here).
[17:14] <ogasawara> just give me a sec to scroll back in #ubuntu-classroom-chat
 ogasawara: QUESTION: what to do about Greg-K-H's bitching about not enuff patches from someone@canonical
[17:15] <ogasawara> bhk_f: all I can say is with the limited number of kernel devs we have we do our best to make sure our patches go upstream
[17:16] <ogasawara> bhk_f: the kernel team is growing in numbers so we'll hopefully be able to contribute more in the future
[17:16] <ogasawara> drunkenkilla> ogasawara: Question: some notebooks have problems with the brightness for example the samsung and sony notebooks. i created a bug report but nothin happened. is this problem combined with the kernel or is it a driver problem of samsung...?
[17:17] <ogasawara> drunkenkilla: I'd have to take a look at the bug report, if you can ping me with the bug # in #ubuntu-bugs I'll be sure to take a look
[17:17] <ogasawara> kippy> QUESTION: how do we know that a bug is for the kernel and not some other package?
[17:17] <ogasawara> kippy: some common kernel bugs would be, kernel oops or panics
[17:17] <ogasawara> kippy: complete system lock ups
[17:18] <ogasawara> kippy: issues with suspend/resume or wifi would also typically be kernel related
[17:18] <ogasawara> kippy: if in doubt, don't be afraid to ask in #ubuntu-bugs
[17:18] <ogasawara> lord> QUESTION: what is the reason of kernel renaming?
[17:18] <ogasawara> lord: basically to make things easier on the kernel team
[17:19] <ogasawara> lord: having to track one package vs multiple packages is simpler
[17:20] <ogasawara> lord: additionally it made it difficult to make sure bugs were carried forward when using the old naming convention
[17:20] <ogasawara> Picklesworth> QUESTION: Is sorting out bug reports one of the reasons for the Ubuntu Hardware Database?
[17:20] <ogasawara> Picklesworth: yes :)
[17:20] <ogasawara> mbt> QUESTION:  Is there a way to give a "heads up" when the upstream kernel has a bug in it that needs to be worked around at the Ubuntu level so that we don't have something like the CD/DVD drive regression happen again and slip through a release?
[17:21] <ogasawara> mbt: best way would be to open a Launchpad bug report but also notify myself and the kernel team in #ubuntu-kernel
 ogasawara: QUESTION: How important are "tags" for kernel bugs?
[17:21] <ogasawara> angusthefuzz: tags are very helpful with respect to kernel bugs
[17:22] <ogasawara> angusthefuzz: I used them when we did the 2.6.27 kernel move to note any specific regressions
[17:22] <ogasawara> angusthefuzz: there are also things like tagging bugs as bitesize for the simpler low hanging bugs that can be quickly resolved
[17:23] <ogasawara> angusthefuzz:  we've even discussed tagging bugs with the driver being used
[17:23] <ogasawara> angusthefuzz: I myself use the tags to search bugs in launchpad and I know the kernel team does as well
[17:24] <ogasawara> angusthefuzz> ogasawara: Are those three required files enough to mark a bug confirmed in most cases?
[17:24] <marrow> Hello everybody
[17:24] <marrow> What did I miss?
[17:24] <ogasawara> angusthefuzz: typically yes.
[17:25] <jono> marrow, #ubuntu-classroom-chat
[17:25] <andresmujica> marrow: please comments at #ubuntu-classroom-chat
[17:25] <ogasawara> angusthefuzz: there are some exceptions, but in general those files should be present to mark a bug confirmed/triaged
 QUESTION: What are some good ways to know if a bug is kernel-related or not?
[17:26] <ogasawara> Tina_Russell: see answer above
 ogasawara: are you a kernel developer or just a manger? (i want to know ubuntu organization
[17:26] <ogasawara> lord: I'm actually a member of the QA Team but work closely with the kernel team and primarily focus on the kernel bugs
 QUESTION why don't you wrap those information getters to one program and let it run every time the kernel crashes? or at least let the user start a programm to report this bug?
[17:28] <ogasawara> tkoerfer: I recommend using apport to report your bug
 ogasawara: also hows ubuntu kernel different from vanilla
[17:29] <ogasawara> bhk_f: the kernel team tries to refrain from deviating from the upstream kernel as much as possible
[17:29] <ogasawara> bhk_f: I'll touch on the upstream sync'ing process in a second
[17:30] <ogasawara> ok, guys, I'll try to get to more of the questions at the end
[17:30] <ogasawara> let's continue on
[17:31] <ogasawara> So now what happens after a high quality kernel bug has been filed?  How is the kernel team notified?
[17:31] <ogasawara> Bug reports which have been confirmed against the actively developed kernel, have provided all the necessary debugging information, and are ready for a kernel developer to immediately begin debugging should have their Status set to "Triaged".
[17:31] <ogasawara> Along with setting the Status, the Importance of the bug should be set and the bug should also typically be assigned to the "ubuntu-kernel-team".
[17:31] <mahesh_> i joined in late so i am not sure if this question has already been asked, but if it hasn't been then ... how significantly does the ubuntu kernel differ from the mainline kernel?
[17:32] <ogasawara> mahesh_: please ask in #ubuntu-classroom-chat
[17:32] <ogasawara> https://wiki.ubuntu.com/KernelTeamBugPolicies explains more about this bug policy.
[17:32] <ogasawara> Now, here's where the fun starts.
[17:32] <ogasawara> Knowing that the bug exists in the Ubuntu kernel, it's best to try and confirm the bug exists in the upstream kernel as well.
[17:32] <ogasawara> If the bug is confirmed to also exist in the upstream kernel, we want to be sure to notify the upstream developers about the issue.
[17:32] <ogasawara> The upstream kernel bug tracker can be found at http://bugzilla.kernel.org
[17:32] <ogasawara> Be sure to apply the same best practices when submitting bugs upstream.
[17:33] <ogasawara> A bug watch can also be added to the Launchpad bug report to monitor the upstream bug report.
[17:33] <ogasawara> To add a bug watch, click on the "Also affects project" link in the Launchpad bug report.  It's located under a bug's task table.
[17:33] <ogasawara> Then paste the upstream bug link in the "I have the URL for the upstream bug:" text box.
[17:33] <ogasawara> Click the "Add to Bug Report" button, and the bug watch should be set.
[17:33] <mahesh_> oops! I
[17:33] <ogasawara> All subscribers to the bug should receive email notification for any changes in the upstream bug report's status or importance.
[17:33] <mahesh_> am sorry
[17:33] <ogasawara> Getting kernel bugs confirmed and reported upstream is definitely an area where improvements can be made.
[17:34] <ogasawara> Part of these improvements depend upon the Ubuntu kernel team making it easier for bug reporters to test the upstream kernel.
[17:34] <ogasawara> This is why there are plans for the kernel team to provide an upstream kernel package which will allow bug reporters to easily install and test the upstream kernel.
[17:34] <ogasawara> I think this will greatly help the upstream bug identification process.
[17:34] <ogasawara> I would anticipate this being available sometime during the Jaunty development cycle.
[17:34] <ogasawara> However, for the time being bug reporters will still have to compile the upstream kernel from source.
[17:34] <ogasawara> I know building the upstream kernel may sound like a scary task, but believe me it's actually quite simple.
[17:35] <ogasawara> The following wiki documents this process:
[17:35] <ogasawara> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[17:35] <ogasawara> Another advantage to testing the upstream kernel is that the bug may in fact already be fixed upstream.  This is the ideal situation.
[17:35] <ogasawara> If the specific upstream patch to be pulled in can be identified, definitely post that information to the bug report.
[17:35] <ogasawara> Otherwise, a comment that this issue is resolved in a specific upstream kernel version is still helpful.
[17:36] <ogasawara> During each development cycle the Ubuntu kernel is rebased with each of the upstream kernel release candidates until the final upstream kernel release is made for a specific version.
[17:36] <ogasawara> At that point, the Ubuntu kernel usually stops rebasing with the upstream kernel and will then cherrypick any additional patches from upstream into the Ubuntu kernel.
[17:36] <ogasawara> The patches which are cherrypicked typically represent fixes to resolve kernel bugs that have been reported.
[17:36] <ogasawara> Patches continue to be cherrypicked until the Ubuntu kernel freeze, which is usually a few weeks prior to the final release.
[17:36] <ogasawara> Now, how can someone ensure that the upstream patch will indeed get pulled into the Ubuntu kernel prior to the kernel freeze?
[17:37] <ogasawara> The best approach would be to inquire about the bug on the FreeNode IRC server in the #ubuntu-kernel channel.
[17:37] <ogasawara> Additionally, feel free to ping me directly about it.  I should be in the #ubuntu-kernel channel as well.
[17:37] <ogasawara> We'll make sure we track the bug accordingly and can set the bug's milestone to make sure it stays on the radar of the Ubuntu kernel team.
[17:37] <ogasawara> Now what about the case where a patch for the bug exists but it's neither in the upstream kernel nor the Ubuntu kernel?
[17:37] <ogasawara> First, confirming that the patch does indeed resolve the bug is important.
[17:38] <ogasawara> This does require knowing how to apply a patch and compile the kernel.
[17:38] <ogasawara> I gave a reference for building the upstream kernel earlier.
[17:38] <ogasawara> Applying a patch is the same whether using the upstream kernel source of the Ubuntu kernel source.
[17:38] <ogasawara> The patch command is typically of the form:
[17:38] <ogasawara> patch -p1 < patch_file.txt
[17:38] <ogasawara> To find out more about the patch utility, refer to the man page.
[17:38] <ogasawara> If the patch is going to be built and tested using the Ubuntu kernel source, the following document describes the process of how to build the Ubuntu kernel:
[17:38] <ogasawara> https://help.ubuntu.com/community/Kernel/Compile
[17:39] <ogasawara> Building the Ubuntu kernel uses a slightly different set of commands than building the upstream kernel.
[17:39] <ogasawara> This is because the Ubuntu kernel source provides some additional Ubuntu specific scripts to help build the Ubuntu kernel.
[17:39] <ogasawara> Assuming the testing proves successful and the patch was applied to the Ubuntu kernel, contact the Ubuntu kernel team on the kernel-team mailing list:
[17:39] <ogasawara> https://lists.ubuntu.com/mailman/listinfo/kernel-team
[17:39] <ogasawara> The kernel team monitors the traffic to the mailing list quite closely.
[17:39] <ogasawara> Patches need to be reviewed before being accepted so contacting the kernel team using the mailing list is better than using IRC in this scenario.
[17:40] <ogasawara> When sending a patch to the mailing list be sure to follow a few simple rules.
[17:40] <ogasawara> 1) Mention the Launchpad bug report.
[17:40] <ogasawara> 2) Summarize the issue and why the patch resolves it.
[17:40] <ogasawara> 3) Comment that the patch has been tested and confirmed to resolve the issue.
[17:40] <ogasawara> 4) Be sure to note which kernel version the patch was tested with.
[17:40] <ogasawara> 5) Inline the patch to the email.  Inlining the patch allows for the kernel team to immediately review the patch in the context of the email.  In addition to inlining the patch, I usually also attach it as well.
[17:40] <ogasawara> 6) If there's no response after a week, feel free to follow up with the email again.
[17:41] <ogasawara> If the patch gets accepted into the Ubuntu kernel and does not exist upstream, the Ubuntu kernel team will try to push these patches upstream for review and consideration as well.
[17:41] <ogasawara> It's a lot of extra work for the Ubuntu kernel team to maintain out of tree (ie out of upstream) patches.
[17:41] <ogasawara> As a result, they try to make sure patches get incorporated into the upstream kernel.
[17:41] <ogasawara> Getting patches accepted upstream is in everyone's best interest.
[17:41] <ogasawara> Everyone benefits from the fix being upstream, not just Ubuntu users.
[17:41] <ogasawara> It also avoids patches accidentally being dropped and a bug reappearing.
[17:42] <ogasawara> Now what about the final case of a bug being fixed in the current development release of Ubuntu but still existing in a previous Ubuntu release?
[17:42] <ogasawara> This is where the Stable Release Update policy is taken into consideration.  http://wiki.ubuntu.com/StableReleaseUpdates
[17:42] <ogasawara> If the bug does qualify for a Stable Release Update, a release nomination for the bug will be opened and approved.
[17:42] <ogasawara> If the bug does not qualify for a Stable Release Update, the bug's task table will typically reflect that it's been fixed against the actively developed kernel but will not be fixed as an SRU.
[17:42] <ogasawara> At a minimum, this should be reflected as a comment in the bug.
[17:42] <ogasawara> Only certain individuals have the ability to approve release nominations.
[17:43] <ogasawara> Once approved, the Ubuntu kernel team will try to patch the corresponding kernel with the fix and then the kernel will get uploaded into the -proposed Ubuntu repository.
[17:43] <ogasawara> -proposed is basically a testing bed for any packages containing updates being considered for a Stable Release Update.
[17:43] <ogasawara> I'd encourage you to attend the "Verifying Stable Update (SRU) bugfixes" open week session later this week for more information and how to help out.
[17:43] <ogasawara> As I had mentioned before, the Ubuntu kernel team does have a limited number of resources.  So it is unfortunately the case that not all kernel bugs will get fixed during a given release cycle.
[17:43] <ogasawara> However, by submitting high quality bug reports, it definitely speeds up the process for when the kernel team is able to get to a bug.
[17:44] <ogasawara> If you're interested in getting involved in either helping triage or fix kernel bugs, don't be shy.
[17:44] <ogasawara> Just helping out by making sure bugs have the minimal debug information and are confirmed against the current development kernel is a great starting point for those looking to become triagers.
[17:44] <ogasawara> You'll also likely want to look at becoming a member of the Ubuntu Bug Control team:
[17:44] <ogasawara> https://launchpad.net/~ubuntu-bugcontrol
[17:44] <ogasawara> By becoming a member of ubuntu-bugcontrol you are given certain permissions for setting a bug's status - for example being able to set a bug to "Triaged" or "Won't Fix".
[17:44] <ogasawara> If you are looking to become more involved in the development aspect of the kernel, refer to:
[17:44] <ogasawara> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
[17:45] <ogasawara> Every little bit helps and it is definitely appreciated.
[17:45] <ogasawara> So I'd like to use the remaining time to answer any further questions.
[17:46] <ogasawara> just a sec while I get the next question . . .
[17:47] <ogasawara> mbt> QUESTION:  Sometimes it's useful to use a vanilla kernel to troubleshoot/compare.  The Wiki says use make-kpkg, but it doesn't seem to work.  Currently I just make and make install, because it works without any conflicts.  But can one easily repackage a vanilla kernel?
[17:48] <andresmujica> /852598/*2+
[17:48] <ogasawara> mbt: hrm, I'll review the wiki.  but as I mentioned earlier, the ubuntu kernel team is intending to provide a vanilla kernel for those interested in testing
[17:48] <mbt> ogasawara: Which is good news. :)
 ogasawara: QUESTION: how many are in the kernelteam? can't more dev be hired?
[17:49] <ogasawara> gourgi: there was only 5 devs but we've recently hired on 3 more :)  so yes, more are being hired.
 QUESTION: there has been a fuss about Akoya Mini and some other netbooks using the ralink 2860 WLAN card. There is a driver available from ralink. as mobile/small devices are on Canonical's roadmap, will there be some efforts to get the driver in the vanilla kernel?
[17:50] <ogasawara> m4rt1n: it's preferred if the developers of the driver push the driver upstream first and then it get pulled into the Ubuntu kernel
[17:50] <ogasawara> m4rt1n: vs Ubuntu pulling it and then trying to push it
 QUESTION: about the 2.6.27 regression (tcp options reordering) and the solution of ubuntu "disabling time stamp" instead of use an old kernel or delaying release: is it the best solution?, how we can trust ubuntu that he doesn't disable any other features of the kernel?
[17:52] <ogasawara> lord: a fix was pulled into the kernel for that issue and was released  the same day as Intrepid.
[17:52] <ogasawara> lord: it's really a call and decision made by the release team, and they should be keeping your best interests in mind
[17:53] <ogasawara> lord: it's best to also take a look at the release notes page to review any known issues for a release
 QUESTION: Why are there 2 sessions on SQA - one by ogasawara and one by BrianMurray
[17:53] <ogasawara> bhk_f: this one is definitely kernel specific
 QUESTION: Any member of kernel team has commit writes in upstream?
[17:54] <ogasawara> andresmujica: we use the same process of pushing patches upstream as everyone else - ie via the kernel maintainers
 ogasawara: QUESTION: I noticed an open QA position for creating virtualbox testing images, where do you see images fitting into the kernel bug process?
[17:55] <ogasawara> angusthefuzz: we'll take as much testing of the kernel as possible whether that be on real hw or in a virtual environment
 QUESTION : what is the main case of bugs in the kernel , are there repeated bugs that you encounter over and over?
[17:55] <ogasawara> cybernoutles: there's always suspend/resume issues I see being reported
[17:56] <ogasawara> cybernoutles: and with Intrepid it seemed there were more issues with wifi as well
 QUESTION: Why don't you hire Greg-K-H away from Suse(look wat its doing to his hair!), that will stop his bitching about no patches from canonical...surely
[17:57] <ogasawara> bhk_f: to be fair, Greg-K-H does great work for the kernel no matter who he works for.  hopefully we can do our best to change his opinion of us.  but just buying off a developer is not the right answer :)
 QUESTION: Hows ubuntu kernel different from Fedora kernel, for example the current intrepid & fedora ones ?
[17:58] <jcastro> (last question)
[17:58] <ogasawara> bhk_f: considering we're both using a 2.6.27 based kernel we should be somewhat similar.  I wouldn't be able to tell you the specific differences though, sorry.
[17:59] <ogasawara> ok and last question:
 Question: Bug 279186 (kernel x64 oops on boot for dual core atom D945GCLF2) isn't fixed.  Will I see new kernel updates for Intrepid - now that it is released or do I need to install Jaunty in the hope of a fix ?
[17:59] <ogasawara> Guest33263: Intrepid will see kernel updates via the SRU process, but it wouldn't hurt to test the Jaunty kernel when available.
[18:00] <ogasawara> ok, thanks everyone!
[18:00] <jcastro> thanks leann!
[18:00] <jcastro> ok, ogra will kick off Ubuntu on Ultra Mobile PCs in a minute or so
[18:01] <jcastro> as always, please put questions in #ubuntu-classroom-chat, and don't forget to prefix your question with QUESTION:
[18:02] <jcastro> ogra: you can begin!
[18:02] <ogra> jcastro, 2 min please
[18:03] <jcastro> ok
[18:03]  * ogra puts on some hold music
[18:05]  * ogra waves
[18:05] <ogra> ok. lets get started
[18:05] <ogra> so i'm here to talk about ubuntu-umpc and the work we do in the mobile team in general
[18:06] <ogra> ubuntu-mobile started in 7.10 as a joint project between the moblin community and ubuntu
[18:06]  * lool hugs ogra 
[18:06] <ogra> back then basically the ubuntu mobile team just adopted the moblin technology into ubuntu to make it work
[18:07] <evandarcz> geist
[18:07] <ogra> with hardy a first public imag for so called mobile internet devices, so called MIDs was released
[18:07] <evandarcz> sorry
[18:07] <ogra> *image
[18:08] <ogra> basicall that included the hildon technology for mobile desktops and was focused on intel atm CPUs
[18:08] <ogra> *atom
[18:08] <ogra> which made ubuntu also inrotude the lpia (low power intel) architecture
[18:09] <ogra> which supposedly had some enhancements to kernel and toolchain to make use of the atom specific powermanagement features
[18:10] <ogra> the hardy MID image was still built using the moblin image creator which didnt work so well with established image building technologies
[18:10] <ogra> s/established/established ubuntu/
[18:10] <ogra> so the image build process in intrepid was reworked to be closer to the ubuntu infrastructure ...
[18:11] <ogra> alongside an additional flavour was created, the so called ubuntu UMPC flavour
[18:11] <ogra> so with intrepid we have the ubuntu-mid and ubuntu-umpc flavour ... both targeting mobile devices, basically focussing touchscreens ...
[18:12] <ogra> while -mid is targeting the realysmall devices with screens from 4-7", umpc is thought for bigger ones like the samsung Q1U for example
[18:12] <ogra> i.e. 7-9 or 10"
[18:13] <ogra> mid is still built based on the hildon and mobin technology
[18:13] <ogra> while umpc is targeting devices that usually come with windows vista today, so it was decided to use a standard gnome desktop and make it suitable for touchscreen use
[18:14] <ogra> since the typical umpc devices are as powerful as a laptop today
[18:14] <ogra> screenshots of ubuntu umpc can be found at http://people.ubuntu.com/~ogra/mobile/
[18:15] <ogra> many people decided to use UMPC on netbooks as well where the mobile team had a lot of positive feedback
[18:16] <ogra> some people also expect to use the applications from ubuntu netbook remix on top of this image which is easily possible (i'm in the process of putting a hwto together atm that should be up tomorrow)
[18:16] <ogra> so that should roughly suffice as introduction of what ubuntu-umpc is
[18:17] <ogra> as a note, people that have followed the dev process in intrepid might have seen the image referred to as ubuntu-mobile, late in the cycle we decided to step away from that generic name
[18:17] <ogra> so thus the name ubuntu-umpc
[18:17] <ogra> lets get to some questions :D
[18:18] <ogra> Q: what is the current status of the relationship with moblin and will moblin 2 be available for umpc and mid
[18:18] <ogra> i'm personally only working on -umpc but we will go on to base the -mid image on hildon 2 technology and very likely also import a lot from moblin2
[18:19] <ogra> Q  is my asus eee 1000h a UMPC?
[18:19] <ogra> well, yes and no ... it is surely a netbook and you can definately run -umpc on it (naively or tweaked to use the netbook apps)
[18:20] <ogra> we are mainly focussing on touchscreens atm but there is a loose plan to add a bootmenu to the jaunty image that offers selection between the two desktop setups
[18:20] <ogra> Q: If a user wanted Ubutnu Mobile on their UMPC, how would they go about installing it, and is it a relatively easy process for the user
[18:20] <ogra> yes :)
[18:21] <ogra> http://cdimage.ubuntu.com/releases/intrepid/release/ has the iage
[18:21] <ogra> and a link to instructions how to get the image onto a USB key
[18:22] <ogra> we provide a gui tool in a PPA that hopefully will join the archive in jaunty to make it easy to write usb images to usb keys
[18:22] <ogra> Q: What is the relationship between Ubuntu Netbook Remix and Ubuntu Mobile
[18:22] <ogra> the netbook remix is a remix, specifically targeting OEMs
[18:22] <ogra> the most significant difference is the set of desktop apps
[18:23] <ogra> and a set of patches to the default apps that make them work on 1024x600 pixel sized screens
[18:24] <ogra> the set of the four apps is already available in intrepid, the patches are supposed to enter ubuntu at some point and the umpc image will benefit from it
[18:24] <ogra> Q: are there any proved benefits to lpia and will ume continue to use it
[18:24] <ogra> we will review and test the benefits very closely during the jaunty release cycle, a spec is registered for this
[18:27] <ogra> currently the lpia builds include a bit more than just the kernel and toolchain changes, some apps carry patches that make them work better with hildon for example
[18:27] <ogra> to have both in x86 or amd64 flavours new binary packages would need to be created which isnt the case yet
[18:27] <ogra> thats a uge amount of work and while i cant talk for the whole team here i would assume that moving al these changes back to the normal arches will likely take more tzhan one release cycle
[18:27] <ogra> Q: wiil the ume team specialize into a flavour for eeepc, one for aspire one etc
[18:27] <ogra> no
[18:28] <ogra> what we are trying to achieve in the mobile team is the same the ubuntu distro tem does
[18:28] <ogra> we try to build something generic that runs on a special size/set of HW
[18:28] <ogra> but withing that class of devices the images should run on every device
[18:29] <ogra> the oem team that produces the netbook remix does a great job of doing device specific customization and this task will stay in their realm, the mobile team tries to achive generic enablement
[18:29] <ogra> Q: can umpc software be run on an regular pc i386 , and are there any virtualbox images to take a look at the software?
[18:30] <ogra> the current umpc image is i386 based and does all the standard gnome applications you also find on the normal ubuntu desktop
[18:31] <ogra> target of the umpc image is to just make these apps work on the screensize (i.e. for netbooks) and to make them touchscreen usable (for UMPCs)
[18:31] <ogra> Q: Is there any possibility or plans to use Ubuntu in NOKIA N810?
[18:31] <ogra> the n800/810 uses an ARM cpu, an arch for which we dont have support yet
[18:33] <ogra> theer were discussions at the last UDS about arm enablement and if it comes to an arm port at some pint that launchpad supports in the infrastructure, the desktop flavours should just run on it or be proted to it
[18:33] <ogra> that includes umpc and desktop ... and who knows, probably even -mid ... i cant predict the future :)
[18:34] <ogra> Q: how would a common base shared by both Nokia  and Ubuntu and indeed Debian look like...how can the fragmentation be
[18:35] <ogra> well, as i see it the maemo comminuty did awesome work on the maemo front, they are basically upstream for hildon and hildon2 so i would assume a possible arm build would bring the communities together to share code etc
[18:36] <ogra> but here my crystal ball starts to get blurry again, everything depends on support for arm in the infrastructure, which is not here yet :)
[18:36] <ogra> Q: is the OLPC capable for Ubuntu mobile?
[18:36] <ogra> probably ...
[18:36] <ogra> i havent tried an OLPC with it yet, but i would assume it can run at least ubuntu-mid
[18:37] <ogra> i was working personally on a classmatePC image for a while, which even was capable to run a normal edubuntu gnome desktop, so i dont see why an OLPC shouldnt be able to run something of the mobile builds which has a raher smaller footprint
[18:38] <ogra> Q: Recently there were some fuss with a high rate of netbooks rejected by customers because they couldn't install their windows apps in them (live messenger i.e.) which strateegy is planned in that front?
[18:38] <ogra> thats really a question i cant answer personally, we dont work directly on the marketing side of things with the mobile team
[18:39] <ogra> i dont even know if these claims are true nor do i know abotu such a feedback
[18:39] <FilipeRosset> hi peoples
[18:39] <ogra> Q:  Is somebody considering integrating a KDE environment like Qtopia in one of the -MID or -UMPC?
[18:40] <ogra> yes, there was recently some discussion about KDE integration in the #ubuntu-mobile channel, i think the kubuntu community is actively starting to work on something, but i dont know details beyond that
[18:40] <ogra> peobably ask in #kubuntu to get more info ... something's going on there definately :)
[18:40] <ogra> Q: is there a #ubuntu-umpc or a mailling list?
[18:41] <rugby471>  
[18:41] <ogra> not specifically ... since the mobile team works n the images, we do all our coordination in #ubuntu-mobile, feel free to join any time, we appreciate every soul in there :)
[18:42] <ogra> we also hold meetings every thursday in #ubuntu-meeting everyone is invited t join and give input
[18:42] <ogra> and ubuntu-mobile@lists.ubuntu.com is our mailing list
[18:43] <ogra> Q: What do you think about promises of the devices based on ARM and MIPS as UMPC?
[18:43] <ogra> ... i cant make any :)
[18:43] <ogra> but they would surely be great ... i'm an n800 owner myself and would appreciate to run ubuntu on it
[18:44] <ogra> Q: Which UMPC's seem to "just work" the best with Ubuntu-umpc?
[18:44] <ogra> definately the samsung Q1 Ultra as many of us in the development team own one as development platform
[18:44] <ogra> so you can largely assume this works best
[18:45] <ogra> Q: It is possible make UMPC from PDA by Ubuntu if will be ARM port?
[18:45] <ogra> that would surely be possible if there were an arm port
[18:46] <ogra> things like opie and gpe are in the archive, if the PDA is a bit bigger even the mid flavour might work on it, but that depends on an arm port indeed
[18:47] <ogra> so it looks like i ran out of questions :)
[18:48] <ogra> Q: hp is using ubuntu on its new netbooks, are there others planning the same?
[18:49] <ogra> well, there is also dell, sylvania and toshiba already
[18:49] <skate_archone> thotypous, hi, thanks for you recommendation
[18:49] <ido_> what else is in progress to make it more touch friendly ?
[18:50] <ogra> i'm not sure who else will be in the loop, thats something the oem and marketing teams might be able to answer
[18:50] <ogra> Q: what are the biggest obstacles that you're encountering at the moment?
[18:50] <ogra> well, with intrepid i personally simply found out that nothing sucks as hard as our touchscreen suport
[18:51] <ogra> as ido_ noted, there will be much work done in jaunty to solve that
[18:51] <maniacmusician> can you speak to that in a more technical sense?
[18:51] <ogra> upstream xorg is working on a unified architecture to get all touchscreens use evdev on X level
[18:51] <ogra> we plan to work closely with them
[18:52] <ogra> maniacmusician, well, there is been no proper calibration tool for example
[18:52] <ogra> the one the evtouch driver used to ship since years in debian and ubuntu didnt even work
[18:53] <ogra> my personal focus to get at least the code we ship into shape this release, the next round we'll try to work more with upstream to solve it for all possible touchsceens
[18:53] <ogra> indeed that needs your input :) we hope to get enough user feedback and testing for real massive inprovements
[18:53] <ogra> : Is LG KS20 going to be supported?
[18:54] <ogra> sorry, no idea, i would need the tech specs, feel free to drop by after the talk in #ubuntu-mobile ;)
[18:54] <ogra> QUESTION: Will the netbook versions and umpc versions be upgradeable too similar to the main distro ?
[18:54] <ogra> yes !
[18:55] <ogra> they are absolutely upgradeable like the main distro with teh intrepid image
[18:55] <ido_> is it safe to ues the auto-update feature on the umpc versions then ?
[18:55] <ogra> Q: Is there any advantage to the netbook manufacturers in using 64 bit rather than 32 bit Ubuntu releases
[18:56] <ogra> well, i personally usualy only see drawbacks in 64bit arches since you likely run into probs with flash and the like
[18:56] <ogra> which is a typically used app on netbooks
[18:56] <ogra> but thats a solely personal optinion
[18:57] <ogra> given that ATOM atm only supports 1G ram i dont see many benefits for using 64bit OSes on netbooks
[18:57] <ogra> ido_, yes it is
[18:57] <ogra> we'll make sure the images are as properly upgradeable as the main distro
[18:57] <ogra> Q: umpc devices are as powerful as a laptop -> How can you explain users having issues with HD video on a UMPC
[18:58] <ogra> ^^^ got that in PM
[18:58] <ogra> well, i simply cant without debugging ;)
[18:58] <ogra> i havent heard these issues yet
[18:58] <ogra> i personally use a dvb-t card on my samsung which works fine
[18:59] <jcastro> ok, just about out of time
[18:59] <ogra> Q:image build process in intrepid was reworked to be closer to the ubuntu infrastructure -> how about the repository infrastructure and the delays in packaging/testing for lpia, how long is the average wait between i386 and lpia and what are the limitationsor packages that can't be used on
[18:59] <ogra> lpi architechture
[18:59] <ogra> there essentially is no wait anymore now
[18:59] <ogra> apart from packages that actually get patches on the desktop level to work with hildon
[19:00] <ogra> for these indeed its a matter of integrating the hildon side of things, but that has nothing to do with the build infrastructure
[19:00] <ogra> lpia currently is a fully working arch on te build servers and packages should usually build at the same time as the i386 ones
[19:01] <Tolchi> ty ogra
[19:01] <jcastro> thanks ogra!
[19:01] <ogra> ok, seems we'Re running out of time ... so iÄll leave the stage to jorge
[19:01] <ogra> thaks everyone :)
[19:01] <jcastro> ok, bdmurray, your turn!
[19:01] <bdmurray> Welcome!  I'm here to talk to about how to report bugs about Ubuntu as there are a couple of different ways you can do it.
[19:02] <bdmurray> Additionally, I'll cover how to make your bug report more likely to get fixed!
[19:02] <bdmurray> Perhaps you are wondering what exactly is a bug?
[19:02] <bdmurray> In computer software it is an error or a flaw that makes the software behave in ways for which it wasn't designed.  Some of these can result in crashes, others may have a subtle effect on functionality, others can be spelling errors.
[19:03] <bdmurray> By reporting these issues you can help to improve Ubuntu for everyone!
[19:03] <bdmurray> To be able report a bug effectively let's take a look at what a bug report looks like.
[19:04] <bdmurray> Reported bugs are kept in Launchpad, the bug tracking system used by Ubuntu.  Let's look at a sample bug report - http://launchpad.net/bugs/291342.
[19:04] <ubot5`> Launchpad bug 291342 in update-manager "free disk space check could actually carry out suggested ways to clear space" [Wishlist,Confirmed]
[19:04] <bdmurray> There are four attributes of a bug report that I want to point out.  1) The bug's title or summary is 'free disk space check could actually carry out suggested ways to clear space'.
[19:05] <bdmurray> 2) In the Affects table you'll see that this bug report affects 'update-manager (Ubuntu)' this is the package / application which the bug report is about.
[19:05] <bdmurray> 3) Bug's have a "description" which is filled out when you are reporting a bug.
[19:06] <bdmurray> 4) You'll also notice that the bug's status is Confirmed.
[19:06] <bdmurray> The status also appears in the affects table.
[19:07] <bdmurray> Are there any questions regarding what a bug report looks like?
[19:09] <bdmurray> < snapy> QUESTION:  What are tags?
[19:09] <bdmurray> Bug tags provide another way of identifying and searching for bug reports in Launchpad.  You can find some common ones that we at http://wiki.ubuntu.com/Bugs/Tags.
[19:10] <bdmurray> For example screencast is a tag used when a bug has a screencast attached to it.
[19:10] <bdmurray> < yusuf_> QUESTION: What is the comments setion for?
[19:11] <bdmurray> Comments are used to communicate information between the bug reporter and bug triagers or developers.  For example a triager might request more information about the bug.
[19:12] <bdmurray> So how can you report a bug about Ubuntu in Launchpad?
[19:12] <bdmurray> They can be reported via the web interface at https://bugs.launchpad.net/ubuntu/+filebug where you start by filling out the summary which becomes the bug's tile.
[19:13] <bdmurray> After which you are asked for the package affected and for 'Futher information' which becomes the bug's description.
[19:13] <bdmurray> The description should contain at a minimum the following:
[19:14] <bdmurray> 1) The release of Ubuntu that you are reporting the bug about.
[19:14] <bdmurray>  2) The version of the package you are reporting the bug about.
[19:14] <bdmurray> 3) What you thought should happen.  and 4) What happened instead.
[19:14] <bdmurray> You also have the opportunity to add an attachment to your bug when you are reporting it via the web interface.
[19:14] <bdmurray> Another way to report a bug is using apport, an automated problem report application included with Ubuntu.
[19:15] <bdmurray> The advantage to using apport is that it automatically collects information about the release of Ubuntu you are using and the version of the package / application that you are reporting the bug about.  This means less work for you!
[19:15] <bdmurray> Let's say that you have encountered a bug with gnome-terminal.  You can use apport to report the bug by going to gnome terminal's "Help" menu and choosing "Report a Problem".
[19:15] <bdmurray> Apport will start collecting information about your bug and then launch your browser where you enter the bug's summary / title and then enter the bug's description.
[19:16] <bdmurray> An example of a bug reported using the "Report a Problem" menu item is http://launchpad.net/bugs/292885.  Looking at that bug you'll see information in the description regarding the DistroRelease, the package and version, and kernel version among other things.
[19:16] <ubot5`> bdmurray: Error: Could not parse data returned by Launchpad: The read operation timed out
[19:16] <bdmurray> All of which was collected automatically for you.  The "Report a Problem" functionality has been integrated into lots of applications.
[19:17] <bdmurray> Speaking of tags you'll also notice that bug is tagged apport-bug.
[19:17] <bdmurray> Apport also has a command line interface, called apport-cli, where you can report a bug about a specific package via 'apport-cli -f -p PACKAGE' which is useful for non GUI applications for example gdm (gnome-display-manager) or X.
[19:18] <bdmurray> Additionally, you can also specify a process id number via 'apport-cli -f -P PID'.
[19:18] <bdmurray> Using apport is the preferred way to report bugs as they contain detailed information about the application and your system.  Further information about reporting bugs can be found at https://help.ubuntu.com/community/ReportingBugs.
[19:19] <bdmurray> < ogzy> QUESTION: what does a triager do?
[19:20] <bdmurray> This will be addressed more tomorrow when pedro_ gives a class on triaging bugs.  However, a triager helps gather more information to make the bug report complete so it can start being fixed!
[19:21] <bdmurray>  < Kolyan_ufalug_> QUESTION: How do you think should be written
[19:21] <bdmurray>                         the ideal bugreport? What do you think of
[19:21] <bdmurray>                         beginners who are not able to report bugs
[19:21] <bdmurray>                         right?
[19:21] <bdmurray> The ideal bug report should contain information about the release of ubuntu, the package version affected, and detailed steps for someone else to recreate the bug.
[19:22] <bdmurray> The steps to recreate the bug, or the test case, is critical so someone else can confirm the bug report.  Bugs that are unreproducable are often hard to fix!
[19:23] <bdmurray> < ogzy> QUESTION: so triager and bug fixer are different people?
[19:23] <bdmurray> No, not necessarily.  Think of them more as roles.  A developer fulfills the role of a triager when they are gathering information to start working on the report.
[19:24] <bdmurray> Moving on - how can we make our bug reports more useful for triagers and developers?
[19:24] <bdmurray> Choosing the affected package or application the bug is about is critical.  Please don't submit bugs with out a package!
[19:25] <bdmurray> We have about 1500 of these right now and your report might get lost there or will be responded to less quickly.
[19:25] <bdmurray> Some helpful hints for finding the proper package are at https://wiki.ubuntu.com/Bugs/FindRightPackage.
[19:25] <bdmurray> This page also contains the names of packages that might be hard to discover.  For example, bugs about the kernel in Intrepid Ibex should be reported about 'linux' in Launchpad.
[19:26] <bdmurray> Also feel free to join the #ubuntu-bugs channel on Freenode and ask for help in finding the proper package.
[19:26] <bdmurray> An important part of a bug's life cycle is it entering the Confirmed status.
[19:26] <bdmurray> When a bug is Confirmed it means that someone has been able to recreate the bug or believes sufficient information has been included in the bug report for a developer to start working on it.
[19:27] <Tamass> cool, openweek
[19:27] <Tamass> :)
[19:27] <bdmurray> Any Launchpad user can confirm a bug report, but please don't confirm your own!  It is important that someone else is able to recreate the bug and that we know it is not specific to your configuration.
[19:27] <bdmurray> In practical terms - this means that you should include extremely detailed steps to recreate the bug in it's description so anyone, not just a developer, could confirm it.
[19:28] <bdmurray> It is far better to have too much detail than not enough!
[19:28] <bdmurray> There is another bug status named 'Triaged' which is an advanced state of 'Confirmed'.  You can learn more about bug statuses at http://wiki.ubuntu.com/Bugs/Status.
[19:29] <bdmurray> Some fairly simple things you can do to make your bug report easier for someone to confirm or triage your bug are including a screenshot, via Print Screen, or creating a screencast, using istanbul or gtk-recordmydesktop.
[19:29] <bdmurray> Including these items makes it that much easier for anyone to confirm your bug report.
[19:30] <bdmurray> An example of a bug with a screencast is http://launchpad.net/bugs/212425 - watching the screencast helps one better understand how to recreate the bug.
[19:30] <ubot5`> Launchpad bug 212425 in libwnck "Desktop selector does not change on having positioned a file on" [Low,Confirmed]
[19:30] <bdmurray> Additionally, the best way to make your bug report more likely to be fixed is to follow the debugging procedures for the package or subsystem the bug is about!
[19:31] <bdmurray> These have been written by bug triagers or the developer of the software and following them will help you create a more detailed bug report.
[19:31] <bdmurray> You can find the list of debugging procedures at https://wiki.ubuntu.com/DebuggingProcedures.
[19:32] <bdmurray> Looking at some more questions ...
[19:32] <bdmurray> < gourgi> QUESTION:what is the difference between "This bug  doesn't affect me" and "Subscrive to bug" ? do both  provide update notifications?
[19:33] <bdmurray> If you change a bug report to 'This bug affects me' that information gets recorded in the Launchpad database.  It is an easy way of saying me too.
[19:33] <bdmurray> However, you are not subscribed to the bug report when you do that.
[19:34] <bdmurray> When you subscribe to a bug report you will receive e-mail notifications regarding changes to the bug report whether they be questions asked or packages available for testing the fix to the bug report.
[19:34] <bdmurray> < madmetal_spyros> QUESTION: How important for the team is  Apport?
[19:35] <bdmurray> apport is a very important application to bug triagers and the Ubuntu development team.  It is always being improved to submit higher quality bug reports.
[19:37] <bdmurray> < kippy> QUESTION: You mentioned a Bug is a behaviour which the  software was not designed to perform. So how can we  classify the "update manager should suggest ways of  freeing up disk space" as a bug? I mean its more of an  improvement, as the importance=wishlist points up. So  does this mean we can suggest improvements via bug  reports? and what does "Assigned To" contains and
[19:37] <bdmurray>  signiies on the bug greport page?
[19:38] <bdmurray> Some improvement bug reports do belong in Launchpad.  It depends on the scope of the improvement and whether or not the application is something is developed by Ubuntu developers - which update-manager is.
[19:39] <bdmurray> Some ideas, like changing default applications, are best reported at http://brainstorm.ubuntu.com/.  There they can be more fully fleshed out and voted on by community members.
[19:40] <bdmurray> Assigned to means that somebody is working on fixing a bug report.
[19:41] <bdmurray> < grml> QUESTION: Before I report a Bug, I have to check if this  Bug is already reported. How can I list the already  reported Bugs for a given package and/or for a given  Ubuntu Release, please?
[19:41] <bdmurray> This is a great question!  Thanks for asking it.  We get a lot of duplicate bug reports in Launchpad and it helps a lot if reporters would first look to see if the bug is already reported.
[19:43] <bdmurray> For example, lets say we are having an issue with rhythmbox.  We can find bugs reported about rhythbox at https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bugs.
[19:44] <bdmurray> Now we can enter a string in the search box like 'mtp' and click search to find rhythmbox bugs about mtp.
[19:46] <bdmurray> Let's say bug 235726 is the bug I'm experiencing.  I could subscribe to that bug report to receive information about how the bug is progressing.
[19:47] <bdmurray> Additionally, you might notice that this bug doesn't really have a specific package version in it and hasn't been tested with Intrepid.  So if it were your bug you could test it with Intrepid and add your findings to the bug report.
[19:47] <bdmurray> You should include complete details as if you were reporting it as a new bug.  So the release and the specific package version.
[19:49] <bdmurray>  < AnAnt> QUESTION: sometimes I report a bug, and it I get no
[19:49] <bdmurray>                response for it for long time (maybe more than a
[19:49] <bdmurray>                month), what should I do to grab attention to a bug ?
[19:50] <bdmurray> AnAnt: It really depends on the bug.  However, testing it with the latest version of the package can help.  Finding a friend to recreate the bug report and subsequently confirming it would help.  Additionally, not all software included with Ubuntu is developed by us.
[19:51] <bdmurray> So one could report the bug to the upstream bug tracker (for example gnome in the rhythmbox case we were using eariler) and then link your Ubuntu bug report to the upstream bug report.
[19:52] <bdmurray> < toobaz> QUESTION: do programs which use apport trigger it only  when they "die abruptly" or do programmers decide to  make a call to it just when the code itself detects  things are non behaving right?
[19:54] <bdmurray> apport detects application crashes and automatically reports them for the development release of Ubuntu, so programmers don't need to anything.  However, for the "Report a problem" functionality developers can include apport hooks in their package for files to be included in the bug report.
[19:54] <bdmurray> For example, X bug reports include '/etc/X11/xorg.conf' and '/var/log/Xorg.0.log' and maybe some other things.
[19:55] <bdmurray> Are there any further questions?
[19:56] <maiopirata> hi bdmurray
[19:56] <maiopirata> I've one little problem with the wireless
[19:56] <bdmurray> maiopirata: Hi, if you have a question can you ask it in #ubuntu-classroom-chat ?
[19:56] <maiopirata> ok thanks
[19:57] <bdmurray> < spielmannsfluch> QUESTION: What about bugs in  packages/programms not developed by the  ubuntu team, should I report these bugs to  launchpad, too?
[19:58] <jcastro> almost out of time!
[19:58] <bdmurray> If there are included with Ubuntu yes.  This will allow bug triagers and or developers to help you determine if the bug is Ubuntu specific.  Additionally, there are triagers who run upstream versions of software who can test it with the upstream version.
[19:59] <jcastro> ok we're out of time
[19:59] <jcastro> thanks bdmurray!
[20:00] <bdmurray> We've covered some ways to submit higher quality bug reports about Ubuntu.  However, if you need any help reporting a bug, or finding the right package to report a bug on, or finding out if your bug is a duplicate, you can find members of the Ubuntu bugsquad in the #ubuntu-bugs IRC channel.
[20:00] <bdmurray> Thanks everyone!
[20:00] <jcastro> ok emmajane, take it away!
[20:00] <emmajane> Awesome! :)
[20:00] <AnAnt> thanks
[20:00] <emmajane> Hi everyone!
[20:00] <emmajane> In this next session I'm going to walk you through the very basics of setting up the world's best revision control system: Bazaar!
[20:01] <emmajane> Who's up for a little bit of version control?! :)
[20:01] <alucardni> +1 emmajane
[20:01] <Megaqwerty> wohoo!
[20:01] <barcc> +1
[20:01] <emmajane> Woo!
[20:02] <emmajane> This session has six parts: (1) A little bit about Bazaar, (2) Installing Bazaar, (3) Initializing a repository (aka Creating a time machine), (4) Going back in time, (5) Downloading files from Launchpad and (6) Resources.
[20:02] <NetSKaVeN> emmajane for president!!
[20:02] <emmajane> In the next session you will learn how to use Bazaar to maintain a package in Launchpad.
[20:02] <emmajane> I have the notes typed out if you are interested in reading ahead, please keep your questions to the topic at hand though, thanks!! http://pastebin.ubuntu.com/66913/
[20:02] <emmajane> Ok! Let's get started!
[20:02] <emmajane> Topic 1/6: A little bit about Bazaar
[20:03] <emmajane> Bazaar is a distributed version control system that Just Works. Bazaar adapts to the workflows you want to use, and it takes only a few minutes to try it out.
[20:03] <emmajane> Bazaar is used by all kinds of project teams to maintain all the changes that are made to the underlying code by each developer. In fact the code for the data base MySQL is stored in Bazaar! And Ubuntu is working towards putting 15,000 packages into Bazaar! These are HUGE projects!
[20:03] <emmajane> It can be used by real people too though. I like to think of myself as more of a "real person" than a "hardcore ninja developer." I use Bazaar because it's really good, but also because the support community is AMAZING. People have answered questions at all hours of the day in the IRC channel #bzr.
[20:03] <emmajane> Whether you're a hardcore ninja developer, or a real person, you can take advantage of version control for your work.
[20:04] <emmajane> (Apparently ninjas are real people too though.) ;)
[20:04] <emmajane> It can be useful to put all kinds of files under version control. For example: your configuration files, your resume, or any other kind of file that you might want to see a "historical" snapshot of.
[20:04] <emmajane> For example: I'm a freelance Web developer. I'm doing work on a client site and all of a sudden I get brand new files from the graphic designer that change everything. I could start a new folder, but that leaves a lot of junk lying around on my computer. Instead I use all the new files in my project (overwriting the old ones), but with Bazaar there is a secret "history" folder that allows me to go back and look at the old versions of the fil
[20:04] <emmajane> e whenever I want.
[20:04] <emmajane> I like to think of Bazaar as the biggest, baddest UNDO button my computer has ever known.
[20:05]  * emmajane pauses for people to catch up. :)
[20:05] <emmajane> all good? :)
[20:06] <NetSKaVeN> sure
[20:06] <zever> yes
[20:06] <kippy> O:-)
[20:06] <emmajane> awesome. :)
[20:06] <tamrat> \o/\o/
[20:06] <emmajane> Topic 2/6: Installing Bazaar
[20:06] <emmajane> I'm going to assume that everyone is already using Ubuntu?
[20:07] <emmajane> We will be working from the command line for most of this session. I am very comfortable at the command line so if I go too quickly, please jump up and down and tell me! I have used the convention of $ to mean start typing a command. If you look at your command line you will see that it ends with a $. Mine looks like this:
[20:07] <emmajane> emmajane@gollum:~$
[20:07] <emmajane> If you are using GNOME you can open a new terminal window by navigating to:
[20:07] <emmajane> Applications (top left of your screen) -> Accessories -> Terminal.
[20:07] <emmajane> If you are using KDE you can open a new terminal window by navigating to:
[20:07] <emmajane> System -> Terminal Program (Konsole)
[20:07] <emmajane> If you are using a different desktop environment you are probably already a super 1337 haX0r that knows how to find a terminal window, but please let me know if you need more help!
[20:08] <emmajane> Let me know if you can't find a terminal window....
[20:09] <emmajane> Sounds like we're all good?
[20:09]  * emmajane welcomes LarstiQ from #bzr :) (I told you they were helpful!! :) )
[20:09] <emmajane> Now that you are at the terminal window you will see something similar to my command line that I displayed above. We are now going to install Bazaar. I chose to do this from the command because that's where we'll be running the commands. You could also use the Synaptic Package Manager to do this installation.
[20:10] <emmajane> To install Bazaar we are going to use a package manager called apt-get. It install a package it uses the structure: apt-get install PACKAGENAME. You must be the super user of your system to run this program we will use the "sudo" command instead because it's faster and because this comic is funnier if you know about sudo:  http://xkcd.com/149/
[20:10] <emmajane> $ sudo apt-get install bzr
[20:10] <emmajane> You will be prompted for your password. If there are multiple accounts on your computer you may not be in the sudo group. You can switch to the root user if 'sudo' doesn't work for you.
[20:11] <emmajane> Let me know when you've successfully run that command.... or if you're having problems getting Bazaar installed...
[20:11] <NetSKaVeN> all ok here
[20:12] <emmajane> awesome, NetSKaVeN :)
[20:12] <kippy> waiting for download to complet...
[20:12]  * emmajane nods to kippy
[20:12] <kippy> Its done :)
[20:12] <alucardni> waiting for apt-get to finish the installation process
[20:13] <lobo-ptr> like a charm
[20:13] <emmajane> alucardni: cool :)
[20:13] <emmajane> w00t! I like charms, lobo-ptr :)
[20:14] <emmajane> I've got a little bit more installation information, if you're not done yet, that's ok. You're not missing anything. :)
[20:14] <alucardni> ok, done
[20:14] <emmajane> Assuming that worked you should now have Bazaar installed on your system. You can test this with the following command:
[20:14] <emmajane> $ bzr
[20:14] <emmajane> You should get a list of Bazaar commands. Note: Bazaar is the name of the application and bzr is the actual command that you run.
[20:14] <emmajane> If you want to have a pointy-clicky browser to make these changes you can also install "Olive." This program has the package name: bzr-gtk. You can install it with the following command:
[20:15] <emmajane> $ sudo apt-get install bzr-gtk
[20:15] <emmajane> How's everyone doing so far? Ready to start taking snapshots of your files?
[20:15] <NetSKaVeN> sure
[20:15] <LordDicranius> yep :)
[20:15] <alucardni> +1
[20:15] <kippy> Yep, with CLI :)
[20:15] <ogzy> +1
[20:16] <emmajane> awesome :)
[20:16] <emmajane> Topic 3/6: Initializing a Repository (aka Creating a Time Machine)
[20:16] <emmajane> For the next part I want you to choose a directory that has files you *know* you should be keeping in better order. This might be an application that you've been hacking away on, or your resume folder, or whatever!
[20:16] <emmajane> We could also invent some files if you wanted to, but I think it's nice to work with files you know.
[20:16] <emmajane> Change directory to the folder that has the files you want to put under revision control. I am going to work in the folder that contains the files for the Web site riversideyarns.com. I use the following command to move to that directory:
[20:16] <emmajane> $ cd websites/riversideyarns.com
[20:16] <emmajane> Remember that you can use the tab button to finish typing each of the words. Type the first letter of the file name and then press the tab key. It will type the rest of the word for you. Of course if there are more than one files that start with the same letter you will need to type a few more letters before hitting tab again.
[20:17] <emmajane> Once you have changed to your working directory you can create a new "repository" of your files. A repository is a place where data are stored and maintained. This folder will no longer be a simple set of files. It will be an uber awesome time machine that lets you travel back in time to see old versions of your files.
[20:17] <emmajane> To start the time machine, I mean initialize the repository, use the following command:
[20:18] <emmajane> $ bzr init
[20:18] <fukazzz> fazzuk: nice nick :D
[20:18] <emmajane> It's sort of like a magic trick because you won't see anything happen. This command creates a hidden time machine in your current directory.
[20:18] <fukazzz> it seems very familiar...
[20:18] <emmajane> You can confirm it is there with the following command:
[20:18] <emmajane> $ ls -al
[20:18] <emmajane> Do you see the .bzr folder? That's your time machine!
[20:18] <moreati> ls
[20:18] <ciprian_topala> yeap it's there
[20:19] <emmajane> excellent, ciprian_topala :)
[20:19] <kippy> does bzr init require sudo?
[20:19] <emmajane> kippy: nope.
[20:19] <emmajane> kippy: you get to be a regular person for this part. :)
[20:20] <kippy> :)
[20:20] <emmajane> Has everyone got their time machine?
[20:20] <alucardni> it worked!!
[20:20] <emmajane> I mean .bzr folder?
[20:20] <tamrat> yep
[20:20] <kippy> yep
[20:20] <biomass> yea
[20:20] <emmajane> woo :)
[20:21] <emmajane> For the next step you need to add all your files into the time machine. Use the following command:
[20:21] <emmajane> $ bzr add
[20:21] <emmajane> Bazaar will tell you that it has added the files to the time machine. Next you will need to lock and load the time machine. This allows you to jump back to this point in history. In Bazaar-speak this is referred to as "committing your changes."
[20:21] <emmajane> You must add a little message each time you commit your files. This lets you know what happened at this point in history (and makes it easier to jump back in time to exactly the right point). Be descriptive in your commit message. Use the following command:
[20:21] <emmajane> $ bzr commit -m "Adding files to the time machine for the very first time."
[20:22]  * x_dimitri got zapped to back to 1969 by his bzr time machine
[20:22] <emmajane> SHAZAAM! Your time machine is ready to go!
[20:22] <emmajane> x_dimitri: oh dear. :) an actual error? Or just a UNIX joke? :)
[20:23] <x_dimitri> just kidding :-)
[20:23] <emmajane> kay :)
[20:23] <emmajane> phew :)
[20:23]  * x_dimitri is as fine as... um... the linux kernel?
[20:23] <emmajane> haha
[20:23] <ogzy> can we continue?
[20:23] <emmajane> You can now edit your files and continue "committing" changes. Remember Bazaar is like an undo button. You want to be able to "undo" small changes, and not lose a bunch of work because you undid too much.
[20:23] <emmajane> Try editing one of your files and committing the changes. Once you've edited a file you can commit the change into the revision history with:
[20:24] <kippy> difference b/w add and commit?
[20:24] <x_dimitri> good to see there's good humour around here
[20:24] <x_dimitri> please proceed
[20:24] <Flimm> People, chat belongs to #ubuntu-classroom-chat , not here
[20:24] <emmajane> kippy: "add" tells bzr about the files. You only use it once to add each new file.
[20:24] <emmajane> (or you can add files in bulk, like we just did)
[20:25] <emmajane> commit, on the other hand, is how you mark each set of changes so that you can jump back to that point in history.
[20:25] <emmajane> kippy: does that make sense?
[20:26] <emmajane> Try editing one of your files and committing the changes. Once you've edited a file you can commit the change into the revision history with:
[20:26] <emmajane> $ bzr commit -m "A descriptive message with a summary of the changes you made."
[20:27] <emmajane> I would like everyone to try editing one or two files in the directory they're in and "committing" the changes.
[20:27] <alucardni> emmajane: done
[20:27] <emmajane> The next step is to learn how to go back in time, but you need to have edited the files to believe that you really are going back.
[20:27] <emmajane> If you do a few edits and a few commits you will have more to look at in your logs (which is the next step).
[20:28] <emmajane> I'll give everyone three minutes to do this.
[20:28] <emmajane> This would be a good time to ask questions if you have some at this point as well.
[20:29] <ciprian_topala> does bazaar commit too newly created files that didn't exist at the initial commit?
[20:30] <anthony> emmajane: Are you getting the questions from -chat in any way?
[20:30] <emmajane> anthony: I just joined that channel. So people will need to repeat them.
[20:30] <emmajane> ciprian_topala: you have to explicitly add any new files. Otherwise Bazaar will ignore them.
[20:31] <emmajane> Ok. That's the three minutes.
[20:31] <emmajane> Hopefully everyone's done some editing by now?
[20:31] <NetSKaVeN> o/
[20:31] <Tonio__>  yep
[20:31] <emmajane> woo!
[20:31] <LordDicranius> yep
[20:31] <emmajane> Topic 4/6: Going back in time
[20:31] <ogzy> yes
[20:31] <emmajane> Mistakes happen. What if you need to UNDO some changes you've made? You can go back in time and restore your files to a previously saved version.
[20:31] <emmajane> To undo mistakes there are two commands you need to know: revert, and uncommit. But before we start undoing things, let's read the history books to see where we want to travel back in time to....
[20:32] <emmajane> $ bzr log
[20:32] <emmajane> This command lets you see the revision history for the commits you've made to your repository. if you are working with text files you can also look to see what the EXACT changes were between two versions of a file with the "diff" command. To compare from a previous version to the current one, use the following command
[20:32] <emmajane> $ bzr diff -r# FILENAME
[20:32] <emmajane> Replace the # with the "revno" from your log.
[20:32] <emmajane> In the text that is spit out look for the lines that have - and + at the beginning of the lines. The - means the line was removed; the + means the line was added.
[20:33] <emmajane> (This won't work as expected for binary files such as images and OpenOffice.org documents.)
[20:33]  * emmajane pauses to give people a chance to read their history books... I mean logs.
[20:34] <emmajane> I'm going to answer some questions while you're working on that.
[20:34] <mulamanca> quit]
[20:34] <emmajane> rgreening	QUESTION: Is there a qt/KDE equivalent to the bzr-gtk?
[20:34] <mulamanca> exit
[20:34] <mulamanca> quit
[20:35] <emmajane> Hm. Not that I'm aware of. Does anyone else know?
[20:35] <weboide> qbzr
[20:35] <cyphermox> that was brought up in the -chat channel. it seems there is qbzr
[20:35] <LarstiQ> there is
[20:35] <emmajane> excellent!
[20:35] <emmajane> Kolyan_ufalug_	QUESTION: What current status of bazaar speed? When my familiar developers looked at last time bazaar they have said it was not very fast in comparsion to other systems. I know that this is not critical in small projects but big projects also interest.
[20:35]  * LarstiQ is a bit slow to react, sorry for that
[20:36] <emmajane> Kolyan_ufalug_: it's fast enough for MySQL.... specific benchmarking questions could be directed to the mailing list though. I believe it depends on the complexity of the project.
[20:36] <emmajane> presi	QUESTION: I feel confortable with GNU Arch, but seems a bit unmantained so I'm thinking about moving to bazaar, can I work with bazaar in the same way as with arch, that is with working trees separate from repositories?
[20:37] <LarstiQ> Yes, you can with lightweight checkouts.
[20:37] <emmajane> presi: I think you mean branches? Yup, you can do branches in Bazaar. You'll learn that in the next session.
[20:37] <emmajane> moreati	QUESTION: bzr add and bzr commit resulted in the same messages (added foo.bar) is the commit necessary or does bzr add do an implicit commit?
[20:38] <emmajane> moreati: Yup, the commit is necessary. This locks your changes into Bazaar.
[20:38] <kippy> why so many version control systems like SVN, GIT and BAZAAR ? which one is more advantageous in what kind of situations?
[20:38] <emmajane> kippy: Why so many Linux distros?
[20:39] <kippy> why?
[20:39] <emmajane> kippy: each has advantages for different projects. Personally I go with the system that has the best and most active community.
[20:39] <LarstiQ> To explore different approaches, mainly.
[20:39] <emmajane> Ok. Back to the classs. :)
[20:39] <emmajane> This command lets you see the revision history for the commits you've made to your repository. if you are working with text files you can also look to see what the EXACT changes were between two versions of a file with the "diff" command. To compare from a previous version to the current one, use the following command
[20:39] <emmajane> $ bzr diff -r# FILENAME
[20:39] <emmajane> Replace the # with the "revno" from your log.
[20:39] <emmajane> (I think this might be review?)
[20:40] <emmajane> In the text that is spit out look for the lines that have - and + at the beginning of the lines. The - means the line was removed; the + means the line was added.
[20:40] <emmajane> (And this should be new...)
[20:40] <emmajane> To compare two versions in history use the following command:
[20:40] <emmajane> $ bzr diff -v -r#..# FILENAME
[20:40] <emmajane> Note the two dots between the revision numbers. These are important.
[20:40] <emmajane> To move back in time to the last commit (i.e. UNDO only the current changes) use the command "revert." This will take you back to the previously committed changes. This will change all files that have been updated since the last commit.
[20:40] <emmajane> $ bzr revert
[20:41] <emmajane> To go one step further back and undo the last commit of your files, use the "uncommit" command like so:
[20:41] <emmajane> $ bzr uncommit
[20:41] <emmajane> If you want to go back to a very specific version number, you can use the revert command as well as the revision number:
[20:41] <emmajane> $ bzr revert -r #
[20:41] <emmajane> Remember to COMMIT your changes when you go back in time. You must "save" your new location in time by committing the new snapshot into your revision history. Once you've restored your files to the right version, use the commit command like this:
[20:41] <emmajane> $ bzr commit -m "Undoing bug fixes from previous revision. Reverts files back to feature set YXZ."
 emmajane: QUESTION: Is there a uncommit like thing that preserves version history, say, for branches that are always-public?
[20:43] <emmajane> I'm pretty sure that the history isn't deleted, it's the file that's returned to that state...
[20:43] <LarstiQ> well
[20:43] <emmajane> someone else might be able to correct me on that though.
[20:43] <LarstiQ> Once you use uncommit (or rebase) the old revision is destroyed and you can then make a new one.
 QUESTION: We have to revert and uncommit to make changes to a previous version of a file?
[20:44] <emmajane> alucardni: Nope. Choose right tool for the job.
[20:44] <emmajane> Do one OR the other.
[20:44] <LarstiQ> mbt: so doing that will impact other people's ability to interact with your branch
[20:44] <emmajane> There is more information in the Bazaar User Manual at: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#undoing-mistakes
[20:44] <LarstiQ> (and in #bzr :)
[20:45] <emmajane> (That's just more information for "UNDO" althoug the full user manual is there)
 emmajane: uncommit seems to delete history
[20:46] <emmajane> weboide: correct. uncommit completely UNDOES the last commit.
[20:46] <emmajane> As if it NEVER HAPPENED!
[20:46] <emmajane> (How cool would it be to have THAT in real life?!)
[20:46] <emmajane> revert is a little more polite. :)
[20:47] <emmajane> There is more information on the differences in that link I gave you above.
[20:47] <emmajane> What you've had so far are the basics for working with your own files.
[20:47] <emmajane> Hopefully people have had a chance to edit their own work and see the log files and revert changes and basically muck around a bit.
[20:48] <LarstiQ> To stress that, using uncommit on a branch you have published is not recommended.
[20:48] <emmajane> The next part will set you up for Part Two of Bazaar in the next session.
[20:48] <LarstiQ> But you _can_ do it if you have to.
[20:48] <emmajane> Topic 5/6: Working with Launchpad
[20:48] <emmajane> There is one last thing I want to show you today. And that's how to get a repository from Launchpad. In the next session you will learn all kinds of fantastic things that you can do with real code, but first I want to show you how to get that code into your computer.
[20:49] <emmajane> The first thing I want you to do is change directories into a play area. This might be in your home directory, or on your desktop. To change to your home directory use the following:
[20:49] <emmajane> $ cd
[20:49] <emmajane> To change directories to your Desktop use the following command:
[20:49] <emmajane> $ cd ~/Desktop
[20:49] <emmajane> Here are two different ways to grab a repository from Launchpad. You can either use the URL for the project, **or** use the Launchpad project name. You don't need to do both. Let's take a look at the two commands:
[20:49] <emmajane> $ bzr checkout https://launchpad.net/terminator
[20:50] <emmajane> $ bzr checkout lp:terminator
[20:50] <emmajane> Both of these commands will do the same thing. The "lp" version will (obviously) only work for projects that are available in Launchpad. But the first version will work for any URL on the internet that has a .bzr folder in the same directory. (You can probably see the advantages and disadvantages of this!)
[20:50] <emmajane> Choose one method now and download the "terminator" project.
[20:51] <emmajane> In other words perform a "checkout" using either the URL for the project *or* the lp project name.
[20:51] <emmajane> It may take a little while for the terminator project to download. You will be using these files for the "advanced" Bazaar session coming up next.
[20:51] <guest12344321> what is terminator project?
[20:52] <emmajane> guest12344321: You'll have to ask bobbo :)
 QUESTION: is there a shortcut (like lp) for gnome projects?
[20:52] <emmajane> gQuigs: As far as I know there is not. But, again, I've been wrong before. ;)
[20:53] <james_w> gQuigs: there is a plugin to provide it floating around
[20:53] <jcastro> most of the time bzr checkout lp:nameofgnomeproject will work
[20:53] <james_w> the main problem is that GNOME only uses bzr for a few things at the moment, but as jcastro said launchpad has bzr mirrors of most of the projects
[20:54] <emmajane> While you're downloading the project (you saw how easy it was compared to CVS?!) I'm going to plunk in some resources to wrap up this session, but please start asking me questions as well!!
[20:54] <emmajane> Topic 6/6: Resources
[20:54] <emmajane> There are lots of resources to learn more about Bazaar. I personally use the following a lot:
[20:54] <emmajane> The Bazaar Web site. http://bazaar-vcs.org/ Here you will find good documentation as well as useful plugins. I use the "upload" plugin for my Web work as well as bzr_push_and_update.
[20:54] <emmajane> The built-in documentation is really good too. You can check the "man" pages with $ man bzr  OR get a list of all the commands in bzr with: $ bzr --help commands
[20:55] <emmajane> And that's all I've got.
[20:55] <emmajane> Not bad timing, eh? :)
[20:55] <NetSKaVeN> great time!!
[20:55] <james_w> "bzr help topics" is good too
[20:56] <james_w> and #bzr and bazaar@lists.canonical.com of course
[20:56] <presi> very basic but usefull class
[20:56] <jcastro> presi: don't worry, we're getting into advanced topics next
[20:56] <presi> ok
[20:57] <jcastro> bobbo: let's take a few minutes for a break and then begin?
[20:57] <bobbo> jcastro: sure
[20:57] <thiebaude> good job,emma
[20:57] <jcastro> \o/ emmajane!
[20:57] <emmajane> bobbo: they should all have terminator downloaded for you. :)
[20:57] <bobbo> emmajane: good stuff :D Thanks alot!
[20:58] <james_w> bobbo: just remember they have a checkout, not a branch :-)
[20:58] <emmajane> jcastro: thanks :)
[20:58] <bobbo> james_w: you've confused me already :P
[20:58] <james_w> what's bzr?
[20:59] <knome> what's what?
[20:59] <jcastro> ok, moving on with bazaar still, but now into more advanced topics
[20:59] <jcastro> this is the last session of the day
[20:59] <jcastro> so basically we can go until bobbo passes out.
[20:59] <knome> \o/
[20:59] <jcastro> take it away bobbo!
[20:59] <LordDicranius> lol
[20:59] <knome> any beer served?
[21:00] <bobbo> thanks jcastro :D
[21:00] <bobbo> right hey everyone!
[21:00] <thiebaude> yup,knome i have heineken now:)
[21:00] <emmajane> I'll stick around in -chat as well if people still have beginner questions. :)
[21:00] <bobbo> Now Emma Jane has covered the basics of using Bazaar, I'm going to go into a little more detail and show you some of the more
[21:00] <bobbo> complex things you can do with Bzr, including branching, merging and tagging.
[21:00] <NetSKaVeN> hi bobbo
[21:00] <bobbo> so everyone ready to get started?
[21:00] <thiebaude> hi bobbo
[21:01] <Megaqwerty> go for it!
[21:01] <bobbo> right, before we get properly started this session is called "Beyond The basics" but we wont go into the hardcore details that will bore you all to death
[21:01]  * NetSKaVeN is ready
[21:01] <bobbo> instead i'll show you some cool practical stuff, that will hopefully help you in using bzr
[21:02] <bobbo> if you havent done so already plese run "sudo apt-get install bzr bzr-tools" to get bzr and bzr-tools installed
[21:03] <LarstiQ> Shouldn't that be bzrtools without the dash?
[21:03] <bobbo> shout when its installed and you are ready to go
[21:03] <bobbo> LarstiQ: probably!
[21:03] <NetSKaVeN> without dash, all ok here
[21:03] <moreati> ready
[21:03] <Tonio__> ok for me
[21:03] <bobbo> ok onto section 1 : Branching and Merging
[21:03] <meastp> yup
[21:04] <bobbo> Branching & Merging are two of the core concepts in Bzr.
[21:04] <bobbo> A branch is "an ordered set of revisions that describe the history of a set of files". A bit of an abstract and confusing concept if you have never worked with bzr before, but it will all become clear after using it for a little.
[21:05] <bobbo> a branch can also be described as "a line of development for a project"
[21:05] <bobbo> A merge is simply taking code from one branch and joining (merging) it with another. Here is an example workflow to help you understand:
[21:05] <bobbo>   1 - Project foobar is a little command line application with a "trunk" bzr branch
[21:05] <bobbo>    2 - A developer decides it needs a gui, so creates a new branch, based on the old "trunk" branch
[21:05] <bobbo>    3 - The GUI developer works on the GUI until it is ready to go into the main project code
[21:05] <bobbo>    4 - Another developer checks the code, decides it is ok and merges it into the trunk. So now the trunk has:
[21:05] <bobbo>             - All the original code (from before the GUI work started)
[21:05] <bobbo>             - All the code from the GUI branch
[21:05] <bobbo>             - Any changes that have been made in trunk since the GUI branch was created (more on this in a second)
[21:06] <bobbo> If that (not so awesome) description flies right over your head, heres a shiny diagram i made earlier (ignore the big black things, I have no idea what Inkscape was up to earlier): http://bobbo.me.uk/ubuntu/openweek/bzr-branching-merging.svg
[21:07] <bobbo> shout if you understand and want to move on, or dont get it and want some more explanation :D
[21:07] <lobo-ptr> let's move on ;)
[21:07] <NetSKaVeN> o/
[21:07] <johnsgruber> ok
[21:07] <meastp> yeah
[21:08] <bobbo> right so lets have do a practical example of this
[21:08] <bobbo> We will use Terminator as an example because it has quite a few branches that implement new features (and it is a really cool project). First we need to grab Terminator's trunk branch:
[21:08] <bobbo>     bzr branch lp:terminator
[21:08] <bobbo>     cd terminator
[21:09] <bobbo> Now we have the "trunk" branch of Terminator. This is where the core authors of the project put most of their bugfixes etc, but most large feature changes are done outside of trunk, in their own special branches
[21:10] <bobbo> This lets developers make large changes to the code, without breaking the main project code
[21:11] <bobbo>  <james_w> if you grabbed a checkout of terminator in the last session then "cd terminator" and run "bzr unbind" and you will be in the same state as from bobbo's talk <-- Do that :P
[21:11] <bobbo> Right everyone in a (working) Terminator trunk directory?
[21:11] <meastp> How can you merge, or rather copy changes between trunk and, say, a stable serie?
[21:11] <meastp> yes
[21:11] <Tonio__> yep
[21:11] <alucardni> done bobbo
[21:11] <NetSKaVeN> yep
[21:12] <bobbo> OK, so now we are going to merge in another branch
[21:12] <bobbo> this is based on Terminator trunk, but instead of implementing all the bugfixes etc going into the main project, this branches author has decided to implement a shiny new feature
[21:13] <bobbo> So now we run "bzr merge lp:~richiek/terminator/altctrlwin-num_tab_change" to try and merge the new branch into our copy of trunk
[21:14] <bobbo> Once this has completed it should give you a message like:
[21:14] <bobbo>    1 conflicts encountered.
[21:14] <bobbo> This means that bzr tried to automatically merge the two branches together, but since the new author branched terminators trunk, a change has been made (in trunk) that conflicts with the new code (in the branch).
[21:14] <bobbo> (I could have worded that a little better, everyone understanding?)
[21:15] <NetSKaVeN> yeah
[21:15] <johnsgruber> got it
[21:15] <patrickd_> yup
[21:15] <lobo-ptr> sure, go on
[21:15] <meastp> yes
[21:15] <bobbo> So lets go fix the conflict. Run:
[21:15] <Tonio__> okk
[21:15] <bobbo>     bzr conflicts
[21:15] <bobbo> This will show you where all the conflicts in the source tree are. It should say "terminatorlib/terminator.py", so lets edit it and find where the conflict is.
[21:15] <bobbo>     gedit terminatorlib/terminator.py
[21:15] <bobbo> The conflict can be found in between these markers (around line 865):
[21:15] <bobbo>     <<<<<<< TREE
[21:15] <bobbo>     [21:15] <bobbo>     >>>>>>> MERGE-SOURCE
[21:15] <bobbo>     
[21:15] <bobbo> everything above the ='s and below <<<<<<< TREE is what is currently in the trunk and everything below the ='s and above >>>>>>> MERGE-SOURCE is what is currently in the branch you are merging
[21:16] <bobbo> I wont show you completely how to manually merge these, because that requires knowledge of the application and libraries etc. and each merge is different so there is no real need,
[21:16] <bobbo> But basically you have to work out a way for those two piece of code to co-exist, in a way that doesnt cause the application to explode, but also implement the new feature or bugfix in the branch
[21:17] <bobbo> So for educational purposes, lets just pretend that we have managed to fix the conflict and are now ready to commit our merge
[21:17] <bobbo> First off we need to tell bazaar we have actuall fixed the conflict, otherwise it wont let us commit the merge
[21:18] <bobbo> run "bzr resolve terminatorlib/terminator.py" to tell bzr that everything is fixed.
[21:19] <bobbo> we would need to repeat the above process for every file that has merge conflicts in it, so merging big patches, after big patches have been applied in trunk can be a little messy and time consuming
[21:19] <bobbo> finally we need to commit the merge to our copy of trunk: bzr commit -m "Merged in lp:~richiek/terminator/altctrlwin-num_tab_change"
[21:20] <bobbo> congratulations! You just completed your first bzr merge!
[21:20] <bobbo> anyone need any time to catch up?
[21:20] <meastp> no
[21:20] <NetSKaVeN> all ok here
[21:20] <Tonio__> ok for me too
[21:21] <bobbo> right, onto section 2: Tagging!
[21:21] <Megaqwerty> I'm ready
[21:21] <bobbo> QUESTION:how can bazaar tell that two sections of code are in conflict ( and will actually break the software) ?
[21:22] <meastp> ( I'm sorry, I am new to classroom sessions... Am I allowed to ask questions related somewhat to what we are currently doing, or are these 'tutorial' sessions only? )
[21:22] <bobbo> x_dimitri: I am not sure how it works in the internals of bazaar, but it must check whether the branch and the trunk have changed the same pieces of code
[21:23] <LarstiQ> bobbo: could you repeat x_dimitri's question?
[21:23] <bobbo> x_dimitri: it would probably be a good idea to ask a developer about how it works inside bazaar, because it must be pretty complex (as in I dont know, sorry)
[21:23] <bobbo> LarstiQ:  QUESTION:how can bazaar tell that two sections of code are in conflict ( and will actually break the software) ?
[21:23] <bobbo> meastp: ask away, though I cant be sure i'll know the answer :D
[21:24] <x_dimitri> ok
[21:24] <gourgi> meastp: join #ubuntu-classroom-chat for questions
[21:24] <bobbo> OK, section 2: Tagging!
[21:24] <meastp> bobbo: I was told to join the ubuntu-classrom-chat... no worries :)
[21:25] <bobbo> Bazaar has a useful feature, called tagging, which lets you give a commit to a branch a sensible, human understandable name like "0.2.0-release" or "fixes-bug-375838". This is can be used for tagging releases, release candidates, or whenever you are going to need to easily find a revision number.
[21:25] <bobbo> i think svn and other "traditional" VCS's have tagging of some sort too, but I have never had the pleasure of working with them, so wouldnt really know :)
[21:26] <bobbo> So lets try this out in our Terminator branch. You can add a tag to a branch very easily using "bzr tag":
[21:26] <bobbo>     bzr tag "test-tag"
[21:26] <bobbo> This will give the latest revision (the last one committed to the branch) the tag "test-tag".
[21:27] <bobbo> you can delete tags using:
[21:27] <bobbo>     bzr tag --delete test-tag
[21:27] <bobbo> To tag an already existing revision we can use:
[21:28] <bobbo>     bzr tag -r 123 "release-0.1a"
[21:28] <bobbo> This tags revision 123 with the tag "release-0.1a"
 QUESTION: can you delete any tag or only the last?
[21:29] <bobbo> You can delete any tag, but it wont delete the revision, just the tagging of that revision
[21:30] <bobbo> it is also possible to give a revision more than one tag
 QUESTION: Is possible to list the existing tags? how?
[21:30] <bobbo> yes, running "bzr tags" gives you a full list of all the current tags in the branch
 QUESTION:  Can you easily retrieve stable revision identifiers from bzr that are consistent between branches and merges?
[21:31] <bobbo> mbt: Sorry, I have never tried it, so I'm not sure
[21:31] <LarstiQ> mbt: yes, bzr revision ids are stable
[21:31] <bobbo> It is also possible to revert to a revision using its tag, for example:
[21:31] <LarstiQ> mbt: you can see them in log for example with bzr --show-ids log
[21:32] <LarstiQ> mbt: and use them with revid:, so bzr diff -r revid:<your revid here>
[21:32] <bobbo>     bzr revert -r tag:release-0.1a
 Hi, I have recently added my project to lp, with bzr. Currently I have a trunk, and branches for features. But how should I manage releases? E.g if I branch trunk as 1.0 and add to the 1.0 series, how should I keep trunk and the 1.0 series' bugfixes synchronised (with bzr)?
[21:33] <bobbo> meastp: the way I do it (may not be the best or most efficient way but it works) is to have have the release-1.0 branched from trunk, put all bugfixes etc into trunk and then merge them into the release-1.0 branch (does that make sense?)
[21:34] <bobbo> The beauty of bazaar is that you can have release-1.0 specific code in the release branch, but also be able to pull in changes from trunk when they are needed
[21:34] <bobbo> meastp: does that answer your question?
[21:35] <bobbo> For even more on reading tagging in Bazaar check out http://bazaar-vcs.org/Specs/Tagging
 QUESTION: I have made some uggly modifications and put my hown tag and then commit all that stuff and its ok. But I am not logged to the launchpad. So what does commit exactly ?
[21:36] <meastp> bobbo: yes, thanks... I'm a bit confused by this workflow. Will look at the link, thanks
[21:36] <bobbo> Commit in bzr works completely differently to committing in svn or cvs.
[21:37] <bobbo> IN bazaar, "commit" puts revisions into the local branch (which is sitting on your HD or pen drive)
[21:37] <bobbo> You need to "push" them onto launchpad (using bzr push) before they will show up there
[21:38] <bobbo> Tonio__: is that what you were looking for?
[21:38] <Tonio__> bobbo: Thanks it's clear for me (I am a SVN user)
[21:39] <bobbo> Tonio__: yeah, it is one of the biggest confusing things for svn users when they come to bzr, the same words meaning almost completely different things :D
[21:39] <bobbo> Right Section 3 : Extensibility and Modules
[21:40] <bobbo> On the best things about bazaar (IMO) is that it is very easily extensible.
[21:40] <bobbo> It is very simple to plug in your own functionalities to the system
[21:41] <bobbo> There are hundreds of plugins, ranging from useful little tools like creating diffstats (little "graphical" representations of a patch that at a glance tell you how much the patch is changing) to  big complex things like adding dbus or rsync support
[21:42] <bobbo> There are also several plugins that help you integrate with other version control systems
[21:43] <bobbo> including support for importing SVN branches into bzr, which is always very handy when you already have existing project infrastructure that you want to move over to bzr
[21:44] <bobbo> There is a huge big list of plugins on the bazaar website at http://bazaar-vcs.org/BzrPlugins
[21:45] <bobbo> Most of these will be installable via a setup.py file shipped in their source tar.gz, but if you dont fancy doing that, Debian/Ubuntu also has several (more important) bzr plugins packaged up and in the repositories
[21:45] <bobbo> You can see a list of these at http://packages.ubuntu.com/search?suite=default&section=all&arch=any&searchon=names&keywords=bzr-
[21:45] <bobbo> As with all software in the repos, you can just run "suo apt-get install bzr-rebase" and have rebasing support in bazaar
[21:46] <bobbo> Well thats pretty much all I planned for. Are the any questions?
 QUESTION: What's rebasing ?
[21:47] <bobbo> Rebasing is the process of taking a branch and modifying the history so that it appears to start from a different point
[21:48] <bobbo> This can be useful to clean up the history before submitting your changes. The tree at the end of the process will be the same as if you had merged the other branch, but the history will be different.
[21:48] <apagano> exit
[21:48] <bobbo> You can read more about it at http://bazaar-vcs.org/Rebase
[21:49] <apagano> quit
[21:49] <bobbo> Anymore questions?
[21:49] <bobbo> nope? Looks like we can all get away early then!
[21:49] <bobbo> thanks for listening!
[21:50] <NetSKaVeN> great session bobbo
[21:50] <gQuigs> thank you bobbo
[21:50] <johnsgruber> Thanks much
[21:50] <lobo-ptr> thanks
[21:50] <gourgi> thank you bobbo
[21:50] <alucardni> thanks bobbo
[21:50] <biomass> thanks bobbo
[21:50] <Tonio__> Thanks bobbo
[21:50] <james_w> thanks bobbo
[21:50] <bobbo> thanks alot guys :D
[21:51] <weboide> thanks bobbo
[21:51] <pugliamix> hi everybody - seems I came too late
[21:51] <WastePotato> What did I miss?
[21:51] <WastePotato> Can someone pastebin it for me?
[21:52] <cyphermox> WatePotato: check out https://wiki.ubuntu.com/MeetingLogs, all the logs will be there eventually.
[21:53] <Megaqwerty> WastePotato: http://paste2.org/p/96434
[21:53] <WastePotato> Thanks. :)
[22:36] <emma> I have a question/comment about the Ubuntu Open Week directed to whomever it may concern: First thanks for putting it on. It's fabulous and I wish I could attend just about every event. Having said this, could the next Ubuntu Open Week be held at a more diverse spread of hours? As it is, I think most working people in the western hemisphere will not be able to see many of the events, because 15:00 UTC = 10:00 am on the east coast, which means ...
[22:36] <emma> ... most people are at work.
[22:43] <mrooney> emma: well, that just means those people can't ask questions in real-time. You can view it later and ask a question in advance
[22:43] <mrooney> and you could certainly ask the host any questions you have later via IRC or email, I imagine
[22:43] <emma> Okay.
[22:44] <mrooney> But I can see where having it "live" is more fun and interactive
[22:44] <emma> Yes.
[22:44] <mrooney> I think jcastro is perhaps the person to ping for this event
[22:44] <jcastro> It's hard to pick a time when you're trying to hold an event for everyone
[22:45] <jcastro> we try to do the best we can to fit in a time that is best for everyone
[22:45] <emma> Yes of course.
[22:45] <emma> There's no way to please everyone, every event. That's for sure.
[22:45] <Upayavira> Ubuntu isn't the only open source org that tends to pick that timeframe
[22:45] <emma> Maybe each UOW could vary or perhaps different days could be for the western hemisphere users.
[22:45] <jcastro> if I were drowning in people who want to run sessions so we could run one in europe, one in asia, etc. that would be ideal
[22:45] <jcastro> but we don't
[22:46] <jcastro> I believe a few years ago some people in germany ran their own openweek-esque type event in their local language and time zone
[22:46] <emma> Well the main thing is what I said first there. The Ubuntu Open Week is a great idea and I really appreciate the people who put it together :)
[22:46] <jcastro> If someone were to do that kind of thing it would be great
[22:48] <emma> If they started 3 hours later that would make a difference I think.
[22:48] <bbb> nice work jorge et al
[22:48] <jcastro> thanks bbb!
[22:48] <rgreening> The presenters would need to be available at that time too. find presenters for earlier slots and then earlier sessions are possible
[22:48] <rgreening> :)
[22:48] <jcastro> yeah the problem is presenters usually
[22:48] <jcastro> not just picking a time for people
[22:48] <rgreening> hats off jcastro
[22:49] <emma> Sure I get you.
[22:49] <jcastro> It would be nice if we had enough contributors to make it a 24 hour thing around the world or something
[22:49] <jcastro> ok off to dinner, I'll ttyl
[22:49] <emma> jcastro: If you need help for the next one finding presenters, I am good at that kind of thing.
[22:49] <bbb> peace
[22:49] <jcastro> emma: okay
[23:24] <pinkeytheperky> Hi everyone