[01:13] <DzimiHumuNukuNuk> hik
[03:06] <Keyseir> I've got a rather complicated RAM issue. I have two 256 chips and a 512, sdram. I originally was getting segfaults on my ubuntu installation, and then I even got it on a livecd. I couldn't even install on the hd, and I was able to install dapper when I removed the 512. However, I never got any errors running memtest86 for a total of 6-7 hours. 'Memtester' finds errors when the 512 chip is in the picture SOMETIMES, but sometime
[03:06] <Keyseir> s I change the test memory value by maybe 5m and it all changes. Anyone who knows a lot about hardware/ram have an idea?
[03:13] <andrew> Keyseir: #ubuntu
[03:49] <Keyseir> Did someone respond to me here?
[03:49] <Keyseir> I had... issues
[03:49] <andrew> Keyseir: ask in #ubuntu
[03:50] <andrew> this room is for sessions held during the day
[03:51] <Keyseir> Nobody responded in #ubuntu, so I figured I'd go for the room used for more in depth conversations.
[03:56] <LjL> Keyseir: tried posting in the forums?
[03:58] <Keyseir> LjL, No. I should.
[04:56] <pawjan> help
[04:56] <pawjan> ?
[04:57] <nalioth> pawjan: have you asked in #ubuntu ?
[04:57] <Zbyshek> :))
[04:57] <pawjan> I'm just checking if there is anybody not sleeping yet ;)
[05:42] <lara22> hi
[05:42] <andrew> hi
[05:46] <effie_jayx> hi
[10:02] <Seveas> !question
[10:02] <ubotu> Please ask your questions here in #ubuntu-classroom-chat rather than #ubuntu-classroom (prefix them with "QUESTION: ")
[10:02] <Seveas> !questions
[10:55] <sergio1337> sad
[10:56] <b4ck3r> Como te decia
[10:56] <b4ck3r> La programacion esta https://wiki.ubuntu.com/UbuntuOpenWeek
[10:56] <sergio1337> si
[10:56] <sergio1337> english only, please
[10:57] <b4ck3r> jajajajja
[10:57] <b4ck3r> Ok
[10:57] <b4ck3r> lol
[10:57] <b4ck3r> Em portugues pode ??
[10:57] <tonyyarusso> !pt
[10:57] <ubotu> Por favor use #ubuntu-br  ou #ubuntu-pt  para ajuda em portugus. Obrigada.
[10:57] <b4ck3r> Ok
[10:57] <b4ck3r> Obrigado
[10:59] <b4ck3r> Ok, tx
[10:59] <b4ck3r> thx
[10:59] <tonyyarusso> @dump
[11:43] <noxs> hi all
[11:44] <snail> hi noxs: discussoin in #ubuntu-classroom-chat
[12:50] <ailean> why are there two chans for portugese? there isn't a separate chan for US english to UK english . . .
[12:53] <apokryphos> ailean: because the difference is more than just UK and American English, for one. But secondly, we do have a UK locoteam channel -- #ubuntu-uk
[12:54] <ailean> oh right ;)
[12:54] <ailean> well i don't believe in the uk, so i'll stay here :P
[12:55] <apokryphos> it does exist, I can guarantee it ;-)
[12:56] <ailean> lol
[12:56] <ailean> I'll just wish you a happy St Andrew's Day :)
[01:19] <ailean> very good stefg :)
[01:23] <tonyyarusso> apokryphos: Why on earth was it ever +s?
[01:23] <apokryphos> no idea; might've been the Freenode reset from a few days ago
[01:24] <tonyyarusso> Ah, sounds plausible.
[03:12] <WB|Diego> HI
[03:32] <effie_jayx> hi all :D
[04:00] <jono> hi all
[04:00] <jono> right before we start, I have a quick announcement
[04:00] <apokryphos> hi jono 8)
[04:00] <fyrestrtr> oh its started?
[04:00] <jono> tomorrow is the Ubuntu Freshers Day where we invite everyone to come to #ubuntu-freshers
[04:01] <popey> moo
[04:01] <jono> the aim of the day tomorrow is that anyone can ask questions they have about Ubuntu
[04:01] <fabbione> jono: do you need irc logs for that?
[04:01] <jono> so, feel free to get into #ubuntu-freshers all day tomorrow
[04:01] <jono> fabbione, I don't think so - its a general channel
[04:01] <effie_jayx> starting at?
[04:01] <fabbione> jono: ok thanks.
[04:01] <jono> it is all day for every time zone
[04:01] <effie_jayx> :D yipieeeeeee
[04:01] <jono> so, without further ado, let me introduce Melissa Draper - elkbuntu - who is going to talk about LoCo teams
[04:02] <jono> get those questions in #ubuntu-classroom-chat like normal
[04:02] <elkbuntu> :)
[04:02] <jono> enjoy ther session :)
[04:02] <elkbuntu> Hello everyone! Welcome to the LoCo Teams introduction session.
[04:02] <elkbuntu> finished spamming, dear?
[04:03] <apokryphos> yup; take it away :)
[04:03] <elkbuntu> My name is Melissa Draper, and I am the LoCo Team Contact for the Ubuntu Australian LoCo Team. If you are wondering what that title involves, fear not, for we will be discussing it over the course of this session. I have a wiki page at https://wiki.ubuntu.com/MelissaDraper that introduces me in more detail.
[04:03] <elkbuntu> Over the course of this session, we will be discussing a number of aspects of LoCo Teams. This includes, but is not limited to:
[04:03] <elkbuntu> * What are LoCo Teams?
[04:03] <elkbuntu> * Who leads the LoCo?
[04:03] <elkbuntu> * How I can find my LoCo Team?
[04:03] <elkbuntu> * But, I can't see a LoCo Team for me!
[04:03] <elkbuntu> * How do I start a LoCo?
[04:03] <elkbuntu> * Approved vs New
[04:03] <elkbuntu> * How can I get involved?
[04:03] <elkbuntu> Now, lets start at the beginning. What are LoCo Teams?
[04:04] <elkbuntu> A LoCo (short for Local Community) Team is a group of (in our case) Ubuntu users within a Localised Community.
[04:04] <elkbuntu> The teams are run by the people, for the people. They are *not* run by Canonical, however Canonical is highly supportive of them and will provide assistance. We will cover the assistance offered later.
[04:04] <nanda> j
[04:04] <elkbuntu> A LoCo can involve a lot of things such as local promotion, support in the local language, general support to local users and much more.
[04:05] <elkbuntu> LoCo Teams can be based around location, such as in my case, Australia.
[04:05] <elkbuntu> Because people in Australia speak English, there is not a strong need for language-based activities. Our primary focus is advocacy within Australia, but we do a small amount of support.
[04:05] <elkbuntu> Language based teams include for instance, the Spanish Team, which is based primarily around the Spanish language and hence includes most, if not all, the Spanish-speaking countries.
[04:06] <elkbuntu> Because Spanish is a very widely spoken language, the team's efforts would have a greater focus on providing support in Spanish and translating Ubuntu. There are still, of course, advocacy efforts within the team.
[04:06] <elkbuntu> One aspect of LoCo Teams that we find is also important, is that they enable and encourage people to interact with other Ubuntu users that are actually near them, as opposed to the other side of the world.
[04:07] <elkbuntu> A single person with ideas is nothing compared to a dozen equally imaginative people :)
[04:07] <elkbuntu> Ok, there are some questions in the chat, so i'll cover those now. The saturday session will be the same as todays.
[04:08] <elkbuntu> Popey, yes, we are aware of this. It is one area that we are hoping to change. it has improved in the past few months, and we hope to improve it further.
[04:08] <jrib> elkbuntu: it may help to state the question before answering so everyone benefits
[04:08] <Phoenix7477> yes please
[04:08] <nanda> yes
[04:09] <elkbuntu> right.. sorry
[04:09] <fyrestrtr> we are meant to ask questions in -chat and then look here for the answers, or can we ask in here directly?
 QUESTION: Each LoCo seems to be doing their own thing - which isn't a bad thing - but it could be useful for us to talk to eachother more. How can we best learn from eachother so we have a consistent approach across all LoCo teams?
[04:09] <Phoenix7477> thank you :)
 QUESTION: My loCo team is not very active ( a web page, unaswered posts a week long and that's it) how can I help if there are no contacts in the wiki or the webpage
 and cana university have a loCo?
[04:10] <elkbuntu> effie_jayx, i'll discuss this a bit later in the session, and i'll answer questions regarding this after.
[04:10] <effie_jayx> thnx
[04:10] <effie_jayx> I'll stay put
[04:11] <elkbuntu> Now, one question we get asked a lot by new teams is "Who leads the LoCo?".
[04:11] <elkbuntu> Generally, this is done by the LoCo Team Contact.
[04:11] <elkbuntu> The contact may be the founder, who has self-appointed his or herself, or, he or she may have been democratically elected.
[04:11] <elkbuntu> There's no 'right' way to do it, and some teams even have multiple contacts.
[04:12] <elkbuntu> What works for *your team* is best, and it may take a few tries to figure out what this is.
[04:12] <elkbuntu> The responsibilities of the Team Contact vary with the focus of the team, but a general guideline is https://wiki.ubuntu.com/LoCoTeamContact
[04:12] <elkbuntu> In my role as the LoCo Team Contact for Ubuntu-Au, my responsibilities generally include maintaining regular meetings, delegating tasks, channel upkeep and moderation and so forth.
[04:13] <elkbuntu> LoCo Contacts should be subscribed to the loco-contacts mailing list (https://lists.ubuntu.com/mailman/listinfo/loco-contacts) and hang out in #ubuntu-locoteams. This is something that will help with Popey's question above.
[04:13] <elkbuntu> The team contact is also the public face of the LoCo. He/She acts as the main communication bridge between the team and the community at large. Given this, a grasp on the English language is almost necessary.
[04:14] <elkbuntu> It is possible that the contact may be approached by media, or get direct support requests, as their contact details are, or at least should be, easily obtainable.
[04:15] <elkbuntu> Some people in here have probably already located their LoCo Team. Some others may want to know "How I can find my LoCo Team?"
[04:15] <elkbuntu> A good way to find your LoCo Team, is to visit https://wiki.ubuntu.com/LoCoTeamList and see if there is a team in your area.
[04:15] <elkbuntu> If there are several teams that apply to you, the team at country or state level is probably the team you should join first, although there's nothing stopping you being in multiple LoCos.
 QUESTION: Should *only* the team contact join loco-contacts list or can anyone?
[04:16] <elkbuntu> of course not. everyone is welcome :)
[04:16] <popey> \o/
[04:16] <elkbuntu> we actually have alot of people on the list and in the channel who are not their team's contact
[04:17] <elkbuntu> Now, if any of you are in the situation where you are looking at the teams list and thinking "But, I can't see a LoCo team for me!", then there's a good chance one may not exist.
[04:17] <elkbuntu> There is a possibility that your team just has not added themselves to the list, so check the channels list here on freenode, and/or do a google for the team name.
[04:18] <elkbuntu> For example, the Australian team is "Ubuntu-au". "au" is the ISO code for Australia.
[04:18] <elkbuntu> If after searching, you cannot see a team then there probably is not one.
[04:18] <elkbuntu> If you are really interested in LoCo work, then it is time to find some other people and start one :)
[04:20] <lorenzo> oppo
[04:20] <elkbuntu> For those who are asking questions in the -chat channel. I will get to hopefully all of you. Some questions will be answered as I go through, i'll try answer the rest at the end :)
[04:20] <leonel> uevo
[04:20] <elkbuntu> you havent been ignored :)
[04:21] <elkbuntu> Anyhow, I know a few people are here wanting to know "How do I start a LoCo?". Well luckily, it's not rocket science.
[04:21] <elkbuntu> The main things you need are people and communication. It is recommended that you start by setting up a mailing list and an IRC channel.
[04:21] <elkbuntu> We can help with this in various ways. Well, we cannot help you gather the people, but the other things we can help with.
[04:22] <elkbuntu> For a mailing list, we prefer if the list is created through Ubuntu's mailman system. For this, email<EMAIL_ADDRESS>[04:22] <elkbuntu> To register your LoCo Channel, see '/msg chanserv help register' for instructions. The channel should be #ubuntu-cc where 'cc' is your country ISO code.
[04:23] <elkbuntu> IRC channels are best done here on Freenode. Almost all Ubuntu channels are here, and it's useful to have all the channels together.
[04:23] <elkbuntu> Not only that, Ubuntu has built up a very good relationship with the Freenode staff, so we're able to pull strings. It's quite convenient.
[04:23] <elkbuntu> Another important point about using the Ubuntu mailman and Freenode, is that if for some unfortunate reason, the team leader was to disappear into thin air (and yes, this happens), it is much easier to negotiate the reassigning of privileges.
[04:23] <elkbuntu> Once you have the basic structure set up, you're a LoCo team.
[04:24] <elkbuntu> Whilst it is not entirely mandatory, it's strongly suggested you sign the team up at Launchpad.net. This lets us know the team exists, for a start, but it also makes it easy to see who is in the team for purposes of verifing things if something goes wrong.
[04:24] <elkbuntu> Launchpad also incorporates the Rosetta translation tools, which is what Ubuntu uses for translations.
[04:24] <elkbuntu> With Launchpad, there are also other ways to contribute to Ubuntu as a whole (outside the realm of LoCo Teams), as has been pointed out over the past few days. Communication and contribution with the rest of the Ubuntu community is essential for a team's success.
 QUESTION: Is there any formal charter laid out by a LoCo?
[04:25] <elkbuntu> As such? no. Every team is welcome to do so if they wish to, however. For some teams, it might help.
[04:26] <elkbuntu> LoCos are pretty freeform in how they're organised and run. Different things work in different places around the world.
[04:27] <elkbuntu> enoch2702, does that answer the question for you?
[04:27] <enoch2702> yes
[04:27] <elkbuntu> :)
[04:27] <elkbuntu> Now, you may or may not have heard reference to 'approved' and 'new' LoCo Teams. This has caused confusion in the past, so I'll cover it now.
[04:28] <elkbuntu> An approved team is a team that is up and running, has each of the required resources in operation and the team is working well. The team has been acknowledged as haivng these traits
[04:29] <elkbuntu> When you become an approved team, it will make you eligible for certain benefits such as marketing materials, and other possibilities.
[04:29] <elkbuntu> An approved team is also considered officially by the Ubuntu project, and the process involves going before the Community Council.
[04:29] <elkbuntu> New teams are equally important to us, and we do support them by providing services such as hosting, a domain, mailing lists etc to help them become established.
[04:30] <elkbuntu> Once a new team has been set up with the basic mail/irc/launchpad structure, and have been around for a while, there should be no problem getting approved.
[04:30] <elkbuntu> If the team chooses to remain unapproved, we're ok with that too, but there are benefits, as mentioned above, for being approved.
[04:31] <elkbuntu> If you have questions about, or your team requires any of the LoCo services mentioned today, please join #ubuntu-locoteams and ask away, or sign up to the mailing list (https://lists.ubuntu.com/mailman/listinfo/loco-contacts) if you prefer that way of asking.
 QUESTION: How does one know if the team I join is approved?
[04:32] <elkbuntu> there is a list at https://wiki.ubuntu.com/LoCoTeamsList and at the top is an 'approved' list
[04:32] <effie_jayx> thnx
[04:33] <elkbuntu> If you were not before, you may now (hopefully) be wondering "How can I get involved?".
[04:33] <elkbuntu> For most teams, just being on the mailing list, in the IRC channel or on the launchpad.net team is sufficient to join the team, and once you have done this, you can contribute in a variety of ways.
[04:33] <elkbuntu> As mentioned above, LoCo Teams involve a variety of project areas. These can include local support, translation, and local promotion, or even simply documenting the team and it's activites.
[04:34] <elkbuntu> If you unsure of how best to get involved with your LoCo, a good idea is to ask a prominent member within the team. They often know what areas need more man (or woman) power.
[04:34] <elkbuntu> Alternatively, if you are for instance, interested in seeing more promotional material that is relevant to your country, then you could simply create the material you feel is missing.
[04:34] <elkbuntu> When you've done whatever you felt necessary, tell people in the LoCo about it. Showing initiative is also a good way to get respect :)
[04:35] <elkbuntu> On a larger level, groups of LoCo members can get together to stage install-fests, or run booths at computer fairs.
[04:35] <elkbuntu> There are alot of great LoCos around, and we're fortunate to have had some of them collaborate to provide us with our (still fledgling) knowledgebase.
[04:35] <elkbuntu> If you want to find out more about joining, establishing or running LoCos, you can see the https://wiki.ubuntu.com/LoCoTeamKnowledgeBase wiki page.
[04:35] <elkbuntu> Or, as that was the end of my pre-written stuff. you can ask questions :)
[04:36] <elkbuntu> i'll work through the question backlog from -chat now
 QUESTION: My loCo team is not very active ( a web page, unaswered posts a week long and that's it) how can I help if there are no contacts in the wiki or the webpage
 and cana university have a loCo?
[04:37] <effie_jayx> yeah :)
[04:37] <elkbuntu> ok. im going to tie the answer to those two questiosn together
[04:37] <elkbuntu> if your country loco is struggling for activity, a smaller part of the country is going to struggle more
[04:38] <elkbuntu> you're best off pushing the team from your uni
[04:38] <elkbuntu> many country teams tend to have an activity hotspot. maybe your uni is that hotspot for your country
[04:39] <elkbuntu> does that make sense, effie_jayx?
[04:39] <effie_jayx> cool.. but I don't mean to disregard their work? after all they did put up a website
[04:39] <effie_jayx> and have gone through some stages in getting their stuff approved
[04:40] <effie_jayx> they might get offended ... I just want to open the space in my university for them to come an talk
[04:40] <elkbuntu> effie_jayx, if they've come to a standstill, then chances are they'll appreciate the assistance
[04:40] <effie_jayx> me just being a liason between them and my uni
[04:41] <elkbuntu> have you talked to the contact about this?
[04:41] <effie_jayx> but I cannot find a contact email
[04:41] <effie_jayx> i's not on the wiki nor the website
[04:41] <elkbuntu> are you able to contact anyone in the team?
[04:41] <effie_jayx> the irc channel is not on freenode
[04:41] <effie_jayx> I have made a post in their forum
[04:41] <effie_jayx> and I blog in their website
[04:41] <elkbuntu> is the irc channel active?
[04:42] <enoch2702> I hope so
[04:42] <effie_jayx> yes..  but not the key people conect
[04:42] <effie_jayx> only people wanting to find out like me
[04:42] <elkbuntu> then the key people are obstructing progress
[04:43] <elkbuntu> we can talk more specifically on this later, i'll continue through the questions now.
[04:43] <effie_jayx> can we email ?
[04:43] <elkbuntu> join #ubuntu-locoteams :)
[04:43] <effie_jayx> great :)
 QUESTION: It has been suggested in our [UK]  loco team that when providing support (for example in the launchpad ticket system) that we might want to mention/brand/advertise ourselves as part of the loco team, rather than just as individuals. What do you think about that?
[04:44] <elkbuntu> I see no problem with doing this. I assume you're referring to in the signing of the response, ie "Popey, Ubuntu-cc Team" ?
[04:44] <popey> yeah
[04:44] <popey> but suggesting everyone does it
[04:44] <elkbuntu> you cannot force everyone to do something ;)
[04:45] <popey> true enough
[04:45] <elkbuntu> simply encourage it strongly
[04:45] <popey> sorry, was a dumb questino :)
[04:45] <elkbuntu> no such thing
[04:45] <popey> :)
[04:45] <popey> too kind
 QUESTION: Our LoCo team (Utah) has a forum on Ubuntuforums. Is it possible to have our mailing list go to our forum, and our forum posts to the mailinglist?
[04:46] <elkbuntu> atoponce, it is possible. talk to the forum mods about it. i'm assuming they would know the best way to do this.
[04:46] <atoponce> ok. cool. thx
 QUESTION: I heard about getting a hostname redirection for the respective pages for the LoCo. what about that? I mean www.ubuntu.no is cool, but what about oslo.no.ubuntulinux.org that is like more compelling, more logical in a worldwide perspective. Have you some final drafts/specs on that after Mountain View?
[04:48] <elkbuntu> he is gone now, but i'll answer for the sake of others.
[04:49] <elkbuntu> for information regarding domains and so forth, it's best to come into #ubuntu-locoteams and ask questions there. there's people there with a clue on that stuff.
[04:49] <elkbuntu> I dont believe we had any specific specs on the topic of domains, but we're hopefully going to streamline things alot :)
 QUESTION: Can you elaborate on what kind of translation support, or literature does Ubuntu provide for people (like myself) that are thinking of starting a LoCo?
[04:51] <elkbuntu> Hmm...
[04:52] <elkbuntu> I'm not all that knowledgable regarding languages. There's a translation team around, and there's rosetta. that's about all i know ;)
[04:53] <elkbuntu> given that, <minimec> QUESTION: Does the language/translation support by the LOCO groups include translation of main/restricted packages and software, or only uni-/multiverse software?
[04:53] <elkbuntu> There was a rosetta session yesterday. i do not know what was coverd in it, but looking at the logs would be useful maybe?
 QUESTION: Would it make sense for LoCo contacts to be invited to Canonical / Ubuntu meetings such as UDS or is that just logistically impractical? The reason I ask is that I feel the LoCos could get a tremendous amount of motivation from "rubbing shoulders" with devs.
[04:54] <elkbuntu> Probably wishful thinking. Your LoCo area probably has a developer or two in it, encouraging their participation in the LoCo would probably have a good effect.
[04:54] <popey> (and with other locos)
[04:54] <elkbuntu> I'd personally love to be able to manage something like this, but im not sure if it's feasable.
 QUESTION:  How closely do LoCos work with LUGs?
[04:55] <elkbuntu> this is a good question.
[04:55] <elkbuntu> there are some LUGs that are highly ubuntu-oriented, whereas there's others that are predominantly gentoo or fedora or suse oriented.
 QUESTION: Hello elkbuntu, I'm Miguel Ruiz, Chilean Ubuntu LoCo Member. Can you explain how your LoCo works? How many sub-teams do you coordinate?
[04:56] <elkbuntu> the Australian team is one single team
[04:56] <elkbuntu> however, i know there are LoCos with chapters, such as iirc, the Canadian Team.
[04:57] <elkbuntu> that's the geographical side of things
[04:58] <elkbuntu> in terms of sub-teams for different functions, the australian team has had no need for this either. it's worth asking a language oriented team about this though.
[04:58] <elkbuntu> I think we're at the end of questions now. and it's nearly time for the next session :)
[04:58] <mruiz> elkbuntu, I asked you because we usually work in different ways: Forum, Wiki, Website, Translation into Spanish; then we can separate our work in sub-teams
[04:59] <mruiz> thanks elkbuntu
[04:59] <popey> thanks elkbuntu ! good session
[04:59] <Phoenix7477> yeah, thanks :)
[04:59] <LjL> Welcome to Ubuntu Open Week, Nov 27 - Dec 2 between 3pm and 10pm UTC | For the schedule, see https://wiki.ubuntu.com/UbuntuOpenWeek | Daily sessions start at 1500UTC - to see this in your timezone, visit http://tinyurl.com/ykqc67 | Logs at http://people.ubuntu.com/~fabbione/irclogs | Please keep support questions in #ubuntu | Class discussions+questions in #ubuntu-classroom-chat | Next session: The Ubuntu Bug Squad (starting shortly)
[04:59] <elkbuntu> Thank you all for listening to me babble :)
[04:59] <popey> :)
[04:59] <mruiz> :)
[04:59] <popey> you think that's babbling - you should join #ubuntu-uk ;)
[05:00] <elkbuntu> Next up is Simon Law to recruit you all to the bug squad :)
[05:00] <apokryphos> coleslaw
[05:00] <jono> thanks elkbuntu !
[05:00] <atoponce> elkbuntu: thx. good session!
[05:00] <sfllaw> elkbuntu: Thanks for the introduction.  Will you set the /topic or shall I?
[05:01] <LjL> Welcome to Ubuntu Open Week, Nov 27 - Dec 2 between 3pm and 10pm UTC | For the schedule, see https://wiki.ubuntu.com/UbuntuOpenWeek | Daily sessions start at 1500UTC - to see this in your timezone, visit http://tinyurl.com/ykqc67 | Logs at http://people.ubuntu.com/~fabbione/irclogs | Please keep support questions in #ubuntu | Class discussions+questions in #ubuntu-classroom-chat | Current session: The Ubuntu Bug Squad
[05:01] <Jucato> yay bugs!
[05:01] <elkbuntu> it seems LjL will :)
[05:01] <sfllaw> Quick on the ball!
[05:01] <LjL> had it in the clipboard since 10 minutes ;)
[05:02] <sfllaw> Melissa, Lorenzo, you're wonderful.
[05:02] <sfllaw> Good morning.
[05:02] <sfllaw> Welcome to my talk about the Ubuntu BugSquad.
[05:02] <sfllaw> For the purposes of clarity, please limit discussions to #ubuntu-classroom-chat.  If you want to ask a question, just write "sfllaw: I have a question about..." in #ubuntu-classroom-chat and I'll answer it at the approriate juncture.
[05:02] <sfllaw> Thanks!
[05:02] <sfllaw> -------------------------------------------------------
[05:03] <sfllaw> Ubuntu is one of the most popular GNU/Linux distributions out there.  And it also has one of the smallest development teams for its size.
[05:03] <sfllaw> The secret to this is huge community involvement.  We have hundreds of people who help with packaging, translations, technical writing, and bug management.
[05:03] <sfllaw> And boy do we have a lot of bugs.  About 300 to 400 new bug reports get filed every day from users, from stable releases like Dapper to bleeding edge stuff from Feisty.
[05:03] <sfllaw> The first people to look at these reports are the BugSquad.  We do a very important task, drinking from this firehose.  And that's to make sure that the reports that remain in the bug tracking system are useful.
[05:03] <sfllaw> You can find our bug tracking system at https://launchpad.net/distros/ubuntu/+bugs
[05:03] <sfllaw> Right now, it holds over 20000 open bug reports, spread across the entire distribution.  That includes main, restricted, universe, and multiverse.
[05:03] <sfllaw> That's a lot of bugs.  The source of these reports can be found here: http://tinyurl.com/yf4hq9
[05:03] <sfllaw> These are untriaged reports: ones which have never had a human eye look at them.  It's likely that they are missing information, duplicate another report, are filed against the wrong package, etc.  Or, if you're lucky, they're perfect.
[05:03] <sfllaw> :)
[05:04] <sfllaw> To triage a bug report, you need to do a few things.
[05:04] <sfllaw> First you have to determine if it's actually a bug.  The easiest ones have crash reports in them.  Let's go find one.
[05:04] <sfllaw> To start, we go to http://launchpad.net  Click on "The Ubuntu distribution"
[05:04] <sfllaw> In the search box, let's look for a popular package.  Bash is a good one to try, so let's ask for that.
[05:04] <sfllaw> Click on 'Source Package "bash" in Ubuntu' to be taken to its package page.
[05:04] <sfllaw> This shows you Bash within the context of the Ubuntu distribution.  Bash also has another page, a product page, which we won't look at right now.
[05:05] <sfllaw> In the left sidebar, you should see a "Bugs" link.  Click on that and you'll be taken to the bug tracker.  This will list all the bugs inside bash right now.
[05:05] <sfllaw> There are quite a few untriaged bugs, but they are intermixed with triaged ones.  Let's narrow down our search to only show untriaged ones.  Start by clicking the "Advanced search" link.
[05:05] <sfllaw> You want to make sure that:
[05:05] <sfllaw>   Status = Unconfirmed only
[05:05] <sfllaw>   Importance = Undecided only
[05:05] <sfllaw>   Assignee = Nobody
[05:05] <LinuxBA> !logs
[05:05] <ubotu> Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs - See also !OpenWeek
[05:05] <sfllaw> Click the "Search" button.
[05:05] <sfllaw> You should end up at http://tinyurl.com/yawhpj which gives you a nice list of bugs to look at.
[05:07] <sfllaw> My example bug went away.
[05:07] <sfllaw> But we'll fix that.
[05:07] <sfllaw> Dum de dum dum.
[05:07] <sfllaw> Ta da!
[05:07] <sfllaw> Reload guys.
[05:07] <sfllaw> Bug 57413 looks like a promising crash.  Click on its description and it will open up.  You can also get to this bug by going to http://launchpad.net/bugs/57413
[05:07] <sfllaw> You see that the bug reporter has included his crash dump, which was caught by apport, our automated crash profiler.  But Longer hasn't really given us enough information to solve the problem.
[05:08] <sfllaw> Here's the minimum information for a complete bug report:
[05:08] <sfllaw>   1. Version of the software.  Is it in Dapper, Edgy, Feisty?  What about a specific version number?
[05:08] <sfllaw>   2. Steps to reproduce the bug.
[05:08] <sfllaw>   3. What was expected to happen.
[05:08] <sfllaw>   4. What actually happened.
[05:08] <sfllaw> Since this bug is incomplete, we'll want to ask for more information.  You do that by taking responsibility for the bug and having a conversation with the reporter.
[05:08] <sfllaw> Implicitly, we know the answers to 3 and 4, because Bash crashed unexpectedly.  And the crash report has the version of bash buried inside (3.1-5ubuntu1).
[05:08] <sfllaw> Still, we need to ask for reproduction steps.
[05:08] <sfllaw> If you're logged in, you can click on the "bash (Ubuntu)" task table up near the top.  This allows you to modify the state of the bug.
[05:08] <sfllaw> There are some fields there:
[05:09] <sfllaw>   Package: this is the source package of the bug.  Bash is correct for this one.
[05:09] <sfllaw>   Status: change this to Needs Info.  This means other people won't try to triage this bug.
[05:09] <sfllaw>   Assigned to: Me.  You're claiming responsibility for having a conversation with the reporter.
[05:09] <sfllaw>   Comment on this change: Here we should ask the reporter for more information.
[05:09] <sfllaw>   E-mail me about changes to this bug report: Yes.  This will subscribe you to any new comments about this report.
[05:09] <sfllaw> In the comment, we would ask for the version of Bash:
[05:09] <sfllaw>   "Hi Longer.  Could you please describe the precise steps you performed to crash bash?  Thanks."
[05:09] <sfllaw> Click "Save Changes" and you're done.
[05:09] <sfllaw> When you get an e-mail from Longer responding to your question with the appropriate steps, the bug can be considered complete.  You've got information on how to reproduce it and there's even a handy log file for a developer to look at.
[05:09] <sfllaw> We can now pass this on to the development team to fix.
[05:09] <sfllaw> Click "bash (Ubuntu)" again and change:
[05:09] <sfllaw>   Status = Confirmed
[05:09] <sfllaw>   Assigned to = Nobody
[05:09] <sfllaw> Click "Save Changes".
[05:09] <sfllaw> That's it, you're done triaging this bug.
[05:10] <sfllaw> daxelrod asks: Apport doesn't report the ubuntu release version?
[05:10] <sfllaw> It does, actually.
[05:10] <sfllaw> The DistroRelease field in an apport report should tell you what it is.
[05:11] <sfllaw> For instance, in #57413, it tells you that this bug was in Ubuntu 6.10.
[05:11] <sfllaw> Also, you can see the version of bash: "Package: bash 3.1-5ubuntu1"
[05:11] <sfllaw> And the versions of all of its Dependencies.
[05:12] <sfllaw> LjL asks: About "Version of the software" - should a reporter just state it (and the Ubuntu version) in the plaintext bug report, or should care be taken to actually use the Launchpad-native features for specifying versions (the usage of which, honestly, is not very clear to me)?
[05:12] <sfllaw> The answer to this is that there are no Launchpad-native features for providing the version number.
[05:12] <sfllaw> Often, it is good enough to know which Distribution it is.
[05:13] <sfllaw> One of the reasons you want to know the version is so that you don't go hunting for a bug that doesn't exist in the most recent source package.
[05:13] <sfllaw> Another reason is because if you notice a flood of bugs being filed against one package for a stable version, you know there's probably a crisis and you should tell someone.
[05:14] <sfllaw> Jucato asks: In reporting a bug, how do we know which package in Launchpad's list a certain program belongs to?
[05:15] <sfllaw> That requires a bit of good judgement.
[05:15] <sfllaw> The https://wiki.ubuntu.com/Bugs/FindRightPackage wiki page can help with some strategies to find it.
[05:16] <sfllaw> arualavi asks: what's the meaning of the word "triaging" pease?
[05:17] <sfllaw> triaging is the process of sorting and allocating aid on the basis of need.
[05:17] <sfllaw> It's been traditionally applied to medical treatment or food handouts.
[05:17] <sfllaw> But here it applies to new bugs that come in.
[05:18] <arualavi> sfllaw: thank you ;-)
[05:18] <sfllaw> Phoenix7477 asks: How should a triage handle a problem where a bug is listed against an older version of, say bash? Check to see if its in the new one? If it is not reproducible in the new version, should the bug be cleared?
[05:19] <sfllaw> In an older version of bash, you can check to see if it's in the new one.  If it is, mention that this is the case in the description.
[05:19] <sfllaw> If it's not in the new one, it should still be left open.
[05:19] <sfllaw> If it's important enough, someone will issue a fix in the foo-updates archive.
[05:19] <sfllaw> Or someone will backport the new one.
[05:20] <sfllaw> Jucato asks: follow-up: isn't there a way to make reporting bugs a bit easier, for example in choosing which package the bug belongs to? I've compared Malone to bugs.kde.org, and while KDE's process is a bit longer (6 pages), it's also a bit less prone to error.
[05:21] <sfllaw> Yes.  We've recognized that Bugzilla has a nicer process for guiding people through filing bugs.
[05:21] <sfllaw> I think it's a bit complicated, when much of this stuff can be automated.
[05:21] <sfllaw> That's why https://blueprints.launchpad.net/distros/ubuntu/+spec/bug-reporting-tool exists, which we are implementing for Feisty.
[05:21] <Jucato> nice
[05:22] <sfllaw> Shall we move on?
[05:22] <sfllaw> Let's say you encounter a bug report that isn't a bug at all.
[05:22] <sfllaw> Perhaps it is a user asking for help on installing software.  Like a request to be taught how to use synaptic.
[05:22] <sfllaw> Or perhaps it is a user asking for a new feature to be implemented.
[05:22] <sfllaw> You can distinguish between features and bugs this way:
[05:22] <sfllaw> A feature request is a wish for new functionality that the program isn't expected to do.
[05:22] <sfllaw> Whereas a bug is where the program fails in some way.  It obviously should be doing something more correct.
[05:22] <sfllaw> You can respond to these by:
[05:22] <sfllaw> - Setting Status = Rejected
[05:22] <sfllaw> - Writing them a nice note in the comment explaining why it was not a valid bug.
[05:22] <sfllaw> You can get templates of these nice notes at https://wiki.ubuntu.com/Bugs/Responses
[05:23] <sfllaw> But you are welcome to put in your own personal touches.  Just remember to be friendly and polite, not terse.
[05:23] <sfllaw> Being concise can be mistaken for being rude.
[05:23] <sfllaw> LjL asks: Should anyone feel free to change a bug's status from "Unconfirmed" or "Needs info" to "Confirmed" (and similar), if they're convinced that the status of the bug has changed, or is it better etiquette to let the assignee (if any) make this sort of changes?
[05:24] <sfllaw> You should feel free to change something to Needs Info, if you're going to claim responsibility.
[05:24] <sfllaw> You can also change it to Confirmed if all the information is inside the bug.
[05:24] <sfllaw> Rejected is also fine, if it's not a bug.
[05:25] <sfllaw> As is Fix Released, if the _reporter_ says the bug has been fixed by a newer version.
[05:25] <sfllaw> If there's an assignee, you shouldn't go mucking about the Status too much.
[05:25] <sfllaw> Some of the other statuses have different meanings for different teams.
[05:26] <sfllaw> davmor2 asks:  After your last talk I have witnessed the amount of bugs,  how important is it to get the initial triage out of the way?
[05:26] <sfllaw> It's fairly important that we try to clear out the queue of untriaged bugs.
[05:26] <sfllaw> If they're untriaged, nobody has looked at them.
[05:26] <sfllaw> And if nobody has looked at them, nobody will fix them.
[05:26] <sfllaw> :(
[05:27] <sfllaw> daxelrod asks: While the FindRightPackage wiki page helps, is there any list that maps  project names to descriptions? (For example: LiveCD Installer <-> Ubiquity)
[05:27] <sfllaw> Not to my knowledge.
[05:27] <sfllaw> If you would like to help, you can add a section that puts this stuff in.
[05:27] <sfllaw> Like the fact that the LiveCD is casper.
[05:27] <sfllaw> It is a Wiki.  :)
[05:28] <sfllaw> rmjb asks: is it bad form to assign yourself to a bug for which you are not the package maintainer?
[05:28] <sfllaw> It's perfectly find to assign yourself to a bug no matter who maintains it.
[05:29] <sfllaw> Assignment has a specific meaning.  It means "I will take responsibility for shepherding this bug."
[05:29] <sfllaw> That's why, when triaging, you assign yourself to the bug while you're waiting for an answer.
[05:29] <sfllaw> Then you can search for a list of bugs you're assigned to and follow up on them.
[05:29] <sfllaw> When you are done triaging, you assign to Nobody.
[05:29] <sfllaw> Someone else will take responsibility after that.
[05:30] <sfllaw> davmor2 asks:  I noticed too that their is a section for importance who sets this?
[05:30] <sfllaw> People on the Ubuntu QA team, the Masters of the Universe, and Core Developers can set this.
[05:31] <sfllaw> Importance has very specific meanings, so you have to go through simple training to join.
[05:31] <sfllaw> It's pretty easy, see https://wiki.ubuntu.com/Bugs/Importance, but beyond the scope of this talk.
[05:32] <sfllaw> Jucato asks: what's the difference between Fix Committed and Fix Released?
[05:33] <sfllaw> Generally, Fix Released means that the fix has been properly sent out to the general public.  In Ubuntu, we use it to mean that it's been sent to a default archive.  Like feisty or edgy-updates.
[05:33] <sfllaw> Fix Committed means that a fix is available somewhere.  In Ubuntu, this means someone has a package in their own personal archive, or they uploaded it to edgy-proposed.
[05:34] <sfllaw> Yawner asks: After looking at a few comments on bugs, its fairly obvious that some are more important than others, as someone not on the QA Team, how do I know which bug is important and which is not? If I feel that its important what exactly do I do about it?
[05:34] <sfllaw> Learn about Importances and then ask dholbach or me to add you to the Ubuntu QA team.
[05:34] <sfllaw> We'll ask you a few simple questions and then you'll have access.
[05:35] <Yawner> aha ok, I have read the article, but only started triaging yesterday
[05:35] <sfllaw> davmor2 asks:  if you get in over your head with a bug where can you turn?
[05:35] <sfllaw> Other members of the Bug Squad can help you.  You can find someone online all the time.
[05:36] <sfllaw> siretart asks: in what cases do you think it makes sense to assign a bug to a team? What semantic does this have?
[05:36] <sfllaw> Each team typically has its own policy on what it means to assign something to it.
[05:36] <davmor2> I kinda quested that would be the case but it might be something putting people off :)
[05:36] <sfllaw> You probably shouldn't assign something to a team unless you're following that policy.
[05:37] <sfllaw> There is documentation on the Ubuntu Wiki that will tell you when it's proper to assign or subscribe a particular team to a bug.
[05:38] <sfllaw> davmor2 asks:  if you find a bug that say allows anyone to change network setting (without asking for admin password) how can you get it prioritised?
[05:38] <sfllaw> Find someone who has the power to change this online.  There are a lot of us, actually.
[05:39] <sfllaw> Generally, that should be filed as a security bug, so you won't bump into it.
[05:39] <sfllaw> But try private messaging dholbach or me, if it isn't one.
[05:39] <sfllaw> We'll set it to Security and give you a bug.
[05:40] <sfllaw> LjL asks: Sometimes you experience problems that you can conceivably suppose to be due to bugs - however, you are not able to track the problem down to a given package, or reproduce it reliably. Normally, I feel that in these situations, a bug report would be useless or, even worse, distracting; however, there might still be some value in reporting the problem "somewhere", so what would you recommend? A forum post, a Launchpad support
[05:40] <LjL> !netsplit
[05:40] <sfllaw> If you can't reproduce it reliably, a support request is probably your best bet.
[05:40] <sfllaw> If you can't reproduce it reliably, a support request is probably your best bet.
[05:41] <LjL> sfllaw: thanks, sorry for the horribly long question - didn't realize it was so long ;)
[05:41] <sfllaw> Yawner asks: If a bug contains a crash report, should you ask for a backtrace? Can you clarify the difference between the two?
[05:41] <sfllaw> The crash reports contains a backtrace within.  The difference is that the crash report is more complete.
[05:41] <sfllaw> GNOME's bug buddy provides a bit of extra metadata.
[05:41] <Yawner> aha ok, thanks
[05:41] <sfllaw> Apport provides a lot of Ubuntu specific metadata.
[05:42] <sfllaw> OK.  Done with this batch of questions.  On we go.
[05:42] <sfllaw> A large class of reports are duplicates.  These are filed by people who did not look or could not find a bug report identical to their problem.  So they filed a new one.  But looking through the bug tracking system, we can spot quite a few if we take some time.
[05:42] <sfllaw> For instance, let's look at the Totem's list of bugs: https://launchpad.net/distros/ubuntu/+source/totem/+bugs
[05:42] <sfllaw> There's a bug about screen blanking while watching movies, http://launchpad.net/bugs/66257
[05:42] <sfllaw> It has one bug marked as duplicate.  You can find a list of duplicates in the left sidebar.  That one is http://launchpad.net/bugs/73029
[05:42] <sfllaw> If someone filed a new bug that was exactly the same as this one, you could click on the "Mark as Duplicate" link in the left sidebar, and enter "66257" as the bug number.
[05:42] <sfllaw> This reduces the clutter in the bug tracking system.  You want to choose the definitive bug with the most complete information, and make all the other duplicates refer to it.  If information is scattered around, you can edit the description of the definitive bug.
[05:42] <sfllaw> You can find new bugs by looking at the big list of untriaged bugs, that I mentioned before.
[05:42] <sfllaw> Or you can join #ubuntu-bugs and listen as Ubugtu rattles off new bugs every few minutes.
[05:42] <sfllaw> It says things like this:
[05:42] <sfllaw> New bug: #73643 in gaim (main) "Gaim crashes while getting roomlist" [Undecided,Unconfirmed]  http://launchpad.net/bugs/73643
[05:43] <sfllaw> This tells you that a new bug has been filed for the gaim source package.
[05:43] <sfllaw> Gaim lives in main.
[05:43] <sfllaw> And it provides a description of what's wrong.
[05:43] <sfllaw> Plus a handy URL to the bug.
[05:43] <sfllaw> The description of a bug is mutable, so that you can summarize the discussion held in the comments.
[05:43] <sfllaw> This is really useful because difficult bugs may have pages and pages of comments.
[05:43] <sfllaw> To change the description, click the "Edit Description/Tags" link in the sidebar.  Try to clean up the description with a good summary of: Version, Reproduction steps, Expected result, Actual result, and a Diagnosis of the problem.
[05:43] <sfllaw> You should also make sure the Summary is something useful, so people browsing for duplicates can find a relevant bug easily.
[05:43] <sfllaw> Bad descriptions are: "Program crashes."
[05:43] <sfllaw> Good descriptions are: "Program crashes with 'Error 12: Can't find my brain on line 382.'"
[05:43] <sfllaw> A good description is easily searchable using keywords people would think of.
[05:44] <sfllaw> And error messages are good because they are often unique to the problem.
[05:44] <sfllaw> Click "Change" after updating the text.
[05:45] <sfllaw> Ubuntu bugs can be tied to upstream bugs.  They can also be tied to bugs in other distributions.
[05:45] <sfllaw> One example is bug 27810: http://launchpad.net/bugs/27810
[05:45] <sfllaw> If you look at the task table, you'll see three different lines.
[05:45] <sfllaw> libaio (Ubuntu)
[05:45] <sfllaw> upstart (Ubuntu)
[05:45] <sfllaw> libaio (Debian)
[05:45] <sfllaw> So the first two have to do with Ubuntu packages.
[05:45] <sfllaw> And the third has to do with Debian ones.
[05:45] <sfllaw> If I were going through this bug doing triage right now, I'd do the following things.
[05:45] <sfllaw> - Realize that it has nothing to do with upstart, and reject it.
[05:45] <sfllaw>   To do this, I click on the upstart (Ubuntu) task and set its Status to Rejected.
[05:46] <sfllaw> - Notice that Fabio claims that this isn't a problem in Ubuntu because the brokenness was never imported.
[05:46] <sfllaw> - Test to make sure I cannot reproduce the problem.
[05:46] <sfllaw>   If everything works properly, I set libaio (Ubuntu)'s Status to Rejected.
[05:46] <sfllaw> In order to add upstream tasks, you will note two links under the task table:
[05:46] <sfllaw> "Also affects: +Upstream... +Distribution..."
[05:46] <sfllaw> If a bug affects another distribution like Fedora, Guadalinux, or Debian, with its own packages, use the +Distribution link.
[05:46] <sfllaw> If a bug is caused by an upstream program's misbehaviour and is not a packaging bug, use the +Upstream link.
[05:46] <sfllaw> You will have to file the bug in the other bug tracker, but then you can paste that bug's URL in to the "Request fix in a..." page, which will link the bugs together.
[05:47] <sfllaw> But often, the bug will already exist upstream, so you don't want to file a duplicate there.  Just paste in that bug's URL in to our bug tracker.
[05:47] <sfllaw> Every day, the status of this bug will be updated with the upstream's status.
[05:47] <sfllaw> Plus, you can search for bugs which have been fixed by upstream.
[05:47] <sfllaw> Now that I've got you interested, you may be asking "sfllaw: How can I join the BugSquad?"
[05:47] <sfllaw> You don't have to have any serious experience before applying.  You can start in BugSquad right now.
[05:48] <sfllaw> Acceptance is automatic and we'd love to teach you the ropes.
[05:48] <sfllaw> You can join by:
[05:48] <sfllaw> - Joining the #ubuntu-bugs channel
[05:48] <sfllaw> - Getting a Launchpad account
[05:48] <sfllaw> - Applying for membership at https://launchpad.net/people/bugsquad
[05:48] <sfllaw> For more information, please see https://wiki.ubuntu.com/HelpingWithBugs which describes how to help with bugs and how to participate in the BugSquad.
[05:48] <sfllaw> We hang out in the #ubuntu-bugs IRC channel on irc.freenode.net.
[05:48] <sfllaw> You can find help and encouragement (and hugs) there all the time.
[05:49] <sfllaw> Finally, I want to point out that we have an UbuntuHugDay scheduled for next Wednesday.  If you want to start helping with bugs, that would be a great time to pitch in.
[05:49] <sfllaw> Thanks everybody!
[05:49] <sfllaw> I've got eleven minutes for questions.
[05:49] <Yawner> thanks Simon
[05:49] <sfllaw> daxelrod asks: Bug hugs?
[05:49] <sfllaw> So this is one of the things we do to recognize when people have done good work.
[05:50] <sfllaw> We give away virtual hugs when you've finished something.
[05:50] <sfllaw> If you ever meet dholbach or me in real life, we're pretty happy to give you a real hug too.
[05:50] <sfllaw> Hugging is a nice way to put a smile on someone's face.  I highly recommend giving away free hugs.
[05:51] <sfllaw> jrib asks: Can a bug have more than one assignee?  If not, is it just because this will cause confusion?
[05:51] <sfllaw> It doesn't really make sense to have more than one "person" responsible for a bug.
[05:51] <sfllaw> If you want to keep track of a bug, you can subscribe to it.
[05:51] <sfllaw> There can be an unlimited number of subscribers.
[05:52] <sfllaw> Jucato asks: There's a particular situation regarding KDE bugs. KDE people want KDE bugs reported upstream rather than in Launchpad. does this present a problem for users and the bug squad?
[05:52] <sfllaw> There is little we can do to prevent people from filing bugs in Ubuntu's bug tracker.  And we don't want to discourage them.
[05:52] <sfllaw> For instance, we could have introduced the bug ourselves with a patch.
[05:52] <sfllaw> We are happy to forward bugs upstream so that KDE people can fix them.
[05:52] <sfllaw> And link them in with our bug tracker, as I described above.
[05:53] <sfllaw> Having it in Launchpad means Ubuntu developers will know about the problem and can find out about the fix when KDE releases it.
[05:54] <sfllaw> Yawner asks: I have just opened a bug report for Skype, to my knowledge this is not within the Ubuntu Repositories? Do I just forward this bug upstream to Skype? Or reject it?
[05:54] <sfllaw> So the answer to this is two-part:
[05:55] <sfllaw> If it's a problem with Ubuntu that prevents a third-party package from working, that would be a bug.
[05:55] <sfllaw> If it's the third-party package that's broken, you will want to Reject the bug and ask the reporter to talk with the authors.
[05:55] <Yawner> hmm.. ok , thanks
[05:55] <sfllaw> So as an example of the first problem, if we broke glibc by accident, then that would be our bug.
[05:56] <sfllaw> The chances of this happening are pretty low, though.
[05:56] <sfllaw> Jucato asks: well, they say that they don't get informed of the KDE bugs that are filed in Launchpad or that they don't want to keep track of 2 bugtrackers. who forwards them upstream, when and how are they forwarded, and how do you know which ones to forward?
[05:57] <sfllaw> That is a fair statement, but there is nothing we can do to prevent users from filing KDE bugs into Launchpad.
[05:57] <sfllaw> And Kubuntu is often the first experience people have with KDE.
[05:57] <sfllaw> Even if they don't know what KDE is.
[05:57] <sfllaw> The BugSquad is the group that does much of the forwarding.
[05:58] <sfllaw> If you are interested in KDE packages, I hope that you will start triaging there.
[05:58] <sfllaw> And become a local expert about various KDE bugs.
[05:58] <Jucato> I try, sometimes.... :P
[05:59] <sfllaw> All right, our time is up for this session.
[05:59] <sfllaw> Thank you all for attending.
[05:59] <LjL> thank you sfllaw
[05:59] <sfllaw> I will field further questions in #ubuntu-bugs.
[06:00] <sfllaw> The next session is about Edubuntu with ogra.
[06:00] <Jucato> thank you sfllaw!
[06:00] <pitti> sfllaw: erm, it's about patching packages
[06:00] <sfllaw> Oh yeah.
[06:00] <sfllaw> I'm reading wrong.
[06:00] <coNP> should we report this as a bug?
[06:00] <sfllaw> Patching Packages with Martin Pitt (pitti)
[06:00] <LjL> coNP: :-)
[06:00] <pitti> .. and gives him a great hug, of course!
[06:00] <jono> great session sfllaw
[06:01] <pitti> so, who are the Happy Patch People around here? :0
[06:01] <jrib> thank you
[06:01] <pitti> just a warning, today's talk will be 95% the same as the one I held on Tuesday
[06:02] <pitti> jrib, jorgp: welcome
[06:02] <ailean> me :)
[06:02] <jrib> hmm do you think you can get a chance to cover quilt?
[06:02] <pitti> ah, seems that most of the folks already attended Tuesday
[06:02] <pitti> so much the better :)
[06:02] <pitti> jrib: yes, if time permits
[06:02] <pitti> if anyone has any question, or I'm totally uncomprehensible (sorry, I'm German), please do not hesitate to interrupt and ask *immediately*
[06:02] <pitti> Also, don't bother trying to take notes, we'll sort that out at the end. You can fully concentrate on the discussion and examples.
[06:02] <pitti> Let's begin with a little bit of history:
[06:03] <pitti> oh, I will usually paste a snippet and then give you some time to catch up and ask, ok?
[06:03] <pitti> == Why use separate patches ==
[06:03] <pitti> In earlier times, people just applied patches inline (i. e. directly in the source code tree). However, this makes it very hard to extract patches later to modify them, send them upstream, etc. Also this means that new upstream versions are a pain, since they generate a lot of rejections when applying the package diff.gz to them.
[06:03] <pitti> With split-out patches it is much easier to send them upstream, keep track of them, develop them, etc., since you always see which changes belong together.
[06:03] <pitti> The ideal state is an unmodified tarball from upstream, plus clean and separate patches, plus the packaging bits in debian/. That means that lsdiff <sourcepackage>.diff.gz only contains debian/.
[06:04] <pitti> The first attempts to split-out patches were pretty trivial: storing patches in debian/patches/, and adding some patch/patch -R snippets to debian/rules. This worked for small patches, but provided no tools for editing these patches, updating them for new upstream versions, etc.
[06:04] <pitti> Thus several standard patch systems were created which are easy to deploy and provide tools for patch juggling and editing.
[06:04] <pitti> any general questions at this point?
[06:05] <pitti> no? ok
[06:05] <jrib> nope, I'm ok
[06:05] <pitti> What I would like to do now is to introduce the most common patch systems and show some hands-on demo how to add a new patch and how to edit one. For this, I will point at a source package from the current dapper archive, quickly explain the patch system, and show how to apply some (braindead) modifications to it. I recommend you to do the same steps in a terminal, so that you get a feeling for the process and can immediately ask questions.
[06:05] <pitti> everyone you fine with this approach?
[06:05] <elliot__> Yeah, sounds good
[06:05] <pitti> If you want to try the stuff yourself, please do the following commands (on edgy) as preparation:
[06:05] <pitti>   sudo apt-get install dpatch cdbs quilt patchutils devscripts
[06:05] <pitti>   apt-get source cron udev pmount gnome-volume-manager ed xterm
[06:05] <pitti>   wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch
[06:05] <pitti>   chmod 755 dsrc-new-patch
[06:05] <pitti> I deliberately picked the smallest packages I could find
[06:07] <pitti> ok?
[06:07] <ailean> 2 mins
[06:07] <jrib> yep
[06:07] <elliot__>  I'm done
[06:07] <jorgp> im ready
[06:07] <dzzsky> Yes
[06:07] <Netfinity> done
[06:07] <ailean> done
[06:08] <pitti> ailean: the first one doesn't require action from you, just let it grind
[06:08] <chickn> rdy.
[06:08] <pitti> == cron: inline patches ==
[06:08] <pitti> No patch system at all, nothing much to say about this.  You directly edit the files in the source tree. This is convenient for a simple and quick change, but will bite back for new upstream versions (see above) and is inconvenient for submitting patches upstream, or reviewing for merges.
[06:08] <pitti> if you do 'lsdiff <package>.diff.gz' and you see changes which are not in debian/, then you probably have such a package
[06:08] <pitti> (some KDE packages have autoconf stuff directly in the diff.gz, but that is ok)
[06:08] <pitti> so, I think I do not need to say anything else about cron, unless someone has a question
[06:08] <pitti> this style of packages can be mainly found in (1) packages which are around for ages (like cron) or packages where Debian/Ubuntu is upstream
[06:09] <pitti> or when the maintainer simply thinks he won't need a patch system
[06:09] <pitti> :)
[06:09] <pitti> ok, then let's dive in
[06:09] <pitti> == udev: separate patches, but no patch system ==
[06:09] <pitti> This case is the most complicated one since you have to do all the hard work manually. In order to make you understand what a patch system does, and to give you a fallback method that will *always* work with any patch system, I handle this first.
[06:09] <pitti> The good news is that you will seldomly be required to actually do this procedure, since for many packages there are nice tools which make things a charm.
[06:09] <pitti> The bad news is that it may seem utterly complicated for people who never did it before, but I would like you to understand what's actually going on behind the curtains of the tools.
[06:10] <pitti> since it is your live safer
[06:10] <pitti> life, even
[06:10] <pitti> So please do not desperate if you do not fully understand it at first; there's written documentation and you can always take your time to grok it.
[06:10] <pitti> The general approach is:
[06:10] <pitti> oh, please ask questions right here, as I asked for
[06:10] <pitti> I like to treat them synchronously, since this is a hands-on tutorial
[06:11] <pitti>  <jrib> QUESTION: we need  lsdiff -z <package>.diff.gz  right?
[06:11] <pitti> jrib: right, that will show what the diff.gz touches
[06:11] <pitti> ideally this is just debian/
 QUESTION: I'm a complete beginner to all of this . . . I'm unsure about what cron is, and what .diff.gz is. Should I consult something else before coming back to read these logs?
[06:12] <pitti> ailean: I'm afraid you might be overwhelmed by this stuff
[06:12] <pitti> I do assume that you have basic familiarity about what a source pacakge is and how it looks like
[06:12] <ailean> fair enough . . . :)
[06:12] <pitti> this is intended to be a tutorial for people who want to hack on packages
[06:12] <pitti> ailean: but of course feel free to listen
[06:12] <pitti> ailean: cron is 'just a random package' for our purposes
[06:13] <pitti> ailean: and a diff.gz is the disto specific part on top of the original upstream tarball, with all the packaging specific bits and code changes
[06:13] <pitti> but due to limited time I can't be more specific here
[06:13] <pitti> ok, so the general approach
[06:13] <pitti> 1. copy the clean source tree to a temporary directory /tmp/old
[06:13] <pitti> 2. apply all patches up to the one you want to edit; if you want to create a new patch, apply all existing ones (this is necessary since in general patches depend on previous patches)
[06:13] <pitti> 3. copy the whole source tree again: cp -a /tmp/old /tmp/new
[06:13] <pitti> 4. go into /tmp/new, do your modifications
[06:13] <pitti> 5. go back into /tmp and generate the patch with
[06:13] <pitti>   diff -Nurp old new > mypatchname.patch
[06:13] <pitti> 6. move the newly generated patch to <original source dir>/debian/patches/mypatchname.patch
[06:14] <pitti> (just the theory, detailled explanation will follow shortly)
[06:14] <pitti> with the demo it will become clear
[06:14] <pitti> just an explanation of the '-Nurp' diff options:
[06:14] <pitti> in general we want the following diff options:
[06:14] <pitti> -N -> include new files
[06:14] <pitti> -u -> unified patches (context diffs are ugly)
[06:14] <pitti> -r -> recursive
[06:14] <pitti> -p -> bonus, you can see the name of the affected function in the patch
[06:14] <pitti> does anyone have a question about the principle method?
[06:15] <jrib> when you say we need to apply  the patches up to the one we need to edit, does that mean all of the ones that start with a smaller number?
[06:16] <pitti> jrib: right
[06:16] <chickn> wait..before you go too far, i don't get how you know if a package has a 'patching system' or not..
[06:16] <pitti> jrib: in 95% of the cases, patches are applied in asciibetical order, and since most patches are prefixed with a number, sorted by number
[06:16] <pitti> chickn: ah, good question
[06:16] <pitti> chickn: if there is a debian/patches/ with patches, then most probably there is a patch system
[06:17] <pitti> chickn: there are very few braindead pacakges which apply their patches inline and additionally put them into debian/patches/ for future reference
[06:17] <pitti> this is just *silly*
[06:17] <pitti> and it happened to the best of us that we just sticked a new patch into that and wondered why it didn't become active
[06:17] <pitti> you can check debian/rules and search for 'patch', that's a pretty safe method
[06:18] <chickn> k.
[06:18] <pitti> ok, some hands-on example on udev
[06:18] <chickn> So for cron...there's no reference for 'patch' in rules
[06:18] <pitti> open a shell, ready your fingers :)
[06:18] <pitti> chickn: right, and you will see taht lsdiff -z cron*.diff.gz contains source code patches
[06:18] <chickn> k.
[06:18] <pitti> chickn: i. e. it just applies the patches inline in the raw source tree
[06:19] <pitti> jrib: your q was answered, too?
[06:19] <jrib> pitti: yep, carry on
[06:19] <pitti> udev example 1, let's create a new patch 90_penguins.patch:
[06:19] <pitti>   cd /whereever/you/unpacked/the/source/udev-093
[06:19] <pitti> -> now we are in our original source tree where we want to add a new patch
[06:20] <pitti>   cp -a . /tmp/old
[06:20] <pitti> -> create a copy of the clean sources as reference tree
[06:20] <pitti>   pushd /tmp/old
[06:20] <pitti> -> go to /tmp/old; 'pushd' to remember the previous directory, so that we can go back conveniently
[06:20] <pitti>   debian/rules patch
[06:20] <pitti> -> apply all already existing patches; of course we could use the 'patch' program to do it manually, but since debian/rules already knows how to do it, let's use it. The actual name for the patch target varies, I have seen the following ones so far: patch, setup, apply-patches, unpack, patch-stamp. You have to look in debian/rules how it is called.
[06:21] <pitti>   cp -a . /tmp/new; cd ../new
[06:21] <pitti> -> copies our patched reference tree to our new work directory /tmp/new where we can hack in
[06:21] <pitti> that's the preparatory part
[06:21] <pitti> set so far?
[06:21] <jrib> yep
[06:22] <elliot__> give me a mo
[06:22] <chickn> k.
[06:22] <jorgp> k
[06:22] <elliot__> yes fine now
[06:22] <pitti> let's do a braindead modification now
[06:23] <pitti>   sed -i 's/Linux/Penguin/g' README
[06:23] <pitti> -> changes the README file; of course you can use your favourite editor, but I wanted to keep my examples copy&pasteable
[06:23] <pitti> and now we create a patch between the reference and our new tree:
[06:23] <pitti>   cd ..
[06:23] <pitti> -> go back to /tmp, i. e. where our reference tree (old) and hacked tree (new) is located
[06:23] <pitti>   diff -Nurp old new > 90_penguins.patch
[06:23] <pitti> -> generate the patch (Ignore the 'recursive directory loop' warnings)
[06:23] <pitti>   popd
[06:23] <pitti> -> now you should be back in your original source tree (when you did the pushd)
[06:24] <pitti>   rm -rf /tmp/old /tmp/new
[06:24] <pitti> -> clean up the temporary trees
[06:24] <pitti>   mv /tmp/90_penguins.patch debian/patches
[06:24] <pitti> -> move the patch from /tmp to the source tree's patch directory, where it belongs.
[06:24] <pitti> *uff* :)
[06:24] <pitti> Now take a look at your shiny new debian/patches/90_penguins.patch.
[06:24] <pitti> after that, if you do 'debian/rules patch', you'll see that the patch applies cleanly; please do 'debclean' afterwards to unapply the patches and get back a pristine source tree
[06:25] <pitti> so, obviously that's not the end of the wisdom, but if you do these steps a couple of times, you should get a feeling for how to create the most complicated patch conceivable
[06:25] <pitti> so this procedure is the life safer if anything else fails
[06:25] <pitti> questions so far?
[06:25] <jrib> I notice that the patches jump from 01 to 40, and sometimes only jump by 5.  What is the convention in naming the patches?
[06:25] <pitti> jrib: there's no real policy
[06:26] <pitti> jrib: often patches are named in ascending order, then maybe patch 05 becomes obsolete or applied upstream
[06:26] <chickn> but if you're writing patches on top of ones already applied - shouldn't your name be something that will come last?
[06:26] <pitti> jrib: sometimes, maintainers organize them in blocks
[06:26] <pitti> jrib: e. g. in postgresql, upstream patches start with 00, server patches from 10 to 300, contrib patches from 300 to 400, etc.
[06:27] <pitti> jrib: the only rule is that the asciibetical order is the correct order for applying them; they do not even need to start with a number
[06:27] <pitti> chickn: right, usually you should
[06:27] <jrib> ah ok, makes sense
[06:27] <pitti> chickn: however, if you pull stuff from upstream, convention is that you order them first, so that the distro-specific patches stay on top
[06:28] <chickn> gah i think i jacked my patch
[06:28] <pitti> chickn: that makes it easier to upgrade to a new upstream patch
[06:28] <pitti> s/patch$/version/
[06:28] <chickn> "No file to patch.  Skipping patch."
[06:28] <chickn> ooo my paths are all goofy.
[06:28] <pitti> chickn: ok, please try again later and rm -rf the udev tree and apt-get source it again
[06:28] <chickn> k.
[06:28] <chickn> i gotta goto class anyway. thanks!
[06:28] <pitti> Pretty much work, isn't it? Since this happens pretty often, I created a very dumb helper script 'dsrc-new-patch' for this purpose.
[06:29] <pitti> chickn: https://wiki.ubuntu.com/MOTU/School/PatchingSources
[06:29] <pitti> so, please rm debian/patches/90_penguins.patch
[06:30] <pitti> I know, it was precious and hard to do, but now it gets easier :)
[06:30] <pitti> Using this script, above steps would reduce to:
[06:30] <pitti>   ../dsrc-new-patch 90_penguins.patch
[06:30] <pitti>   sed -i 's/Linux/Penguin/g' README
[06:30] <pitti>   <press Control-D to leave the subshell>
[06:30] <pitti> that looks slightly better, doesn't it? If you like the script, please put it into your ~/bin, so that it is in your $PATH
[06:30] <pitti> but I had to torture you with the close-to-the-metal method for the sake of understanding.
[06:31] <elliot__> Yeah
[06:31] <pitti> but let's stay at udev a bit and do the second example
[06:31] <pitti> I promise, this will be the last complicated issue in this lesson
[06:31] <pitti> but it might teach you to never ever do a package without a proper patch system :)
[06:32] <pitti> dsrc-new-patch is currently too dumb to edit existing patches, or to put patches somewhere else than the top of the patch stack. If you need this, then you need to do the manual approach.
[06:32] <pitti> Assume we want to edit 50-result-whitespace.patch. This patch does not depend on the previous patches, so it's a bit easier that way, too:
[06:32] <pitti>   cd /whereever/you/unpacked/the/source/udev-093
[06:32] <pitti>   cp -a . /tmp/old
[06:32] <pitti>   pushd /tmp/old
[06:32] <pitti>   cp -a . /tmp/new; cd ../new
[06:32] <pitti> -> nothing new so far, just created a reference and a hack tree
[06:32] <pitti> but note that we did not apply any patch (since we assume that 50-result-whitespace.patch does not depend on its predecessors)
[06:33] <pitti> everyone got that?
[06:33] <elliot__> yeah, give me a moment
[06:33] <apral> yep
[06:33] <elliot__> yup
[06:33] <pitti>   patch -Nlp1 < debian/patches/50-result-whitespace.patch
[06:33] <pitti> above will apply the current version of the patch, so that you can edit it
[06:34] <pitti> we have to do that only in /tmp/new, so that our final diff call catches both the old patch and our new modifications
[06:34] <pitti>   sed -i '1 s/$/***** HELLO WORLD ****/' udev_selinux.c
[06:34] <pitti> (just some random braindead change)
[06:34] <pitti> now we have the updated tree in /tmp/new
[06:34] <pitti> so let's do the patch:
[06:35] <pitti>   cd ..
[06:35] <pitti>   diff -Nurp old new > 50-result-whitespace.patch
[06:35] <pitti>   popd
[06:35] <pitti>   mv /tmp/50-result-whitespace.patch debian/patches
[06:35] <pitti>   rm -rf /tmp/old /tmp/new
[06:35] <pitti> exactly the same commands as before
[06:35] <pitti> Now debian/patches/50-result-whitespace.patch contains both the original change and our modification of the first line of the source file.
[06:35] <pitti> but promised, from now on it will get really easy :)
[06:35] <pitti> any questions? is the issue of patch dependencies clear to everyone?
[06:35] <jrib> if 50-result-whitespace.patch depended on 01-lib-udev.patch for example.  Would the procedure then just be to apply 01-lib-udev.patch to old first and then do the same thing as before?
[06:35] <pitti> jrib: you got it
[06:36] <elliot__> Ready to continue
[06:36] <pitti> jrib: if you want to stay at the safe side, just apply all patches before the one you want to edit in /tmp/old
[06:36] <pitti> doing that can never hurt
[06:36] <jrib> good point
[06:36] <jorgp> im with you
[06:36] <pitti> Since this is so hideously complicated, patch systems were invented to aid you with that. Let's look at the most popular ones now (they are sufficient to allow you to patch about 90% of the archive's source packages; for the rest you have to resort to the manual approach above).
[06:37] <pitti> == pmount: cdbs with simple-patchsys ==
[06:37] <pitti> cdbs' simple-patchsys.mk module matches its name, it has no bells and whistles whatsoever. However, it is pretty popular since it is sufficient for most tasks, and long ago I wrote a script 'cdbs-edit-patch' which most people can live with pretty well. This script is contained in the normal cdbs package.
[06:37] <pitti> however, of course it only works for pacakges which actually use cdbs
[06:37] <pitti> i. e. which have a cdbs build-dependency
[06:38] <pitti> and include some stuff (simple-patchsys.mk in particular) from /usr/share/cdbs
[06:38] <pitti> ^ in debian/rules
[06:38] <pitti> please take a quick look at debian/rules in the pmount source
[06:38] <pitti> You just supply the name of a patch to the script, and depending on whether it already exists or not, it will create a new patch or edit an existing one.
[06:39] <pitti> this includes taking care of patch dependencies, editing patches in the middle of the stack, etc.
[06:39] <pitti> so, let's mess up pmount a bit
[06:39] <pitti> and add a new patch
[06:39] <pitti>   cd /whereever/you/unpacked/the/source/pmount-0.9.13
[06:39] <pitti>   cdbs-edit-patch 03-simple-readme.patch
[06:39] <pitti>   echo 'This should document pmount' > README
[06:39] <pitti>   <press Control-D to leave the subshell>
[06:39] <pitti> easy, isn't it?
[06:40] <pitti> ok?
[06:40] <jorgp> that was easy
[06:40] <pitti> Editing an already existing patch works exactly the same way.
[06:41] <pitti> so I won't give a demo
[06:41] <elliot__> got to go now. Whats the link for the chat log?
[06:41] <DShepherd> elliot__: topic
[06:41] <elliot__> DSheperd: Thanks
[06:41] <pitti> elliot__: https://wiki.ubuntu.com/MOTU/School/PatchingSources is the wiki page for it
[06:41] <pitti> BTW, "cdbs-edit-patch" is slightly misleading, since it actually only applies to simple-patchsys.mk. You can also use other cdbs patch system plugins, such as dpatch or quilt.
[06:41] <pitti> questions?
[06:42] <jrib> nope, this is a lot easier :)
[06:42] <pitti> I promised :)
[06:42] <pitti> == ed: dpatch ==
[06:42] <pitti> dpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch'
[06:42] <pitti>  The two most important things you should be aware of:
[06:42] <pitti>  * dpatch does not apply debian/patches/*, but instead applies all patches mentioned in debian/patches/00list, in the mentioned order. That means that you do not have to rely on asciibetical ordering of the patches and can easily disable patches, but you have to make sure to not forget to update 00list if you add a new patch.
[06:42] <pitti> (forgetting to update 00list is a common cause of followup uploads)
[06:43] <pitti>  * dpatch patches are actually scripts that are executed, not just patches fed to 'patch'. That means you can also do fancy things like calling autoconf or using sed in a dpatch if you want.
[06:43] <pitti> using dpatch for non-native patches is rare, and normally you do not need to worry about how a .dpatch file looks like
[06:43] <pitti> but I think it's important to mention it
[06:43] <pitti> so if you ever want to replace *all* instances of Debian with Ubuntu in all files, write a dpatch with a small shell script that uses sed
[06:43] <pitti> instead of doing a 300 KB static patch which won't apply to the next version anyway
[06:44] <pitti> The manpage is very good and has examples, too, so I will only give an example here:
[06:44] <pitti> This will edit an already existing patch and take care that all previous patches are applied in order:
[06:44] <pitti>   cd /whereever/you/unpacked/the/source/ed-0.2
[06:44] <pitti>   dpatch-edit-patch 05_ed.1-warning-fix
[06:44] <pitti>   <edit stuff, press Ctrl+D>
[06:44] <pitti> so that's exactly like cdbs-edit-patch
[06:44] <pitti> ok, now we edited a patch, that's pretty easy, right?
[06:44] <jorgp> yes
[06:44] <pitti> now let's create a new one; this is different from cdbs-edit-patch
[06:44] <pitti> (due to the 00list handling)
[06:45] <pitti>   dpatch-edit-patch foo.dpatch 06_testsuite-Makefile.dpatch
[06:45] <pitti>   <edit stuff, press Ctrl+D>
[06:45] <pitti>   echo foo.dpatch >> debian/patches/00list
[06:45] <pitti> This will create a new patch foo.dpatch relative to the already existing 06_testsuite-Makefile.dpatch. If your patch is very confined and does not depend on other patches, you can leave out the second argument.
[06:45] <pitti> please note the last action (adding your new patch at the appropriate position in the patch list)
[06:45] <jorgp> would it still be in this scope of discussion to talk about patches that don't apply cleanly
[06:46] <pitti> so again, dpatch does *not* rely on any asciibetical order by default
[06:46] <pitti> jorgp: of course
[06:46] <pitti> jorgp: if you get a source package from the archive, they should apply cleanly
[06:46] <pitti> jorgp: and if you got a patch from upstream and stick it into debian/patches/, but it doesn't apply, you have to fix it, of course
[06:47] <pitti> jorgp: cdbs-edit-patch and dpatch-e-p will just try and leave you in the shell with the *.rej files
[06:47] <pitti> then you simply resolve the *.rej files, and press C-D to update the patch
[06:48] <pitti> jorgp: is that what you meant?
[06:48] <jorgp> yes
[06:48] <jorgp> thanks
[06:48] <pitti> jorgp: however, please keep in mind that a dpatch is a patch with a shell script header, not a simple patch (as mentioned above)
[06:48] <pitti> so to avoid this entirely, you should never just stick an unknown patch into debian/patches
[06:48] <pitti> instead, you use *-edit-patch
[06:49] <pitti> and *then* use patch -p1 < /path/to/your/new/patch
[06:49] <pitti> edit the mess there
[06:49] <pitti> and let *-edit-patch create the actual patch in the source tree
[06:49] <pitti> ok?
[06:50] <jrib> yep
[06:50] <pitti> then let's go to the last patch system
[06:50] <pitti> == xterm: quilt ==
[06:50] <pitti> quilt is the other non-dumb standard patch system. Like dpatch, it has a list of patches to apply in patches/series (to use debian/patches, packages need to add a sylink).
[06:50] <pitti> It is non-trivial to set up and has a lot of advanced commands which make it very flexible, but not very easy to use.
[06:50] <pitti> nontrivial to set up for Debian source packages, that is
[06:50] <pitti> (it's not hard either, but more work than simple-patchsys, and even dpatch)
[06:50] <pitti> I will only show a small example here
[06:50] <pitti> in the xterm source
[06:51] <pitti> First, you can use the existing machinery to set up symlinks and directories for quilt:
[06:51] <pitti> cd /whereever/you/unpacked/the/source/xterm-216
[06:51] <pitti> debian/rules prepare
[06:51] <pitti> the 'prepare' target is not standardized; you need to look into debian/rules
[06:51] <pitti> however, it usually boils down to 'export QUILT_PATCHES=debian/patches' (which should work fine everywhere)
[06:51] <pitti> since quilt's default patch dir is ./patches
[06:51] <pitti> so some packages set up a symlink, some export QUILT_PATCHES, etc.
[06:52] <pitti> Now let's edit the already existing patch 901_xterm_manpage.diff:
[06:52] <pitti> quilt push 901_xterm_manpage.diff
[06:52] <pitti> this will apply all patches in the stack up to the given one
[06:52] <pitti> apply inline right in the source tree, that is
[06:52] <pitti> i. e. *not* in a temporary directory and not in a subshell
[06:52] <pitti> quilt keeps track of applied patches in the source tree internally
[06:53] <pitti> now let's edit a file that is already touched by the original patch
[06:53] <pitti>   sed -i 's/Copyright/Copyleft/' xterm.man
[06:53] <pitti> let's commit the change:
[06:53] <pitti>   quilt refresh 901_xterm_manpage.diff
[06:53] <pitti> So unlike the other patch systems, quilt works with patched inline sources, but keeps track of modifications.
[06:54] <pitti> k?
[06:54] <jrib> k
[06:55] <jorgp> k
[06:55] <pitti> Finally, let's add a new patch to the top of the stack:
[06:55] <pitti>   quilt push -a
[06:55] <pitti> '-a' means 'all patches', thus it applies all further patches after 901_xterm_manpage.diff up to the top
[06:55] <pitti>   quilt new muhaha.diff
[06:55] <pitti> register a new patch name (which we want to put on top of the patch stack)
[06:55] <pitti>   quilt add README
[06:55] <pitti> you have to do that for all files you modify, so that quilt can keep track of the original version
[06:55] <pitti> this tells quilt to keep track of the original version of README
[06:55] <pitti>   sed -i '1 s/^/MUHAHA/' README
[06:55] <pitti> modify the source
[06:56] <pitti>   quilt refresh
[06:56] <pitti> this will finally create debian/patches/muhaha.diff with the changes to README
[06:56] <pitti> as I already said above, quilt has a patch list, too
[06:56] <pitti> in debian/patches/series
[06:56] <pitti> which is much like debian/patches/00list for dpatch
[06:56] <pitti> and if you push -a, then the patch will land on top of the patch stack, and will automatically be put at the end of series
[06:57] <pitti> of course you can create the patch in other levels of the patch stack
[06:57] <pitti> but usually you want the top
[06:57] <pitti> sometimes, when you pull changes from upstream CVS, it's better to put them at the bottom of the stack
[06:57] <pitti> i. e. upstream changes shuold generally come *before* distro-specific changes
[06:57] <pitti> ok?
[06:57] <jrib> ok
[06:58] <pitti> [06:58] <pitti> As you saw, Debian source packages do not have any requirements wrt. structure, patch systems, etc., other source package systems like SRPM are much stricter wrt that. This of course means more flexibility, but also much more learning overhead.
[06:58] <pitti> As a member of the security team I can tell tales of the pain of a gazillion different source package layouts... :)
[06:58] <pitti> Therefore some clever people sat together the other day to propose a new design which would both give us a new and unified source package and patch system that uses bzr (with a quilt-like workflow). This would also integrate packages and patches much better into Launchpad and revision control in general.
[06:58] <pitti> Please take a look at https://wiki.ubuntu.com/NoMoreSourcePackages if you are interested in this.
[06:59] <pitti> I don't want to handle this here, since it's really distant future
[06:59] <pitti> oh, and officially again:
[06:59] <_ion> That was new to me. Sounds very cool.
[06:59] <pitti> [06:59] <pitti> The channel topic points to fabbione's logs, so that you can get the full conversation
[06:59] <pitti> There is also a wiki page https://wiki.ubuntu.com/MOTU/School/PatchingSources which provides most of above information in a more convenient format. However, it might be slightly out of date (it's from dapper times). Feel free to update the page and and add missing bits.
[06:59] <pitti> we are already at the end of the our
[06:59] <pitti> thank you for your attention!
[06:59] <jrib> sorry, one more question about quilt.  After our last command, the patches are still applied so do we have to unapply them before building the source package?
[06:59] <LjL> !openweek
[06:59] <ubotu> Ubuntu is hosting a series of introductory sessions for people who want to join the Ubuntu community, which all takes place in a week. See https://wiki.ubuntu.com/UbuntuOpenWeek. For logs please see https://wiki.ubuntu.com/ClassroomTranscripts and http://www.tonyyarusso.is-a-geek.com/irclogs/openweek/
[06:59] <pitti> I hope you could learn a bit
[07:00] <pitti> jrib: debclean will take care of that
[07:00] <apral> thanks for the lesson-have learnt much & have much to practise.never a hint of an accent.apologies for learning quietly.
[07:00] <jorgp> thank you again pitti
[07:00] <jrib> pitti: great, thanks for the session
[07:00] <pitti> jrib: and if you build without cleaning, then quilt will know that it already applied the patches
[07:00] <ailean> thanks pitti
[07:00] <pitti> jrib: as I said, quilt keeps track of everything, it's pretty hard to break
[07:00] <jonh_wendell> pitti, i'm sorry, i missed this one, i'll look logs...
[07:00] <DenisTheMenace> how can i build the source package?
[07:01] <pitti> I am terribly sorry that I cannot stay longer, I have to rush to a concert now
[07:01] <pitti> DenisTheMenace: debuild -us -uc -b
[07:01] <pitti> if you have any further questions, can you please mail me<EMAIL_ADDRESS>[07:01] <apokryphos> There'll be a one hour break now before the next talk, which will be on The Ubuntu Desktop Team.
[07:01] <DenisTheMenace> thanks pitti and have fun at the concert
[07:01] <jaclark> thanks!
[07:01] <pitti> the wiki page summarizes all of that, too, including the examples
[07:02] <pitti> any other questions?
[07:02] <pitti> (5 minutes to go)
[07:03] <jorgp> which patching system do you prefer and why?
[07:03] <pitti> jorgp: I use cdbs+simple-patchsys.mk for my packages
[07:04] <pitti> jorgp: mainly because I like it's simplicity, wrote cdbs-edit-patch which makes it easy to deal with it, and I don't want to use different systems
[07:04] <jorgp> im starting to really like cdbs
[07:04] <pitti> me too, the concept of factorization and modularization is The Right Thing (tm)
[07:04] <pitti> if only the docs were better :)
[07:04] <jorgp> hehe, thanks for the session
[07:05] <pitti> you're welcome
[07:05] <pitti> I'm glad if you could learn something
[07:05] <jorgp> yes, alot
[07:05] <pitti> and, please never hesitate to mail me or ask me in #ubuntu-devel if you have a question about a particualar package
[07:06] <a7p> is anyone doing transcripts?
[07:06] <LjL> i learned how clueless i am about packages ;-) but anyway, it was interesting to read... even given the little i had the background to understand - thank you pitti
[07:06] <pitti> a7p: see topic
[07:06] <LjL> !openweek | a7p
[07:06] <ubotu> a7p: Ubuntu is hosting a series of introductory sessions for people who want to join the Ubuntu community, which all takes place in a week. See https://wiki.ubuntu.com/UbuntuOpenWeek. For logs please see https://wiki.ubuntu.com/ClassroomTranscripts and http://www.tonyyarusso.is-a-geek.com/irclogs/openweek/
[07:06] <LjL> !logs
[07:06] <ubotu> Channel logs can be found at http://people.ubuntu.com/~fabbione/irclogs - See also !OpenWeek
[07:07] <pitti> ok, bye everyone!
[07:07] <Lesley> bye
[07:07] <tonyyarusso> a7p: Oh, btw, mind are pretty much automatic except for going through and splitting them by session.
[07:07] <tonyyarusso> *mine
[07:07] <a7p> tonyyarusso, I saw ...
[07:08] <apokryphos> dang
[07:08] <LjL> *grin*
[07:08] <apokryphos> too crowded :O
[07:09] <a7p> tonyyarusso, I thought about turning them into a block-text and a compact Q&A-section - but I think that's useless work - I will read the logs I am interested in and will extend the the Wiki-Howtos.
[07:09] <apokryphos> cool
[07:49] <stefg> ping
[07:49] <LjL> pong
[07:50] <stefg> Ok, i'm connected :-) (which isn't taken for granted if i watch how often i got disconnected today..)
[08:01] <seb128> hum, k
[08:01] <seb128> looks like it's DesktopTeam presentation time :)
[08:02] <seb128> hi everybody
[08:03] <ypsila> moin
[08:03] <seb128> I'm Sebastien Bacher, working for Canonical and member of the Ubuntu DesktopTeam
[08:03] <seb128> I'll do a short presentation first of what are the team goals and what is the team doing and what you can do if you want to contribute
[08:04] <seb128> then I'll reply to questions
[08:04] <seb128> !questions
[08:04] <ubotu> Please ask your questions here in #ubuntu-classroom-chat rather than #ubuntu-classroom (prefix them with "QUESTION: " or the instructor's nickname)
[08:04] <seb128> for questions then
[08:04] <seb128> and I (or somebody else if somebody wants to do the job) will copy them on that chan and I'll reply
[08:05] <seb128> quick round, do we have any member of the desktop team around who want to say hi and what they are doing quickly? ;)
[08:05] <seb128> dholbach? ;)
[08:06] <apokryphos> dholbach is away: /me -> walk
[08:06] <seb128> it's sort of dinner time for people on european time so maybe some people are not around
[08:06] <seb128> anyway, let's start
[08:06] <seb128> The desktop team is the team working on the Ubuntu desktop.
[08:06] <seb128> The main goals for the team are:
[08:06] <seb128> - update desktop packages when new upstream versions are available
[08:06] <seb128> - make easy for users to try new cool softwares by packaging them quickly
[08:06] <seb128> - have a good collaboration with upstream
[08:06] <seb128> - triage and fix desktop bugs
[08:06] <seb128> - make the Ubuntu Desktop ROCK!
[08:06] <dholbach> I'm Daniel Holbach, work for Canonical too and am part of the Desktop Team also. I work on Telepathy too, Accessibility, and a couple of other teams also. :-)
[08:06] <seb128> hey dholbach :)
[08:06] <dholbach> guys, I don't type as quick as seb128
[08:07] <dholbach> :)
[08:07] <seb128> note that the team is friendly and hugs are common around ;)
[08:07] <seb128>
[08:07] <seb128> Where you can find members of the desktop team:
[08:07] <seb128> - the #ubuntu-desktop@freenode IRC chan
[08:07] <seb128> - the<EMAIL_ADDRESS>mailing list
[08:07] <seb128>
[08:07] <seb128> feel free to join the chan or the list at any time if you want to ask any question or start working on the desktop and help the team
[08:08] <seb128>
[08:08] <seb128> let see what the team do and where you can help
[08:08] <seb128>
[08:08] <seb128> * Work on Bugs:
[08:08] <seb128> Bugs managements is a good part of the work for the desktop team at the moment and required to prioritise the work and now what problems should worked first
[08:08] <seb128> .
[08:08] <seb128> - Places for desktop bugs: https://bugs.launchpad.net/people/desktop-bugs/+assignedbugs, https://wiki.ubuntu.com/DesktopTeam/Bugs
[08:08] <seb128> - You can help the Desktop Team by joining the bug squad (http://wiki.ubuntu.com/BugSquad)
[08:08] <seb128>  * 236 members to date
[08:08] <seb128>  * ~60000 bug mails in the last year ;-)
[08:08] <seb128>  * Hug Days
[08:08] <seb128>  * forward useful bugs and investigate with upstream
[08:08] <seb128>  * make bug useful (reassign them to the right place, ask for required details, get debug backtrace for crashers, clean bugs that should be closed)
[08:08] <seb128> - help listing bugs that should be fixed for the next version of Ubuntu (or fixes to backport)
[08:08] <seb128>
[08:09] <seb128> bugs are taking a good part of our efforts at the moment and somebody anybody can help easily on
[08:09] <dholbach> ~60000 bug mails (only for desktop bugs)
[08:09] <seb128> dholbach: stat for this year?
[08:09] <dholbach> no stats yet
[08:10] <seb128> any, lot, so any help is welcome :)
[08:10] <dholbach> but I'd expect it to be   *1.5  at the very least
[08:10] <seb128> there is not only bugs though
[08:10] <seb128>
[08:10] <seb128> * Communication with other teams, upstream, Debian, etc:
[08:10] <seb128> We want to have a good relationship with the people we work with
[08:10] <seb128> .
[08:10] <seb128> - work on forwarding patches upstream (https://wiki.ubuntu.com/DesktopTeam/UpstreamDelta), having a low delta is better for everybody
[08:10] <seb128> - become point of contact between the distribution and upstream for packages you have an interest in
[08:10] <seb128> - work with other teams and Debian
[08:10] <seb128>
[08:11] <seb128> if people from upstream world want to work with us to make sure their software work nicely on Ubuntu they are welcome
[08:11] <seb128> and we are really looking for people to "adopt an upstream"
[08:11] <seb128> = being the point of contact in the distribution for a package and working with upstream making sure everybody is happy
[08:12] <seb128>
[08:12] <seb128> another point
[08:12] <seb128>
[08:12] <seb128> * Documentation:
[08:12] <seb128> A good documentation help new contributors to know where to start and also not-so-new team members how to do specific things, or what is to do by example
[08:12] <seb128> .
[08:12] <seb128> - help by writing specifications (i.e: documents on launchpad and the wiki that describes the changes we want to get implemented and how)
[08:12] <seb128> - update wiki pages for the DesktopTeam (https://wiki.ubuntu.com/DesktopTeam) (goals, list of things to do, documentation, how to start, etc)
[08:12] <seb128>
[08:12] <seb128> the documentation is important too
[08:12] <seb128> we are especially looking for good documentation helping the people who start
[08:13] <seb128> because it's not easy to start when you don't know what to do
[08:13] <seb128> and after some time people tend to forget the difficulties they have when they started
[08:13] <seb128> we have everything to win making it easy for people who want to participate :)
[08:13] <seb128>
[08:14] <seb128> next point
[08:14] <seb128> * Packaging:
[08:14] <seb128> Most of the work for a distribution is at the packaging level which means there is some place to contribute there too :)
[08:14] <seb128> .
[08:14] <seb128> - help doing desktop packages updates (update the package, test the new version, communicate issues with upstream is there is any)
[08:14] <seb128> - pick a package you have interest in (contacting the usual maintainer before starting to work on it might be a good idea) and start working on it. No need to have uploads right to start on a package, having your first updates mentored is usually a good start and way to learn. If you do a good job you can quickly become the maintainer for that package
[08:14] <seb128> - work on fixing issues by writting patches or backporting them from upstream and applying those fixes to the packages
[08:14] <seb128> - package new softwares
[08:14] <seb128>
[08:14] <seb128> we tend to keep up with the GNOME desktop updates usually
[08:14] <seb128> but there is lot of nice softwares around users would like to play with
[08:15] <seb128> and that would be nice if people who like to play with them etc would step and maintain the corresponding package
[08:15] <seb128> and being a contact point for those upstream too ;)
[08:15] <seb128>
[08:16] <seb128> and there is testing too!
[08:16] <seb128> * Testing:
[08:16] <seb128> - help testing GNOME, write specific test plans
[08:16] <seb128> * Other:
[08:16] <seb128> - new ideas: bring your good ideas of changes for the Ubuntu desktop and help to implement them
[08:16] <seb128> - teams: if you can motivate several people to work on a project creating a team around it is a good way to organize work: pda, printing, mono, telepathy, etc
[08:16] <seb128>
[08:17] <seb128> that's a summary of the things we are working on I think
[08:17] <seb128> if I forgot some let me know
[08:17] <seb128> now just a few examples of tasks where you could start
[08:17] <seb128> and we will do questions
[08:17] <seb128>
[08:17] <seb128> Examples of tasks to start:
[08:17] <seb128> - If you feel comfortable enough to reply to upstream comment about bugs there is a list of bugs that should be forwarded upstream available on http://tinyurl.com/yzd8t3 (you can also pick bugs not listed there yet, there is plenty of them not categorized to forward)
[08:17] <seb128> - Clean old 'NeedsInfo' bugs
[08:17] <seb128> - help out with packaging, maintaining, merging
[08:17] <seb128> - review bugs with patches attached
[08:17] <seb128> - look at bugs tagged as 'ubuntulove'
[08:17] <seb128> - write about the new cool changes happening to the UbuntuDesktop world for UWN: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter
[08:17] <seb128> - update wiki pages for the DesktopTeam to make them useful, especially for new contributors (having an updated and useful https://wiki.ubuntu.com/DesktopTeam/TODO would be nice by example)
[08:17] <seb128> Start here: https://wiki.ubuntu.com/DesktopTeam/GettingStarted
[08:18] <seb128>
[08:18] <seb128> ok
[08:18] <seb128> that's done for the presentation
[08:18] <seb128> let's do question then
 QUESTION: Ubuntu introduced the Apps/Places/System trinity to gnome, so the System menu is doing the job of a system-tool like yast/drakconf/foobar. But what about xorg.conf generation anything like SaX in the pipeline? (I hate to advice people: You've got to sudo dpkg-reconfigure xserver-xorg! reaction: ".... dpkg....what???")
[08:18] <seb128> anybody wants to pick the interesting ones from -chat and copy there on the chan?
[08:18] <seb128> apokryphos: thank you ;)
[08:19] <apokryphos> np 8)
[08:19] <seb128> stefg: the DesktopTeam doesn't maintain xorg, xorg is big enough to have it's own team. I think that xorg has an autoconfig branch and it's going to land to feisty
[08:19] <Circus-Killer> QUESTION: For now it seems to me that the Desktop team is a mix of all other themes together? You pointed out fixing bugs (not for the bugsquad theme?) and working on documentation (not for the documentation theme?) Is this correct, or just a bit confusion from my point of view?
[08:20] <LjL> !questions
[08:20] <ubotu> Please ask your questions in #ubuntu-classroom-chat
 QUESTION: For now it seems to me that the Desktop team is a mix of all other themes together? You pointed out fixing bugs (not for the bugsquad theme?) and working on documentation (not for the documentation theme?) Is this correct, or just a bit confusion from my point of view?
[08:20] <stefg> That's not a xorg-thing... will we have a graphical tool to configure xorg is the question...
[08:20] <seb128> stefg: ah, nothing planned for that no
[08:20] <seb128> stefg: the way to go is autoconfig from xorg rather than a tool to do it
[08:21] <apokryphos> stefg: Kubuntu is working on one for Feisty, as I recall.
[08:21] <seb128> if I understood what the xorg team wants to do
[08:21] <apokryphos> (in kubuntu there is only some basic configuration available for it at the moment, with kde-guidance)
[08:21] <seb128> ok, I'm not sure, better ask some xorg guy
[08:22] <seb128> nothing planned from the desktop team side
[08:22] <seb128>
[08:22] <seb128> rulus: good question
[08:22] <seb128> bugsquad is not specific to the desktop
[08:22] <seb128> but the desktop is a component which gets a lot of bugs
[08:23] <seb128> and you can really help by joining the bugsquad team and help on desktop bugs
[08:23] <seb128> because the time we spend fighting bugs we can't spend it working on the desktop
[08:23] <seb128> and that's not easy to find a balance
[08:23] <seb128> documentation is made by the documentation team
[08:23] <seb128> I was rather speaking about documentation about the desktop organisation
[08:23] <seb128> and where to start etc
[08:24] <seb128> which should be written for the team by people around the team
[08:24] <seb128> the ubuntu-doc team has enough to do documenting Ubuntu
[08:24] <seb128> without starting documenting how teams are working
[08:24] <seb128>
 QUESTION: What is backporting? Bringing applications that are not part of ubuntu into ubuntu?
[08:25] <seb128> backporting is taking something new and bringing it where you want
[08:25] <seb128> not sure if that's clear
[08:25] <seb128> the backport team takes packages from feisty and build them on edgy by example
[08:25] <seb128> new version of software
[08:25] <apokryphos> frafu: generally it's done when an ubuntu release has an older version of a popular package, such as, say, firefox
[08:25] <seb128> like they will likely build gaim 2.0 and build it on edgy
[08:26] <seb128> so you will get a backport of that new version of gaim for edgy
[08:26] <seb128> we "backport" patches too
[08:26] <seb128> which means take fix from a new version
[08:26] <seb128> and apply them to the previous one to fix the issue
[08:26] <seb128> s/the issue/an issue
[08:26] <seb128>
 QUESTION: do you guys have plans on releasing a live DVD with both Ubuntu and Kubuntu
[08:27] <seb128> not that I know
[08:27] <seb128> but if somebody wants to work on that as project that should be doable
 QUESTION: how can I look for upstreams that haven't been adopted yet?
[08:27] <seb128> maybe that could be a spec for next cycle ;)
[08:27] <seb128>
[08:27] <seb128> samgee: that is a good question
[08:28] <seb128> we discussed monday on the first Desktop session about having an "ambassador" noted on launchpad for a package
[08:28] <seb128> that is not done yet
[08:28] <seb128> at the moment the best is probably to look at the changelog to know who has worked on the package
[08:28] <seb128> and to ask him
[08:29] <seb128> usually people working on a package should know about that
[08:29] <apokryphos> Any other questions?
[08:29] <seb128> if they don't there is probably nobody doing that job for the package at the moment
 QUESTION: how's telepathy at the moment
 and the integration :)
[08:30] <seb128> dholbach? ;)
[08:30] <amnesia> :)
[08:30] <seb128> I would say than dholbach and the telepathy do a rocking job
[08:30] <seb128> we probably have most of it packaged for edgy
[08:30] <dholbach> amnesia: as clients we have gossip-telepathy and cohoba in feisty
[08:31] <dholbach> gossip-telepathy works quite well at the moment and gabble (jabber) and butterfly (msn) support are good enough to use
[08:31] <seb128> telepathy -> telepathy-team
[08:31] <amnesia> ah ok, you just mentioned telepathy in the beginnning...will ask them then
[08:31] <dholbach> the upstream developers are working like mad and audio conferencing is said to work quite good as well (I never got around to test it yet)
[08:31] <dholbach> (farsight is doing that part)
[08:32] <amnesia> ok will drop by then for a little testing/helping
[08:32] <seb128> that's a good example of how people interested in a particular topic can group together and create a team
[08:32] <seb128> team are goods too :)
 QUESTION: Your top priorities for Feisty - any details about how Beryl will be implemented in it (by default)?
[08:32] <dholbach> sudo apt-get install telepathy-gnome      in feisty should provide you with all that's needed
[08:32] <amnesia> dholbach: cool thanks
[08:32] <seb128> top priorities?
[08:33] <seb128> GNOME 2.18
[08:33] <seb128> compiz or beryl (not decided yet which one)
[08:33] <seb128> and I would like beagle or tracker (not decided which one neither) on the desktop too
[08:33] <seb128> an app to replace disks-admin would be welcome too
[08:33] <amnesia> seb128: you would means one of them will be in?
[08:33] <seb128> amnesia: "them" being?
[08:34] <amnesia> beagle or tracker
[08:34] <seb128> I would like to get one yep
[08:34] <amnesia> great!
[08:34] <seb128> we will likely have tracker to universe soon
[08:34] <seb128> maybe next week
[08:34] <dholbach> . o O { I would like to get a pony }
[08:34] <seb128> I've contacted upstream this week about that
[08:35] <_ion> Ignoring indexing, the possibilities from a shared metadata database with a dbus API are appealing.
[08:35] <seb128> then we will ask for user feedback and see which would fit better
[08:35] <seb128> tracker looks nice
 QUESTION: are you guys working on any improvement on the applications' menu for next version?
[08:36] <seb128> no
[08:36] <seb128> does it need improvement? ;)
[08:36] <amnesia> mac-style?
[08:36] <seb128> we have gnome-main-menu (aka slab), the menu from novell packaged
[08:36] <seb128> and we will likely have it on the CD for feisty, but not as default one
[08:36] <apokryphos> meduxa: any specific thoughts?
[08:37] <seb128> maybe with a panel profile switcher app (one as been worked during SoC2006)
[08:37] <seb128> which would allow to pick a standard linux layout or a windows like one
[08:37] <meduxa> freedesktop rules are difficult to understand for customice the menu so
[08:37] <seb128> it's on my list of things I would like to get for feisty, it'll depend on how busy I'll be though
[08:37] <seb128> contributions are welcome ;)
[08:37] <bhale> meduxa: that is why we have alacarte
[08:38] <bhale> or whatever it is called now, simple menu editor
[08:38] <meduxa> graphical interfaces for customicing are the only good choice for users
[08:38] <seb128> meduxa: alacarte (menu editor) should "just work", no?
[08:38] <meduxa> yes
 QUESTION: There are a bunch of D-Bus APIs that have been showing up, some of varying quality, and D-Bus lacks a versioning scheme (no sonames etc.). i've noticed already that supporting different API revisions is causing trouble for applications. is there a game plan for bus API versioning?
[08:39] <meduxa> it does, the point is if you have alacarte stopeed from improvements or you are developing more features for it
[08:39] <seb128> alp: dbus is 1.0 now
[08:39] <seb128> API is stable and will not change any time soon
[08:39] <meduxa> thks
[08:39] <alp> (am talking about the APIs themselves, not the library implementation)
[08:40] <seb128> meduxa: we are not working on it atm, if you have suggestion feel free to open feature request or mail the desktop list about them
[08:40] <seb128> alp: we don't plan to do any distribution specific work on that at the moment no
[08:40] <sox> QUESTION: There's a project to develop a native "SAP GUI" ( in deb  format) for Ubuntu feisty?
[08:40] <apokryphos> !questions
[08:40] <ubotu> Please ask your questions in #ubuntu-classroom-chat
[08:41] <seb128>
[08:41] <seb128> apokryphos: next one? ;)
 QUESTION: speaking of dbus. we definitely need dbus for volume control and totem too. are they planned/done yet?
[08:41] <seb128> no
[08:41] <seb128> not planned nor done
[08:41] <seb128> contributions are welcome
[08:41] <seb128> there is lot of such "small improvements" which would be nice
[08:42] <seb128> maybe create a spec for them so it get developer time next cycle :)
[08:42] <seb128>
 QUESTION: About apps menu, maybe at gnome is ok, but at kde is a complete mess. It needs imporvement.
[08:42] <seb128> dunno about KDE
[08:42] <seb128> anybody from the kubuntu team around?
[08:42] <apokryphos> andresmujica: I completely agree. It looks like Kubuntu might be adopting the kickoff menu for feisty
[08:42] <apokryphos> ubotu: kickoff
[08:42] <ubotu> kickoff is a new KDE menu developed by SUSE. It organises items differently, has an integrated Beagle search, and been put through extensive usability testing in the Novell usability lab. See http://www.kdedevelopers.org/node/2283
[08:42] <seb128> DesktopTeam does Ubuntu Desktop in fact
[08:42] <apokryphos> there's a nice presentation of it there
[08:42] <seb128> kubuntu-team does KDE
 QUESTION: mac-menu integration? there is a patched libgtk around, works alright actually. could it go in feisty? any thoughts on that?
[08:44] <seb128> amnesia: no idea, I don't use mac and don't know what mac-menu looks like and dunno about that bug
[08:44] <seb128> any pointer is welcome :)
[08:44] <seb128> feel free to mail the desktop list about that
 QUESTION: just from curiosity about how things work - by which way will the final decision be made for whether the default manager will be Beryl or Compiz?
[08:45] <seb128> Bourlotieris: the TB (technical board) will make the call
[08:45] <seb128> that's likely to depends on the feedback we get on them
[08:46] <apokryphos> Bourlotieris: at the moment it looks like it'll most likely be on the grounds of stability
[08:46] <seb128> how actively they are maintained
[08:46] <seb128> and what we think about them
[08:46] <seb128> I would be in favor of compiz for my part
 QUESTION: Can you describe the process from recieving a suggestion of a new feature or improvement related with usability until it is decided to include it in a new version or desestimated?
[08:46] <seb128> beryl dialog scares me with its zillion of un-understable options and weird effects
[08:46] <bhale> http://wiki.ubuntu.com/CompizOnFeisty < compiz is very well integrated today
[08:46] <apokryphos> seb128: they don't plan that settings manager to be available directly to the end users
[08:46] <seb128> and compiz used by other distros too, etc
[08:47] <apokryphos> there's another settings manager which they're using; developed mainly by Amaranth I believe
[08:47] <seb128> and looks stabler and seems to be doing what we need
[08:47] <seb128>
[08:47] <apokryphos> (there's a question above, by meduxa )
[08:48] <seb128> meduxa: no fixed process and we don't have an usability team atm in fact (just one usability guy)
[08:48] <seb128> either discussions on the list or on bugs
[08:48] <seb128> specs are probably things which work the best for non trivial changes
[08:48] <seb128> for details good sense and convincing upstream or the maintainer is probably the way ;)
 QUESTION: irda support? I need to apt-get install irda-utils, enable irda in /etc/defaults, then it works. need to install irda-tray (not in ubuntu) to be able to beam files from/to my cell phone. Anything planned to make it easier?
[08:49] <amnesia> ..like the bluetooth love ubuntu gets nowadays, but irda is on almost every phone nowadays
[08:50] <seb128> amnesia: no, no plan from me
[08:50] <seb128> simple reason: I've no irda device
[08:50] <dholbach> amnesia: could you mail the motu list and see that irda-tray gets included in ubuntu?
[08:50] <seb128> if you have an interest to irda and what to help you are most welcome
[08:50] <amnesia> seb128: what to do to help there?
[08:50] <amnesia> dholbach: I wanted to package it today but I can do that, they do it surely better
[08:51] <dholbach> amnesia: or get your package reviewed - that's cool
[08:51] <dholbach> amnesia: Rock On!
[08:51] <seb128> amnesia: if only archive change are required (like move packages to ubuntu-desktop), mail ubuntu-devel to describe what needs to be done and why
[08:51] <seb128> if things need to be packaged or maintained, help doing the job
[08:51] <amnesia> seb128: cool!
[08:52] <seb128> amnesia: if you need somebody to review your package just ask on IRC
[08:52] <seb128> I'm sure some MOTU or some Desktop Team people will be happy to help you on that :)
[08:52] <amnesia> will do, want it to work out of the box on feisty
[08:52] <seb128> rock on!
[08:52] <amnesia> :)
[08:52] <seb128> lot of hugs for amnesia everybody ;)
[08:53] <apokryphos> ok, if there are no more questions we'll take a short break before the next talk, which will be "Maintaining an Ubuntu Package", by Jordan Mantha
[08:53] <amnesia> will do what I can, maybe others will follow
[08:53] <apokryphos> thanks seb128 8)
[08:53] <seb128> thank you for everybody for the good questions
[08:53] <bhale> zogads Jordan Mantha
[08:53] <amnesia> seb128: thanks for being here
[08:53] <Bourlotieris> Thank you, really interesting
[08:53] <meduxa> nice talk, what a short hour
[08:54] <seb128> good :)
[08:54] <frafu> thanks
[08:54] <LaserJock> bhale: now now, no need to get excited ;-)
[08:54] <seb128> feel free to join #ubuntu-desktop or the desktop list at any time if you want to discuss desktop things
[08:54] <rulus> thanks for your session seb128!
[08:55] <apokryphos> gah, this topic is getting tighter all the time :P
[08:55] <bhale> oops
[08:56] <jean__> thanks
[08:56] <ajmitch> yay LaserJock
[08:56] <rulus> !questions
[08:56] <ubotu> Please ask your questions in #ubuntu-classroom-chat
[08:57] <LjL> only, "/msg ubotu logs" won't give you the -classroom specific factoid... :-\
[08:57] <jean__> thanks seb128
[08:59] <apokryphos> beh
[09:01] <LaserJock> ok, time to get started?
[09:01] <apokryphos> LaserJock: sure; take it away :)
[09:01] <sox> come on!
[09:02] <LaserJock> Hello everybody!My name is Jordan Mantha and I'm a PhD Chemistry student and Ubuntu volunteer.
[09:02] <LaserJock> In Ubuntu I'm a Universe developer, a part of the Documentation Team, on the Edubuntu Council, and am just generally an Ubuntu-holic.
[09:02] <LaserJock> Today I want to talk a little about what how we maintain software once it's already in our software repositories (Main, Restricted, Universe, Multiverse)
[09:02] <ailean> nice to meet you - you a scot?
[09:02] <LaserJock> me? now
[09:03] <LaserJock> just your typical mutt American
[09:03] <ailean> sorry, continue :)
[09:03] <LaserJock> so far during the Open Week we've had talks on how to package
[09:03] <LaserJock> how to patch packages
[09:03] <LaserJock> etc.
[09:04] <LaserJock> so I'm not really going to cover that so much
[09:04] <LaserJock> I think there are 3 things that are important to keep in mind here:
[09:04] <LaserJock> 1. Ubuntu is intimately connected to Debian
[09:04] <LaserJock> 3. Ubuntu relies on thousands of "upstreams"
[09:04] <LaserJock> 2. Ubuntu uses Launchpad ( http://launchpad.net ) for virtually all package maintenance
[09:05] <LaserJock> Ubuntu is a Linux distro
[09:05] <LaserJock> which among other things, means it usually doesn't write it's own software
[09:05] <LaserJock> but instead collects other people's software (upstreams) and "glues" them together and makes sure they work right
[09:06] <LaserJock> so lets look at the 3 things I've outlined above in a little more detail
[09:06] <LaserJock> 1. Ubuntu is intimately connected to Debian
[09:06] <LaserJock> Ubuntu is a Debian-based distro
[09:06] <LaserJock> that's probably not surprising to anybody
[09:07] <LaserJock> but we don't fork Debian
[09:07] <LaserJock> instead at the beginning of each development cycle we take a snapshot of Debian's unstable repo
[09:08] <metres> hi guys, Im trying a recompilation of my kernel, but I have problem..., I just installed Edgy on my amd64, I downloaded the source linux-2.6.19 from kernel.org, unpack it, but when I try make xconfig, I got this response : "make[1] : *** Pas de rgle pour fabriquer la cible  scripts/kconfig/.tmp_qtcheck , ncessaire pour  scripts/kconfig/qconf.o . Arrt." Do anyone have a clue ?
[09:08] <LaserJock> and we spend much of the first half of the development release cycle merging those changes back into Ubuntu
[09:08] <rulus> metres: #ubuntu please
[09:08] <LaserJock> metres: #ubuntu is a better place to go
[09:08] <metres> thanks I'LL try this
[09:09] <LaserJock> ok, so the question is how do we keep track of what we've changed and what's straigh from Debian
[09:09] <LaserJock> to differentiate we use a particular versioning scheme
[09:09] <LaserJock> any source package that has been changed or modified in any way will give a ubuntuX version put on the end
[09:10] <LaserJock> where X starts at 1 and just increments with each upload we make that keeps the same base Debian version
[09:10] <LaserJock> so when we go through our merging/syncing phase at the beginning of the cycle we determine which packages were changed in the previous version
[09:11] <LaserJock> and if they weren't changed, we just sync the Debian package straight over
[09:11] <LaserJock> however, if there was a change a handy script called Merge-o-Matic (MoM) will attempt to merge the package in a semi automated way
[09:12] <LaserJock> the thing to note here is that *every* package that had a previous Ubuntu change has to be manually checked before it is either synced (if Debian picked up our changes and we don't need them anymore) or merged (we still need them)
[09:13] <LaserJock> so just to see the scale we are taking about here are some stats for edgy:
[09:13] <LaserJock> In the Main repo there are a total of 5382 source package
[09:14] <LaserJock> 978 of them have ubuntuX versions and have to be manually checked
[09:14] <LaserJock> in Universe there are 18656 source packages
[09:14] <LaserJock> 1250 of them have ubuntuX versions
[09:15] <LaserJock> so that's over 2000 packages that have to be manually checked, merged, built, and tested before being uploaded
[09:15] <LaserJock> we have probably around 100 people doing this work
[09:15] <LaserJock> around 80% are volunteer community members
[09:16] <LaserJock> ok, let's take a question break
[09:16] <bhale> < rmjb> QUESTION: If every package with an Ubuntu change needs to be manually checked, what does MoM do?
[09:16] <LaserJock> MoM can make the process easier
[09:16] <LaserJock> what you are looking for in a merge is what Ubuntu changes exist
[09:17] <LaserJock> and why they are there
[09:17] <LaserJock> so you have to look at the difference between the Ubuntu package and the Debian package it was based on
[09:17] <LaserJock> you also have to look at what has changed since then in Ubuntu
[09:17] <LaserJock> sorry Debian rather
[09:18] <bhale> < andresmujica> QUESTION:  Does it means that Debian takes changes made here at ubuntu for their own packages???
[09:18] <LaserJock> and then go back and make sure you only add in the Ubuntu changes to the new Debian version
[09:18] <bhale> (sorry, questioner left)
[09:18] <LaserJock> yes, that is correct
[09:18] <LaserJock> we send all the differences we make to Debian
[09:18] <bhale> as an example, Debian and Ubuntu mono teams share many members, and changes flow in 2 directions
[09:19] <LaserJock> and the Debian maintainers are free to take our changes
[09:19] <LaserJock> bhale: exactly
[09:19] <bhale> patches are posted here in an automated fashion as well:
[09:19] <LaserJock> we try to maximize cooperation and minimize divergence
[09:19] <bhale> http://patches.ubuntu.com/
[09:19] <LaserJock> and also on the individual package pages on packages.qa.debian.org
[09:20] <bhale> < ailean> QUESTION: can you point us in the direction of some tutorials?
[09:20] <LaserJock> yes
[09:20] <LaserJock> there is an Ubuntu Packaging Guide
[09:20] <LaserJock> it is shipped in both the Ubuntu and Kubuntu help systems
[09:21] <apokryphos> ubotu: packaging
[09:21] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
[09:21] <LaserJock> and can also be found on help.ubuntu.com
[09:21] <LaserJock> yeah ^^
[09:21] <bhale> we have two more and I hope we can get going again
[09:21] <bhale> < urbnsr> QUESTION: Are there packages that start for ubuntu only or do all packages have to come via Debian?
[09:21] <LaserJock> also check out the Debian documentation at www.debian.org/devel/
[09:21] <LaserJock> yes, some packages start in Ubuntu
[09:21] <bhale> no, Ubuntu can get new packages, see http://wiki.ubuntu.com/REVU for submitting new ones
[09:21] <LaserJock> some start completely elsewhere
[09:21] <bhale> last question.
[09:22] <LaserJock> the vast majority come from Debian though
[09:22] <bhale> < andresmujica> QUESTION:  It seems that there' s some work duplicated at several levels, package creator, debian, and ubuntu.. any proposal or way to improve this? or is defacto way?
[09:22] <LaserJock> well, in essence what we try to do in Ubuntu is take what Debian maintainers do and add on top of it
[09:22] <LaserJock> not repeat it
[09:22] <LaserJock> so if there's a bug that Debian should know about we forward it
[09:23] <LaserJock> if we patch something that is useful for Debian we try to get it to them
[09:23] <LaserJock> so the idea is we are enhancing rather then duplicating Debian's work
[09:24] <LaserJock> there are efforts like utnubu (ubuntu backwords)
[09:24] <LaserJock> to help make sure Ubuntu changes get back into Debian
[09:24] <LaserJock> but mostly just good communication
[09:24] <LaserJock> bhale: done?
[09:24] <bhale> LaserJock: yes, sorry.
[09:24] <LaserJock> OK, so the second item: Ubuntu relies on thousands of "upstreams"
[09:25] <LaserJock> so Debian is our first upstream most of the time
[09:25] <LaserJock> but they have upstreams too
[09:25] <LaserJock> the original software authors
[09:26] <LaserJock> and if we want our work to help the maximum number of people we need to get our changes to them
[09:26] <LaserJock> also, as software develops, it doesn't do so on the same time line
[09:26] <LaserJock> so we have to be aware of thousands of different projects all releasing at different times
[09:27] <LaserJock> and we have to work to make sure we can produce the most stable and usable distro we can
[09:27] <LaserJock> that really leads to my 3 point: Ubuntu uses Launchpad ( http://launchpad.net ) for virtually all package maintenance
[09:28] <LaserJock> Launchpad is essentally a very large distro managment web app
[09:28] <LaserJock> developed by Canonical (the Ubuntu sponsor company)
[09:29] <LaserJock> and it includes a bug tracker (Malone), specification tracker, translation system, support tracker, etc.
[09:29] <LaserJock> it also houses our archive maintainence and build structure
[09:30] <LaserJock> Launchpad can sometimes be a bit confusing to use when you first get started with it
[09:30] <LaserJock> so here's my #1 tip, learn how Launchpad uses URLs
[09:30] <LaserJock> so you can "build" your own URL to go where you want
[09:31] <LaserJock> it makes finding things pretty easy
[09:31] <LaserJock> For instance, if you want to know about a particular source package use:
[09:31] <LaserJock> http://launchpad.net/distros/ubuntu/+source/<packagename>
[09:31] <LaserJock> If you want to see all the bugs for a package just add on +bugs:
[09:31] <LaserJock> http://launchpad.net/distros/ubuntu/+source/<packagename>/+bugs
[09:31] <LaserJock> Parts of the URL with the + in front are important, they are like modifiers to the thing that goes before it. In this case we want to see bugs for <packagename>
[09:32] <LaserJock> now one of the things that makes Launchpad good for package maintainance and communication with upstream is you can link to other bug trackers
[09:32] <LaserJock> for instance, right now, Launchpad can link and track bugs in Debian, Gnome, KDE, Mozilla to I believe
[09:33] <LaserJock> so if somebody files a bug in Launchpad for Ubuntu
[09:33] <LaserJock> and I see that Debian has reported the same bug
[09:33] <LaserJock> I can link to that one and watch it's progress
[09:33] <LaserJock> and be notified when it's been fixed so that I can make sure to get those fixes
[09:34] <LaserJock> bhale: ok, lets take some more questions
[09:34] <bhale> cool.
[09:34] <bhale> this one is kind of off the wall but you can handle it
[09:34] <bhale> < proppy> QUESTION: sometimes when we package for multi distribution and there is different dependencies, we supply multi control files for each distribution (for example control.dapper which differ from control.sarge), i believe this is not the correct way to do it?
[09:34] <LaserJock> I love off the wall questions :-)
[09:35] <bhale> I know :)
[09:35] <bhale> (now might be a good time to mention bzr!)
[09:35] <LaserJock> proppy: really what we'd rather see is that difference in versioning and in a revision control
[09:36] <LaserJock> another project that Canonical is supporting is the bazaar revision control system
[09:36] <LaserJock> Launchpad now supports bazaar
[09:36] <LaserJock> so that each Launchpad user can keep different "branches" of what they are working on
[09:36] <LaserJock> you can even use a Launchpad team to control access
[09:37] <LaserJock> so rather then individual control files
[09:37] <LaserJock> I'd rather see a dapper branch or a sarge branch on bazaar.launchpad.net
[09:37] <LaserJock> proppy: hopefully that answers your question a bit
[09:37] <bhale> another choice for cooperating with debian developers is svn for your team on alioth.debian.org and make branches off of the trunk
[09:37] <bhale> < gumpa> QUESTION: is Launchpad a Zope3 app?
[09:37] <proppy> LaserJock: thanks
[09:38] <LaserJock> I believe so
[09:38] <bhale> gumpa: the web portion, yes.
[09:38] <LaserJock> ajmitch: you might now better than I
[09:38] <bhale> < andresmujica> QUESTION:  About upstream bug trackers, should i search for a similar bug or report a knew one pointing to the bug reported..
[09:38] <ajmitch> LaserJock: yes, it is
[09:38] <LaserJock> well, it doesn't really hurt anything to file the bug in Ubuntu
[09:39] <LaserJock> if you also report it in the upstream bug tracker it's nice to link to that in the Ubuntu bug report on Launchpad
[09:39] <LaserJock> so we can keep track
[09:39] <LaserJock> but yeah, always searching for an existing report of your bug is good
[09:40] <LaserJock> it's amazing how much time we can spend just tracking down duplicates
[09:40] <bhale> ok thats all for questions atm
[09:40] <LaserJock> andresmujica: does that answer your question?
[09:40] <andresmujica> yeap
[09:40] <andresmujica> tks
[09:41] <LaserJock> ok, that's a basic overview of what maintaining a package in Ubuntu involves
[09:41] <LaserJock> other then the nitty gritty details of the actual packaging
[09:41] <LaserJock> so I'd like to open it up for any general package maintainance questions
 QUESTION: Given that i know which dependencies differs from the debian packages, is there a way to provide theses information *in* the debian packages, to they get applied when synced from the unstable repository ?
[09:42] <bhale> you can make a file called control.in
[09:42] <LaserJock> so you want to make it so Ubuntu can sync even though there are some slight dependency differences
[09:42] <LaserJock> ?
[09:42] <bhale> that dynamically builds a control file, similar to auto*
[09:43] <proppy> nice
[09:43] <bhale> check the Debian Developers Guide for that
[09:43] <proppy> we have access to debian unstable repository
[09:43] <proppy> and locally compile and package for ubuntu
[09:43] <proppy> so i want to make the sync process smooth
[09:44] <LaserJock> proppy: in essence then maintaining it in Ubuntu would be filing a bug report with a debdiff, worst case
[09:44] <bhale> if you are actively maintaining the package in Debian and want to make Ubuntu changes, you can contribute them to the archive via a MOTU
[09:44] <bhale> (or becoming one yourself)
[09:44] <bhale> sorry we have to keep going
[09:44] <proppy> ok thanks
[09:44] <proppy> :)
[09:44] <bhale> you might want to check out #ubuntu-motu
[09:44] <proppy> yep this is a bit specifiq
[09:44] <bhale> they can answer any of your questions, capable folks!
[09:44] <bhale> < rmjb> QUESTION: how important is the maintainter's relationship with the upstream developer? Do you need their permission before packaging thier software for Ubuntu?
[09:45] <LaserJock> interesting question
[09:45] <bhale> you don't need their permission of course, we deal in freely distributable software
[09:45] <bhale> it is my opinion that the realtionship in general is very important
[09:45] <LaserJock> If it's free software then you don't *have* to get there permission
[09:46] <LaserJock> but it's rather bad form to go putting somebodies work in a distro that will go to a few million people and not tell them :-)
[09:46] <LaserJock> in my experience though upstreams are pretty excited to get their work in a distro
[09:46] <rmjb> I guess the least you can do it try to inform them
[09:46] <LaserJock> and usually will work with you pretty well
[09:46] <bhale> it would be polite to do so
[09:46] <LaserJock> I maintain 2 packages in Debian
[09:46] <LaserJock> and I talk with both of the upstreams fairly often
[09:47] <LaserJock> and they help me by making any changes necessary to the build structure to work with debian packaging
[09:47] <LaserJock> ok, I'll take the 2 last questions here and wrap it up
[09:48] <bhale> < andresmujica> QUESTION:  Is any kind of public building machine or should i compile at my own server and then distribute the package?
[09:48] <LaserJock> well, the answer is, not quite yet
[09:48] <LaserJock> I know that Canonical is working on building personal package archives into Launchpad
[09:48] <LaserJock> that will allow anybody to upload and build packages in the own personal repo space
[09:49] <LaserJock> but that doesn't exist right now
[09:49] <cbx33> wow
[09:49] <bhale> at this time what you want is pbuilder
[09:49] <bhale> docs on the wiki
[09:49] <LaserJock> however, getting your package into Ubuntu does have that advantage of building your package on all the supported apps
[09:49] <cbx33> pbuilder rocks
[09:49] <LaserJock> *arch rather
[09:50] <bhale> alright, one more.
[09:50] <bhale> < cbx33> QUESTION: Where can I get more information about maintaining packages using make?  How much make knowledge is needed?
[09:50] <LaserJock> well, of course you can read up on autotools stuff
[09:50] <LaserJock> but in essence you don't really need to know all the details to package
[09:50] <LaserJock> but the more knowledge you have the better off you'll be
[09:51] <LaserJock> but it's not uncommon for programs to not use make at all
[09:51] <LaserJock> for instance a lot of python packages use distutils
[09:51] <LaserJock> etc.
[09:51] <bhale> < LjL> QUESTION: Would that, once it exists, also allow building packages without actually having all the required -dev dependencies installed on the local machine, and/or setting up a chroot environment, and similar relatively onerous undertakings?
[09:51] <apokryphos> (indeed, all of KDEis switching to cmake)
[09:52] <bhale> canonical build service related ^
[09:52] <LaserJock> LjL: indeed it would
[09:52] <bhale> IMO the build service is not meant for testing the build of your package
[09:52] <LaserJock> although it would be much better to test your packages before hand
[09:52] <bhale> but building and publishing a 'canonical' copy once youve done the work
[09:52] <LaserJock> bhale: right
[09:53] <bhale> < somerville32> QUESTION: Can you compare and constrast Stable Update Releases and Backports?
[09:53] <bhale> good question.
[09:53] <LaserJock> LjL: we are getting pbuilder docs better and better so hopefully it will be less onerous
[09:53] <bhale> https://wiki.ubuntu.com/StableReleaseUpdates
[09:53] <LaserJock> yes, good question
[09:54] <LjL> LaserJock: that's nice to know, thanks
[09:54] <bhale> STU refers to $distr-updates, critical bug fixes
[09:54] <bhale> https://wiki.ubuntu.com/StableReleaseUpdates
[09:54] <LaserJock> Stable Release Updates are for very important bug fixes to existing versions
[09:54] <bhale> ugh
[09:54] <bhale> Bugs which may, under realistic circumstances, directly cause a security vulnerability
[09:54] <bhale> Bugs which represent severe regressions from the previous release of Ubuntu
[09:54] <bhale> Bugs which may, under realistic circumstances, directly cause a loss of user data
[09:54] <bhale> these are the only conditions for SRU
[09:54] <LaserJock> Backports on the other hand are focused on getting the latest version of a package
[09:55] <LaserJock> so you will almost never see the actual version of the software in -updates change
[09:55] <LaserJock> it's usually just a patch to fix a bug or regression
[09:55] <LaserJock> somerville32: good enough?
[09:56] <bhale> < apokryphos> QUESTION: with regard to Canonical making a build service, have they not considered using the already active/popular SUSE build service?
[09:56] <LaserJock> ok, guys I'm almost out of time here
[09:56] <bhale> no, the Canonical service was in works before the SusE service was announced
[09:56] <bhale> I will call it quits on that note
[09:56] <bhale> and answer anything else in -chat