[00:00] <Kellsch> Does anyone know of a good book to learn how to use Ubuntu or other Linux?  I've found about a million but I was wondering if anyone had a specific book that they found excellent.
[00:12] <pdragon> http://www.amazon.com/Ubuntu-Unleashed-Andrew-Hudson/dp/0672329093
[00:12] <pdragon> i've found that one useful
[00:15] <pdragon> http://www.amazon.com/Ubuntu-Unleashed-2008-Covering-8-04/dp/067232993X/ref=sr_1_1/180-9872617-7588121?ie=UTF8&s=books&qid=1232324122&sr=1-1
[00:15] <pdragon> sorry, there's the updated one
=== emma_ is now known as emma
[00:31] <Kellsch> thanks
[00:31] <Kellsch> I'll check it out
[00:56] <DasEi> oha, life in #ubuntu-classroom
[04:11] <davidcs> hello
=== dholbach changed the topic of #ubuntu-classroom to: Ubuntu Classroom || https://wiki.ubuntu.com/Classroom || https://lists.ubuntu.com/mailman/listinfo/ubuntu-classroom || Upcoming Event: Ubuntu Developer Week Jan 19-23: https://wiki.ubuntu.com/UbuntuDeveloperWeek || Ask questions in #ubuntu-classroom-chat
[08:30] <creek23> hello, has the Ubuntu Developer's week starter already? -- Im from Philippines. and it's 5PM ofJan 19 here.
[08:43] <dholbach> creek23: run   "date -u"   to find out what UTC time it is
=== dholbach changed the topic of #ubuntu-classroom to: Ubuntu Classroom || https://wiki.ubuntu.com/Classroom || https://lists.ubuntu.com/mailman/listinfo/ubuntu-classroom || Upcoming Event: Ubuntu Developer Week Jan 19-23: https://wiki.ubuntu.com/UbuntuDeveloperWeek || Ask questions in #ubuntu-classroom-chat || Run 'date -u' in a terminal to find out what UTC time it is
[09:03] <creek23> dholbach: what's basically gonna happen during "Getting Started" -- I'm basically waiting for Packaging which I think is hosted by you.
[09:03] <dholbach> creek23: I just blogged about it - let me get you the link
[09:04] <dholbach> creek23: http://daniel.holba.ch/blog/?p=337
[09:04] <dholbach> there you go
[09:04] <creek23> wow. thank you.
[09:04] <creek23> very much
[09:04] <dholbach> anytime
[09:04] <dholbach> it's going to be bloody brilliant
[09:06] <creek23> i sure hope so. :D
[09:06] <directhex> someone seems excited
[09:10]  * creek23 is joining the dev week the first time :D
=== matek is now known as matekm
=== mib_m3qag6hl is now known as shankhs
=== amit_ is now known as cornucopic
[12:08] <raouf> hey Everyone
=== soulnet is now known as derosa
[15:01] <Kmos> hi dholbach
[15:06] <dholbach> hi Kmos
[15:08] <Kmos> dholbach: how are you? nice to see new events here
[15:08] <dholbach> very good - thanks :)
[15:08] <dholbach> still need to prepare a few things though :)
[15:11] <Arc> yea opening session in 50 mins
[15:20] <Kmos> dholbach: everything will be ok =)
[15:30] <creek23> 30 min more....
[15:37] <meekatron>  /IGNORE -regexp -pattern "is (away|gone|back)" * ACTIONS
[15:43] <shankhs> hi
[15:52] <shankhs> i am excited
[15:56] <rooivalk> four minutes
[15:57] <Flimm> ...
[15:57] <creek23> 3.
[15:57] <rooivalk> three minutes
[15:57] <housetier> will there be logs? I'll have to move from work to home soon and would miss out
[15:57] <dholbach> housetier: yes ,they're liked from the wiki page already
[15:58] <dholbach> housetier: they'll be put up after the sessions
[15:58] <housetier> excellent!
[15:58] <creek23> good to hear
[15:58] <creek23> 2.
[15:58] <rooivalk> 2 minutes
[15:59] <creek23> 1.
[15:59] <rooivalk> 30 seconds
[15:59] <creek23> 10
[15:59] <creek23> 9
[15:59] <creek23> 8
[15:59] <creek23> 7
[15:59] <rooivalk> 5
[15:59] <rooivalk> 4
[15:59] <creek23> 6
[15:59] <rooivalk> 3
[15:59] <creek23> 5
[15:59] <rooivalk> 2
[15:59] <rooivalk> 1
[15:59] <Jarlen> spam!spam!
[16:00] <creek23> woohoo!
[16:00] <dholbach> HELLO MY FRIENDS!
[16:00] <rooivalk> gooooooo
[16:00] <holloway> Hellooouh!
[16:00] <MrKanister> ^^__^^
[16:00] <Don_S> Hullo!
[16:00] <creek23> mabuhay!
[16:00] <kusa> heloooooo
[16:00] <dholbach> Who's here for Ubuntu Developer Week and who's excited as I am?
[16:00] <kusa> hellooo*
[16:00] <nxvl> o/
[16:00] <holloway> \o/
[16:00] <istaz> hello
[16:00] <creek23> i am!!!
[16:00] <sam[cOe]> hi
[16:00]  * Don_S looks around.
[16:00] <arch> o/
[16:00] <arch> ghgh
[16:00] <afflux> *waves
[16:00] <Tm_T> dholbach: no, more than you
[16:00] <dholbach> It's hardly possible, but who's MORE excited than I am?
[16:00] <Flimm> Everybody join #ubuntu-classroom-chat !
[16:00] <pedro_> yay!
[16:00] <creek23> i am!
[16:00] <rooivalk> i am toooo
[16:01] <dholbach> Welcome to another KICK ASS Ubuntu Developer Week!
[16:01] <dholbach> Just a quick introduction before we kick off this fantastic week:
[16:01] <dholbach> The schedule is up here: https://wiki.ubuntu.com/UbuntuDeveloperWeek and logs will be made available after the sessions, the links are already there.
[16:02] <dholbach> Most sessions will be here, in #ubuntu-classroom
[16:02] <dholbach> and questions should be asked in #ubuntu-classroom-chat
[16:02] <dholbach> please prefix them with QUESTION: so people see them easier
[16:02] <dholbach> ie:   QUESTION: When is Jaunty coming out?
[16:02] <dholbach> This first session is going to be special
[16:03] <dholbach> It's "Getting Started" and we're going to have it in multiple languages simultaneously!
[16:03] <dholbach> (big applause here!)
[16:03]  * creek23 claps!
[16:03]  * holloway claps
[16:03]  * Aderyn claps
[16:03]  * Israphel claps
[16:03]  * istaz claps
[16:03] <dholbach> james_w will be leading Getting Started in English
[16:03]  * ripps claps
[16:03] <arch> claps!
[16:03]  * EnCuKou claps!
[16:03]  * kusa claps!
[16:03] <dholbach> Mirv and Tm_T will be leading the Finnish session in #ubuntu-fi-devel
[16:03] <ikis> claps
[16:04]  * Flimm claps
[16:04] <dholbach> huats and gpocentek will be leading the French session in #ubuntu-fr-classroom
[16:04]  * Tm_T bows
[16:04] <shankhs> QUESTION: I know C/C++ how can I start developing in ubuntu?
[16:04] <dholbach> gaspa and quadrispro will be leading the Italian session in #ubuntu-classroom-it
[16:04] <gpocentek> (+Lutin on the french chan ;) )
[16:05] <james_w> and didrocks?
[16:05] <dholbach> gpocentek: excellent, merci beaucoup
[16:05] <dholbach> james_w: he's ill :-/
[16:05] <james_w> lot's of french :-)
[16:05] <huats> james_w: is ill...
[16:05] <james_w> aww, get well soon didrocks
[16:05] <dholbach> nxvl and pochu will be leading the Spanish session in #ubuntu-classroom-es
[16:05] <dholbach> and I'll be doing the German session in #ubuntu-classroom-de
[16:05] <dholbach> thanks a lot dear presenters, you ROCK
[16:05] <james_w> this is going to be so cool
[16:06] <nxvl> thank you for having the idea!
[16:06] <dholbach> I hope you're going to have a fantastic time, I'm VERY excited!
[16:06]  * dholbach hugs y'all
[16:06]  * james_w hugs dholbach 
[16:06]  * holloway hugs dholbach back
[16:06] <Aderyn> group hug!
[16:06] <dholbach> james_w: the floor is yours :)
[16:06]  * nxvl HUGS dholbach back
[16:06] <dholbach> yoohooo! :)
[16:06] <james_w> thanks dholbach
[16:06]  * Tm_T runs away from dholbach 
[16:06] <Koon> yaaaay
[16:06] <james_w> good luck to my fellow presenters :-)
[16:07] <Mirv> thanks :)
[16:07] <kusa> thanks :)
[16:07] <james_w> right, who's going to be following the English session?
[16:08] <Aderyn> i will. :)
[16:08]  * Don_S raises his hand.
[16:08]  * Jarlen raises his hand
[16:08]  * legate raises his hand
[16:08]  * toobuntu_ raises his hand
[16:08] <pdragon> i'm lurking
[16:08]  * Arc raises
[16:08]  * Israphel idem
[16:08] <shankhs> I thought there will be over 1000 participants
[16:08] <theseas> me too!
[16:08] <EnCuKou> I'm lurking as well.
[16:08] <arrowes> me too
[16:08] <james_w> cool, glad to hear it
[16:09] <ikis> me
[16:09]  * Flimm raises his hand
[16:09] <james_w> in this session I'm going to be talking about Ubuntu Development in general terms, showing you round some areas of it, and giving you pointers to get more information
[16:09] <Israphel> I gonna follow the session while I watch disney channel
[16:09] <Kmos> james_w: let's start it :)
[16:10]  * creek23 raises hands.
[16:10] <shankhs> ya
[16:10] <james_w> then in the next session the unstoppable dholbach is going to talk about how to get started doing packaging, which is one of the main activities in Ubuntu developement
[16:10] <james_w> so if you want to know the mechanics of packaging stick around for that session
[16:11] <james_w> so, we'll get started with a look at the structure of Ubuntu development
[16:11] <james_w> the wiki is the place to look for this
[16:11] <james_w> https://wiki.ubuntu.com/UbuntuDevelopment
[16:11] <james_w> that's the overview page
[16:11] <james_w> that is full of links for places to get more information
[16:12] <creek23> my first time here: are all the events gonna happen here in the IRC? how about visualizations?
[16:12] <james_w> so, an Ubuntu developer is anyone that works on making Ubuntu  rock technically
[16:12] <james_w> creek23: in #ubuntu-classroom-chat please
[16:13] <james_w> as I said the main activity is based around packaging, and as such we deem "Ubuntu Developers" to be those that have "upload rights" to the archive, but there are many many more people that contribute to Ubuntu in really important ways without having upload rights
[16:14] <james_w> for those that have upload rights, there are two groups "Core-dev" and "MOTU"
[16:14] <james_w> the distinction is on how many packages they get to upload, with core-dev being allowed to upload anything, and MOTU only allowed to upload packages in universe
[16:14] <james_w> (and multiverse)
[16:15] <james_w> MOTU is the team to get involved with if you want to become an ace packager
[16:15] <james_w> it's a really friendly, helpful community, and there is loads to do
[16:16] <james_w> <Aderyn> QUESTION: MOTU is short for what?
[16:16] <james_w> MOTU stands for "Masters of the Universe"
[16:16] <james_w> it's a pun on the fact that we maintain the  universe component
[16:16] <james_w> <shankhs> QUESTION: how to get upload rights
[16:16] <james_w> good question
[16:17] <james_w> to become a MOTU you spend some time contributing through the "sponsorship process"
[16:17] <james_w> <shankhs> QUESTION: how to get upload rights
[16:18] <james_w> https://wiki.ubuntu.com/SponsorshipProcess
[16:18] <james_w> that's what I meant :-)
[16:18] <james_w> this is where you prepare an update to a package in the archives and request that it be uploaded
[16:18] <james_w> someone with upload rights will then review your change and work with you to make it work
[16:19] <james_w> once they are happy with it they will upload it for you, but it will be under your name, they just sign it for you so that they archive software will accept it
[16:20] <james_w> after some time, when you have contributed significantly through this process you apply for upload rights
[16:20] <james_w> and the people that sponsored you will advocate your application, saying that they think you are ready to upload by yourself
[16:21] <james_w> the MOTU Council then vote on your application and if they vote in favour of you you are given upload rights
[16:21] <james_w> the aim is that it's fairly easy to get your work sponsored, so that you can contribute while not having upload rights, and then once you are trusted we can remove the review step and let you upload without that wait
[16:22] <james_w> and of course sponsor the next batch of developers
[16:22] <james_w> <shankhs> QUESTION: I read that to become MOTU you need a mentor how to get one?
[16:22] <james_w> you can have a mentor if you like, but it is not requires
[16:22] <james_w> see https://wiki.ubuntu.com/MOTU/Mentoring for more information on mentoring
[16:23] <widox> alid login request > java.lang.NullPointerException
[16:23] <widox> 11:20:08.104 - [ WARNING ] > SysHandler -> Bad room id. Action: roundTrip >> java.lang.NumberFormatException: For input string: "null"
[16:23] <james_w> the time from application to getting a mentor is just a couple of days at the moment I believe
[16:23] <GSMX> date -u
[16:24] <james_w> but it's preferred if you can get started reading the documentation and tackling bugs on your own, and apply for a mentor for advice and guidance
[16:24] <james_w> mentors are busy with their own development work, so they won't be able to teach you everything
[16:24] <james_w> <ikis> QUESTION:What technical skills should have an Ubuntu developer? Is there any material?
[16:25] <james_w> there aren't specific technical skills required
[16:25] <james_w> knowing a bit of programming (in any language) helps
[16:25] <james_w> if you are good at the command line, and know a bit of scripting or something that is usually good enough
[16:26] <james_w> the main thing you need is skill at problem solving. Much of what we do boils down to that.
[16:26] <james_w> there are obviously some things that you need specific skills before, but you can either skip those tasks, or learn the skills as needed
=== soulnet is now known as derosa
[16:27] <james_w> <maxb> QUESTION: How does the Ubuntu Universe Contributors status fit in to this system? What is different between a member of this team and anyone else following the SponsorshipProcess?
[16:27] <james_w> thanks, I forgot to mention this
[16:28] <jepes> hello
[16:28] <cineris> Hey!
[16:28] <james_w> the "Ubuntu Universe Contributors" status is the same as Ubuntu member status
[16:28] <jepes> hi
[16:28] <mib_zvl2d8tt> hi
[16:28] <james_w> jepes: #ubuntu-classroom-chat please
[16:28] <elipticalosma> ola
[16:29] <james_w> the MOTU council is able to grant Ubuntu membership based on contribution to Ubuntu development
[16:29] <james_w> it doesn't gain you anything special from a developer perspective
[16:29] <james_w> it's just a recognition of your contribution to development and ubuntu member status
[16:30] <james_w> (and so @ubuntu.com email, IRC cloak, planet ubuntu etc)
[16:30] <elipticalosma> hiper cool
=== Kelemen3 is now known as Kelemen
[16:31] <james_w> now, I want to talk a bit about the development cycle and related things
[16:31] <creek23> elipticalosma: #ubuntu-classroom-chat please
[16:31] <samp> ola hay alguien español
[16:32] <cineris> hoyga?
[16:32] <james_w> as Xazax stated most packages in Ubuntu come from Debian
[16:32] <Nosgosh> te comprendo
[16:33] <james_w> so we start the cycle by pulling in all the latest stuff from Debian
[16:33] <james_w> this goes on for a couple of months
[16:33] <james_w> most stuff is pulled in automatically
[16:33] <james_w> but if we have modified a package in Ubuntu then we must "merge" the changes
[16:33] <james_w> this activity is unsurprisingly known as "merging"
[16:34] <james_w> this is an important activity, as it is one of the main ways we make sure we are up-to-date, and is where a lot of interesting new things for Ubuntu come from.
[16:34] <Kmos> Nosgosh: try #ubuntu-es-classroom
[16:34] <james_w> we owe a lot to Debian, and to the "upstreams" that they take from
[16:35] <jepes> hola javier
[16:37] <cineris> thanks Kmos
[16:38] <james_w> after that process has gone of for a couple of months (at "Debian Import Freeze", or "DIF")
[16:38] <james_w> we stop the automatic import, and start to focus on the next release
[16:38] <james_w> there is still a couple of months where we work on new things
[16:39] <james_w> we either start to jump ahead of Debian a little bit by pulling directly from "upstream"
[16:39] <james_w> or we add new things ourselves
[16:39] <james_w> that goes on until "feature freeze"
[16:39] <james_w> at that point we start to focus on making the next release solid
[16:40] <james_w> this starts a couple of months before release
[16:40] <james_w> and things start to freeze more and more over time
[16:40] <james_w> meaning we make smaller and smaller changes to try not to break anything
[16:40] <james_w> then we release and have a big party
[16:41] <james_w> <ikis> QUESTION: Do you use the unstable Debian always?
[16:41] <james_w> not always
[16:41] <james_w> that's the default, but it's possible to take from elsewhere if needed
[16:41] <james_w> e.g. experimental
[16:42] <james_w> as Debian is currently frozen we have been doing that a bit more than usual this cycle
[16:42] <james_w> <Ape3000> QUESTION: Can you increase the rate of backporting so we would always have the newest software? If it's stable on upstream, why shouldn't it be stable on Ubuntu?
[16:42] <james_w> it's not that simple
[16:43] <james_w> how stable a release is from upstream varies
[16:43] <james_w> and more than that, it depends a lot on the rest of the packages
[16:43] <james_w> so backporting something that works fine may cause it to break
[16:44] <james_w> also, stability is important within a release. Having your system possibly break every day isn't very good to work on.
[16:44] <james_w> selective backports can help for somethings
[16:45] <james_w> and spending more time on backporting means we spend less on the next release, whereas we think it's important to make ubuntu+1 great, and we can do that without having to worry too much about stability for our users
[16:45] <james_w> *and* you're never more than 6 months from the latest release
[16:46] <james_w> <ongolaBoy> QUESTION:why do you release twice a year ?is it reliable ?
[16:46] <james_w> it was decided that this gave the best balance between releasing quickly to get new stuff out there
[16:46] <james_w> and releasing slowly to make sure things were well tested and stable
[16:47] <james_w> it also stems from GNOME's 6-monthly release cycle
[16:47] <james_w> following them is very useful for us
[16:47] <james_w> read Mark's writing on release scheduling if you want to know more
[16:48] <james_w> <Ape3000> QUESTION: What about online games that must be always the newest stable version in upstream? Shouldn't you prefer using the supported version instead of being 100% stable?
[16:48] <james_w> there are obviously special cases, and we try and handle them appropriately
[16:48] <james_w> <slavsun> QUESTION: when the Plymoth technology (loading different services at the same time) will be deployed in Ubuntu ?
[16:49] <james_w> I think you've got a few things mixed up there, Plymouth isn't to do with services
[16:49] <james_w> I'll talk a little bit about the new feature process though
[16:50] <james_w> this process is ongoing, but it comes together towards the end of the release schedule
[16:50] <james_w> we start to survey what changes are arriving upstream, look at brainstorm, talk to each other, etc.
[16:51] <james_w> from that each developer will decide what is both important, and achieveable for the next cycle
[16:51] <james_w> from that they will come up with a number of specifications
[16:51] <james_w> these are then discussed at UDS, or elsewhere
[16:51] <james_w> and then drafted, and approved
[16:52] <james_w> and the developer will then work on them to be included in the next Ubuntu release
[16:52] <james_w> plus, there are lots of things that are just implemented along the way without a specification etc.
[16:52] <james_w> usually smaller things
[16:52] <james_w> plus we get lots of new shiny by default every release from upstreams
[16:53] <james_w> <shankhs> QUESTION:In brainstorm u get lots of conflicting ideas how u manage that?
[16:53] <james_w> well, we don't have to implement them all, so we're ok
[16:53] <james_w> but part of the point of brainstorm is to gauge how the user base feel about conflicting ideas
[16:54] <james_w> if both are voted really high then we have to find another way
[16:54] <james_w> <Ape3000> QUESTION: Do you listen to Brainstorm? If an idea gets lots of votes, do you implement that?
[16:54] <james_w> it's not as simple as that
[16:54] <james_w> we keep an eye on it, but we don't take the top 50 ideas from brainstorm to work on
[16:55] <james_w> firstly, as I said the idea has to be acheivable, when many aren't, at least in the short term
[16:55] <james_w> secondly, user votes isn't the only thing that should drive an OS
[16:56] <paradx> hi
[16:56] <james_w> right, there have been loads of questions about REVU, so I'll talk about that
[16:56] <james_w> you can find REVU at http://revu.ubuntuwire.com/
[16:56] <james_w> and read about it at https://wiki.ubuntu.com/MOTU/Packages/REVU
[16:57] <james_w> REVU is a way for people to propose packages to be included in Ubuntu
[16:57] <james_w> if you find something really useful that isn't included in Ubuntu you can package it
[16:57] <james_w> and then put it on Ubuntu to get reviewed
[16:57] <james_w> MOTU can then come and review your package, and you can fix any problems and re-upload
[16:58] <james_w> if your package gets two advocates (MOTUs that say that it looks good) then it will be uploaded to Ubuntu
[16:58] <james_w> however, reviewing new packages is a time consuming activity
[16:59] <james_w> and there aren't that many MOTUs
[16:59] <james_w> and not all of them spend time reviewing packages on REVU
[16:59] <james_w> this means that there is a lack of reviewers, and so many packages on REVU go un-reviewed for a long period of time
[17:00] <james_w> if you want your package uploaded then you can put it on REVU and ask for reviewers in #ubuntu-motu every so often
[17:00] <james_w> and some patience will see your package uploaded. Then you can watch the bug reports and package new upstream versions etc.
[17:01] <james_w> if you are looking to become an Ubuntu developer then you should probably look for other ways to contribute
[17:02] <james_w> as the above reasons mean that it would take a very long time to developer status through REVU
[17:02] <james_w> and there is more to development than new packages
[17:02] <james_w> I would instead work on updating packages in the repositories to new versions
[17:02] <james_w> and fixing bugs in them
[17:03] <james_w> directhex> you could mention the option of targeting debian rather than revu, james_w
[17:03] <james_w> indeed, thanks directhex
[17:03] <james_w> if you have a new package then getting it in to Debian means that it will end up in Ubuntu anyway soon enough
[17:04] <james_w> and you get more potential users of your package
[17:04] <jsmidt> What's the best way to find out what needs done today? Harvest?
[17:04] <james_w> for finding other tasks to work on then you can use Mr. Holbach's "Harvest" http://daniel.holba.ch/harvest/
[17:06] <james_w> this aggregates lists we have of "low-hanging" fruit
[17:06] <james_w> so they are good leads to pick up
[17:06] <james_w> the absolute *best* thing to do is work on something you care about though
[17:07] <james_w> if you use and love the epiphany web browser then take a look at the list of bugs on that and find something you think you could tackle
[17:08] <james_w> if you try to install a cool new game and it fails to start as it is missing a dependency on some package then prepare a fix to the package so that you can install it
[17:09] <james_w> if you really miss the ability to click on URLs and have them open in your web browser from some terminal emulator that you use then work out how to make that happen and submit a patch
[17:09] <james_w> don't be afraid to start small either
[17:09] <james_w> picking up a bug about a spelling mistake somewhere to work on isn't a bad thing, even though it's not coding C++, every time you work on something you will learn loads
[17:10] <james_w> and before too long you will be able to tackle larger things
[17:11] <james_w> (typing break, my fingers hurt :-) )
[17:12] <Paddy_EIRE> james_w, :)
[17:12] <james_w> right, let's look at other ways to contribute
[17:13] <james_w> so, I've mainly been talking about packaging, as that is the core of what we do
[17:13] <james_w> but there are very few people that just do "packaging"
[17:13] <james_w> it naturally leads you to work on other things
[17:13] <james_w> so we do a lot of bug-fixing
[17:14] <james_w> we also develop some new features
[17:14] <james_w> but that is a large time investment, so the scales we work at leave us little time to do that
[17:15] <james_w> there are two main types of new features that you can contribute though
[17:15] <james_w> the first is of the class "make my favourite application do such-and-such"
[17:15] <james_w> these generally only touch a single package
[17:15] <james_w> and we tend to think of these as "upstream" features
[17:16] <james_w> for these you are often best off contacting the upstream project, as they will know the code much better and will be able to hep you
[17:16] <james_w> the other type are the "glue" features
=== maix_ is now known as maix
[17:17] <james_w> this is where we make something work well either across, or between packages
[17:17] <james_w> this is one area that Ubuntu shines
[17:17] <james_w> this involves either writing new code, or integrating it from upstream
[17:18] <james_w> so you can make something "just work"
[17:18] <james_w> this is where most attention is focused, as these are the things that usually can't be done upstream
[17:18] <james_w> either because they are distribution-specific in some way (for instance installer integration)
[17:19] <james_w> or because they don't live in one package, but between them
[17:20] <james_w> if you have an idea in this area and want to work on it then it's a good idea to track down the right people to talk to
[17:20] <james_w> sometimes this is one particular person, sometimes a team, or sometimes it's a little bit of several people
[17:21] <james_w> if it's to do with a particular package then you can find out who might be a good person to talk to by reading the changelog
[17:21] <james_w> otherwise posting to the mailing list about it is probably the way to go
[17:22] <james_w> <xnox> QUESTION: do translators and bug-squashers get same amount of recognition as the packagers? Eg. in terms of getting Member, MOTU and Coredev statuses?
[17:22] <james_w> the can equally get membership
[17:22] <james_w> they can't get MOTU and core-dev for those activities though
[17:23] <james_w> as they don't normally need to upload packages to do that
[17:23] <james_w> someone would be perfectly welcome to be a translator *and* a MOTU though
[17:23] <james_w> and many people are
[17:24] <james_w> <creek23> QUESTION: Does core-dev or MOTU get paid?
[17:24] <james_w> not necessarily
[17:24] <james_w> some are paid for their work, many by canonical
[17:24] <james_w> but that is neither a requirement nor a guarantee
[17:25] <james_w> there are many volunteer developers who do fantastic work
[17:25] <james_w> <Xazax> QUESTION: there are lot of updated or new packages on getdeb.net. Whats with that? When will they be implemented?
[17:25] <james_w> we don't pull from getdeb.net without manuall inspection
[17:25] <james_w> if there was an updated package there then we could review it and pull it
[17:26] <james_w> or the person that put it on getdeb could seek sponsorship to get it in to Ubuntu
[17:26] <james_w> but we have other ways of finding out about new upstream versions
[17:28] <james_w> rugby471> QUESTION: As a confident user, I reported a bug in launchpad, however it still has not be implemented after a long time, I figured the thing to do is package it myself, however I don't know how to get the source of the deb etc. How do you intend to make bug solving easier for users like myself?
[17:29] <james_w> that's the best way of doing it, then you don't have to wait for someone else:
[17:29] <james_w> :-)
[17:29] <james_w> I personally care a lot about making bug solving as easy as possible in Ubuntu
[17:30] <james_w> well, at least easy to integrate the fix if you can work out what it is
[17:30] <james_w> we can't really make it easier to actually solve problems ;-)
[17:30] <james_w> I'm working on a few projects that I hope will help with this
[17:30] <james_w> and we have had lots of discussion within the developer community about making it easy
[17:31] <james_w> I would say that if you have a fix, and you subscribe the sponsors as outlined in the sponsorship process I discussed earlier you should find it fairly easy to get your fix in
[17:31] <james_w> (assuming that it's not doing something bad)
[17:31] <james_w> <maxb> QUESTION: How does a contributor know when they are ready to apply for MOTU?
[17:32] <james_w> maxb: it's a discussion that has also been going on in recent weeks
[17:32] <james_w> the oft-given answer to this is either "when people tell you you are"
[17:32] <james_w> or "when people are surprised that you aren't already"
[17:32]  * xnox lol
[17:33] <james_w> if you have a couple of regular sponsors then ask them, they will happily tell you if they think you are ready
[17:33] <james_w> and if not they will be able to give you suggestions about where you can improve
[17:34] <james_w> if you don't have regular sponsors then you either haven't really been involved long enough, or you've just been *really* unlucky and never had something sponsored by the same person twice
[17:34] <james_w> (regular here would be 5 or so)
[17:34] <james_w> if you think you are doing well, but you really don't know who to ask then you can find someone from the MOTU council and speak to them about it
[17:35] <james_w> or indeed any MOTU would be glad to help I'm sure
[17:35] <james_w> xnox> QUESTION/SUGGESTION: what about QA? from release perspective (+1) and from the on-going perspective (current, stable and LTS)
[17:35] <james_w> we have the QA team, who try and test things, and keep an eye on the bugs to try and spot things that need to be fixed
[17:35] <james_w> and of course, being free software, the users are testers too
[17:36] <james_w> so we really on bugs being reported, and being escalated in the correct manner
[17:36] <james_w> I think there are some QA sessions this week you could attend to find out more
[17:36] <james_w> and there are weekly QA meetings if you have suggestions
[17:36] <james_w> creek23> QUESTION: Does a software needs a large amount of user before ever being added to Ubuntu upstream?
[17:37] <directhex> <james_w> so we really on bugs being reported, and being escalated in the correct manner <-- and with sufficient detail that they can be repeated & isolated by the person fixing the bug - "it doesn't work" helps nobody
[17:37] <james_w> "upstream" means the places we pull software from, not part of Ubuntu
[17:37] <james_w> directhex: indeed
[17:37] <james_w> but no, we don't require a large amount of users before being added to Ubuntu
[17:37] <james_w> though a package with close to zero *potential* users may have a hard time getting added
[17:38] <james_w> <creek23> QUESTION: after a "needs packaging" is confirmed, when does it usually implemented?
[17:38] <james_w> when somebody does it
[17:38] <james_w> that's the best you can say
[17:38] <james_w> xnox> QUESTION: can maintainers of Debian packages apply for Ubuntu Members status and get it like automagicly?
[17:38] <james_w> not sure
[17:39] <james_w> they will probably be able to get developer status quite quickly, as they presumably have good technical knowledge
[17:39] <james_w> but as for member status, I'm not sure
[17:39] <james_w> that would be up to the councils in the end
[17:41] <james_w> launchpad is the place where a lot of Ubuntu development is tracked
[17:41] <james_w> https://launchpad.net/ubuntu
[17:41] <james_w> you will need an account there for a lot of development activities
[17:42] <james_w> and you can find bug reports, translations, answers, specifications, build logs, NEW queue, and loads more on there
[17:45] <james_w> <ronj> QUESTION: I had never heard of REVU before this session. One question after a quick look at the tool: don't you think this could be simplified and integrated to Launchpad? Seems redundant with some LP features. Or am I missing the point of the tool?
[17:45] <james_w> it could perhaps be integrated in to launchpad, but it isn't, so we have REVU
[17:45] <james_w> the launchpad developers would know if there were plans for it, or even if they wanted something like that
[17:46] <james_w> <jsmidt> QUESTION: Should we update packages updated upstream but not in Debian?  If so, when is the freeze timeline for this?
[17:46] <james_w> jsmidt: yep, there's no problem with that
[17:46] <james_w> jsmidt: right at the beginning of the cycle it may be easier/better to get it in to Debian, and then sync
[17:47] <james_w> in the middle it may be better to get it in to Ubuntu directly, unless you know that it will be updated in Debian soon
[17:47] <james_w> at the end you will have to get a freeze exception, and it doesn't really matter where the package is coming from then
[17:50] <james_w> xnox> QUESTION: Debian is frozen right now. What does it mean for them and for us?
[17:50] <james_w> this means that Debian is in the process of releasing
[17:50] <james_w> the freeze lasts for a long time in this period
[17:50] <james_w> and during that time there are less uploads to Debian "unstable"
[17:50] <james_w> some upload to "experimental", but some just wait
[17:51] <james_w> that means to get things through Debian is a bit of a pain from Ubuntu's point of view, as they are concentrating on release
[17:51] <james_w> I'm happy for them to do that, but it causes us a bit of disruption compared to the normal routine
[17:55] <james_w> xenonex> How can I help in adding the latest version of the package in a repository? (for example, dhcpcd need to upgrade to version 4)
[17:55] <james_w> firstly file a bug with the necessary information
[17:55] <james_w> and tag it "upgrade"
[17:55] <james_w> then check the Debian bug tracking system for the package and see if it has been requested there
[17:56] <james_w> and if it has then link the bug in launchpad
[17:56] <k-milogars> hello
[17:56] <james_w> if not then you can file it in Debian (after checking it is not in Debian already)
[17:56] <james_w> if it is in Debian then we need to do the merge
[17:56] <james_w> once that is done you can tackle the upgrade yourself
[17:56] <james_w> check "uupgrade" from devscripts that will automate some steps
[17:58]  * james_w calls time
[17:58] <james_w> thanks for your participation everyone
[17:58]  * directhex blows a whistle
[17:58] <directhex> round of applause for james_w
[17:58] <james_w> I hope it was useful
[17:58] <xnox> james_w: thank you for the session!!!!!
[17:59]  * xnox claps
[17:59]  * Arc applauds
[17:59] <huats> james_w: congrats ;)
[17:59]  * creek23 claps!
[17:59] <james_w> I wonder how far I diverged from the sessions in other languages :-)
[17:59] <jsmidt> \me claps
[17:59] <Paddy_EIRE> james_w, Thank you very much for your time
[17:59] <rugby471> THANK YOU!!!!! (oops not meant to post in this channel :-] )
[17:59] <CrownAmbassador> Will this be published somewhere like other meetings? I couldn't log it before it started.
[17:59] <Jarlen> thanks james_w, it was very enlightening :)
[17:59] <james_w> CrownAmbassador: check the wiki
[17:59] <EnCuKou> james_w: Thanks for the talk!
[17:59] <theseas> thanx james_w
[17:59] <jsmidt> thanks james_w
[18:00] <CrownAmbassador> james_w: will do , thanks
[18:00] <james_w> the scribes team does a great job making the logs available
[18:00] <creek23> the whole uptream pulling to package review was quite a talk.
[18:00] <maix> CrownAmbassador: https://wiki.ubuntu.com/MeetingLogs/devweek0901/GettingStarted
[18:00] <CrownAmbassador> maix: Wow! That was quick! hehe. Thanks.
[18:00] <maix> ah sry, +EN
[18:00] <dholbach> HELLO EVERYBODY!
[18:00] <maix> browser history :D
[18:00] <dholbach> ARE YOU HAVING A GOOD TIME? :)
[18:00] <Israphel> YEAH
[18:00] <Arc> yes!
[18:01] <xnox> YEAH!!!!
[18:01] <ikis> claps!
[18:01] <cody-somerville> WEE!
[18:01] <dholbach> I can not hear you! Who's here for "Packaging 101"? :-)
[18:01] <CrownAmbassador> dholback: Our German friend yeah?
[18:01] <cody-somerville> ME!!
[18:01] <maix> <-
[18:01] <xnox> ME!!!!!
[18:01]  * apw giggles
[18:01] <Israphel> ←
[18:01] <Cobalt> dholbach: i'd sure like to know more.
[18:01] <Arc> <-
[18:01] <theseas> yesss!!! :)
[18:01]  * Andphe is here for packaging 101
[18:01] <cool2k> ME!!!!
[18:01] <james_w> ME! I've been interested in this packaging thing, I'd quite like to learn how to do it
[18:01]  * ia put hand
[18:02] <alexrudd> might be easier to ask who isn't
[18:02] <xnox> james_w: lol
[18:02]  * hggdh needs to learn pack aging
[18:02] <dholbach> I hope you guys are excited as I am and I hope to see you in #ubuntu-motu soon making Ubuntu rock even harder! :-)
[18:02] <EnCuKou> I'm right here, sucking up the knowledge
[18:02] <Ape3000> I like this few hours
[18:02] <Ape3000> *liked
[18:02] <creek23> i am!!!
[18:02] <dholbach> Ok my friends, let's keep questions in #ubuntu-classroom-chat and please: ask :-)
[18:03] <dholbach> So this is "Packaging 101" - I'm going to explain the bare-bone structure of a very simple package
[18:03] <dholbach> a lot of the stuff I'm going to talk about is also in the Packaging Guide which is linked from https://wiki.ubuntu.com/MOTU/GettingStarted
[18:04] <dholbach> so go and bookmark that page, it has all the important information, including some videos about packaging
[18:04] <dholbach> first please all take a look at /etc/apt/sources.list
[18:04] <dholbach> and see if you have something in there resembling
[18:04] <dholbach> deb-src http://archive.ubuntu.com/ubuntu/ intrepid restricted main multiverse universe
[18:05] <dholbach> this will give apt information about source packages which is what we're going to need
[18:05] <dholbach> if you don't have it, please add it (and replace 'intrepid' with whatever ubuntu release you're running)
[18:05] <dholbach> and run
[18:05] <dholbach>    sudo apt-get update
[18:05] <dholbach> afterwards
[18:05] <dholbach> <bullgard4> QUESTION: Questions may be put at any time or only later?
[18:06] <dholbach> bullgard4: any place in /etc/apt/sources.list should fine
=== Kelemen3 is now known as Kelemen
[18:06] <dholbach> <dlynch> QUESTION: do I need to learn about man pages and icons and where things go on the file system before I can even think about making a package?
[18:06] <dholbach> dlynch: we're not going to cover it in this session, but as all things in Ubuntu Development it's fine to learn them step by step
[18:06] <dholbach> for the package we're discussing in a few secs, it's not that important
[18:07] <dholbach> alright, now that apt knows about source packages, please run
[18:07] <dholbach>       apt-get source hello
[18:07] <dholbach> for those of you who know 'hello', yes, it's boring
[18:07] <Andphe> gksu gedit /etc/apt/sources.list
[18:07] <dholbach> but it's to the point and that's what we like
[18:07] <Andphe> sorry
[18:07] <Andphe> :p
[18:08] <dholbach> hello is a GNU project that shows how to use C, autotools, internationalisation to create an awesome tool which does nothing more than writing "Hello world!" on your screen
[18:08] <dholbach> the hello source package contains a similarly spartanic packaging :)
[18:08] <dholbach> which is a good start
[18:08] <dholbach> so what did 'apt-get source' do?
[18:09] <dholbach> on my machine it downloaded hello_2.2-2.diff.gz hello_2.2-2.dsc and hello_2.2.orig.tar.gz
[18:09] <dholbach> hello_2.2.orig.tar.gz is the unmodified tarball that was released on the GNU homepage
[18:09] <dholbach> (it was merely renamed)
[18:09] <dholbach> <apw> Check if the 'dpkg-dev' package is installed.
[18:10] <dholbach> apw: you're right... sorry - you will need dpkg-dev
[18:10] <dholbach> I thought james_w had covered that ;-)
[18:10] <james_w> yeah, sorry, didn't get round to that stuff
[18:10] <dholbach> haha
[18:10] <james_w> there's a lot of Ubuntu development to talk about
[18:10] <dholbach> you're right :)
[18:10] <dholbach> nevermind guys :)
[18:10] <dholbach> hello_2.2-2.diff.gz is the compressed patch that was introduced to make hello build the Ubuntu way
[18:10] <dholbach> what does that mean?
[18:11] <dholbach> Ubuntu and Debian have a build process that is actually a meta-build process, it's on top of the packages build infrastructure (be it autotools or a python distutils project, or just a few PHP scripts that are installed somewhere, etc.)
[18:11] <dholbach> this is a great thing, as we just have one build process that is applied to all kinds of packages
[18:12] <dholbach> this is the "packaging" :)
[18:12] <dholbach> hello_2.2-2.dsc is a text file that contains meta data such as md5sums and so on
[18:12] <dholbach> <xnox> Question: looking into hello-2.2 directory, itsn't TOO many files for a "prints hello world" programm?
[18:12] <dholbach> xnox: we'll get to the files in the directory in just a sec
[18:12] <dholbach> <co0lingFir3> QUESTION: in the terminal it says signature could not be verified because the public key was not found. how can i fix that?
[18:12] <dholbach> co0lingFir3: you can safely ignore that warning
[18:13] <dholbach> it just means that you don't have the public key of the last person who touched the package to verify it
[18:13] <co0lingFir3> k
[18:13] <dholbach> also I have a hello-2.2 directory that was generated this way: extract the .orig.tar.gz tarball, apply the compressed patch (the .diff.gz)
[18:14] <dholbach> apt-get source <package> will get you every source package that is available in the archive
[18:14] <dholbach> alright, let's crack on
=== hRedBeard1 is now known as hRedBeard-work
[18:14] <dholbach>    cd hello-2.2
[18:14] <dholbach>     ls
[18:14] <dholbach> you can see there's a debian/ directory - this comes from the .diff.gz
[18:14] <dholbach> and that's where the packaging lives
[18:15] <dholbach> if you look into the debian/ directory you can see just a few files
[18:15] <dholbach> and now we're going through all of them one by one
[18:15] <dholbach> any questions already?
[18:16] <dholbach> alright
=== admin is now known as Guest90417
[18:16] <dholbach> the first one   debian/changelog   is pretty straight-forward
[18:17] <dholbach> it contains changelog entries for every revision of the package that was done in Debian / Ubuntu
[18:17] <dholbach> especially in Ubuntu it's very important to document very carefully what you've changed
[18:17] <dholbach> we have no 'maintainer concept' in Ubuntu, we all work on all packages as a team
[18:18] <dholbach> so if you don't like your fellow developer to have to second-guess what "made shit work again" means, you better document it well :)
[18:18] <dholbach> also if you look at the package half a year later you need to know what changed and why
[18:18] <dholbach> also add information about bugs that were fixed, references to patches, discussion etc.
[18:18] <dholbach> <apw> QUESTION: how can we tell if it is a debian or ubuntu change
[18:18] <dholbach> <creek23> QUESTION: revision of the package? not the revision of the binary?
[18:18] <dholbach> <maix> QUESTION: in debian it is not?
[18:19] <dholbach> apw, creek23, maix: we'll get to that exactly now :-)
[18:19] <dholbach> <bullgard4> QUESTION: Do you, Daniel, often consult the changelog in order to find the cause of a bug?
[18:19] <dholbach> bullgard4: always
[18:19] <dholbach> on my system the first line of debian/changelog says:
[18:19] <dholbach> hello (2.2-2) unstable; urgency=low
[18:20] <dholbach> let's go through them one by one
[18:20] <dholbach> 'hello' is the name of the source package
[18:20] <dholbach> typically just the name of the upstream project
[18:20] <dholbach> (2.2-2) contains the version number of the source package
[18:20] <dholbach> it comprises of two parts
[18:20] <dholbach> "2.2" is the version number of the upstream release
[18:20] <dholbach> remember "hello_2.2.orig.tar.gz"?
[18:21] <dholbach> that was the version that was release on the GNU FTP server
[18:21] <dholbach> -2 means "this is the second revision of hello 2.2 that was uploaded to Debian"
[18:21] <dholbach> if we were to add an Ubuntu-only change to the package, it'd be   2.2-2ubuntu1
[18:21] <dholbach> so we just add a "ubuntu1" to the Debian revision
[18:22] <dholbach> <ia> QUESTION: could you tell, please, a little bit more about X.Y-ZubuntuW package version naming? what stands Z and W for and how it calculates if i made some changes and gonna make new package?
[18:22] <dholbach> Ok, let's talk about it a bit more
[18:22] <dholbach> if we were to update hello to 2.3 without inheriting the version from Debian, we would call it 2.3-0ubuntu1
[18:23] <dholbach> <Arc> QUESTION: what about when the upstream release contains a -, such as 1.0-beta2 or 3.0-rc3
[18:23] <dholbach> that's an interesting question
[18:23] <dholbach> in the case of beta2 and rc3 we would change our tactics slightly
[18:23] <dholbach> we'd use the    ~    operator
[18:23] <dholbach> ~?
[18:24] <dholbach> it tells dpkg "this is smaller"
[18:24] <dholbach> let me show you can example
[18:24] <dholbach> daniel@miyazaki:~$ dpkg --compare-versions 1.0-1 gt 1.0~beta1-1 && echo TRUE
[18:24] <dholbach> TRUE
[18:24] <dholbach> daniel@miyazaki:~$ dpkg --compare-versions 1.0-1 gt 1.0beta1-1 && echo TRUE
[18:24] <dholbach> daniel@miyazaki:~$
[18:25] <dholbach> dpkg is always authoritative
[18:25] <dholbach> dpkg will not upgrade to a version of a package that is "smaller" than the current one
[18:25] <dholbach> we introduce the "~" to artificially let dpkg know: this is smaller :)
[18:25] <dholbach> <Arc> QUESTION: what about after - for ubuntu-only packages
[18:26] <dholbach> Arc: can you clarify?
[18:26] <dholbach> <Arc> dholbach: what do you put after the - for when there is no debian package version, when you're packaging directly for ubuntu
[18:27] <dholbach> Arc: OK. let's say I package   baconator 1.0
[18:27] <dholbach> I'd call the first version that ever hits Ubuntu   baconator (1.0-0ubuntu1)
[18:27] <dholbach> to indicate: we did not inherit any version from Debian
[18:27] <dholbach> <creek23> QUESTION: if a software uses the YMD versioning scheme, should the package follow it as foobar-2009.01.16-ubuntu.deb?
[18:28] <dholbach> creek23: it'd probably be foobar_2009.01.16-0ubuntu1_i386.deb or some such
[18:28] <dholbach> <apw> QUESTION: why would not our 2.3 copy be 2.3~ubuntu1
[18:28] <dholbach> apw: in the case of 2.3 (upstream, our first revision) it's not necessary to tell dpkg "this is actually smaller"
[18:28] <dholbach> 2.3-0ubuntu1 works just fine
[18:29] <dholbach> "~" is not used very very often
[18:29] <dholbach> <ripps> QUESTION: What if we checkout a program from svn that doesn't a numerical version just a svn version (ex. svn2558)?
[18:29] <dholbach> so if this was 1.0 version of baconator plus some changes from SVN, I could make it
[18:29] <dholbach> 1.0+svn2558-0ubuntu1
[18:29] <dholbach> alright, let's crack on :)
[18:30] <dholbach> <oliver_g_1> QUESTION: for the SVN checkout case, where do we get the .orig.tar.gz?
[18:30] <dholbach> oliver_g_1: create it ourselves
[18:30] <dholbach> projects that use autotools often have a          make dist      or some such
[18:31] <dholbach> to continue with the first line of debian/changelog....
[18:31] <dholbach> there's still "unstable; urgency=low"
[18:31] <dholbach> unstable is the default "distro release" that is uploaded to in Debian
[18:31] <dholbach> we use things like "intrepid", "jaunty", etc.
[18:31] <dholbach> we can always just upload to the current development version of Ubuntu
[18:32] <dholbach> which in our case is "jaunty"
[18:32] <dholbach> the 'urgency=low' bit is always added by tools like dch (in the devscripts package)
[18:32] <dholbach> and we can safely ignore it
[18:32] <dholbach> in Debian it describes the urgency of the upload
[18:32] <dholbach> in the Launchpad build service it's ignored
[18:33] <dholbach> <creek23> QUESTION: what's with the 0 in "-0ubuntu"?
[18:33] <dholbach> creek23: it means that we have not inherited a version of it from Debian yet
[18:33] <dholbach> <co0lingFir3> QUESTION: can we apply for "needs packaging" in launchpad even if there is no new version of a tool but just changes via GIT?
[18:34] <dholbach> co0lingFir3: needs-packaging is something else - it's bookkeeping within Launchpad for packages that are not in Ubuntu yet
[18:34] <dholbach> co0lingFir3: you're free to add changes from GIT
[18:34] <dholbach> <apw> QUESTION: if the target version is not an ubuntu release does that target 'development' automatically?
[18:34] <dholbach> apw: dch, which adds boilerplate changelog entries for your (in devscripts package) will default to the version you're running right now
[18:35] <dholbach> <oliver_g_1> QUESTION: what if I want to make a package for Hardy? Can I still leave the changelog line at unstable or jaunty, or does it have to be hardy then?
[18:35] <dholbach> oliver_g_1: take a look at https://wiki.ubuntu.com/StableReleaseUpdates
[18:35] <dholbach> it's about hardy-proposed, hardy-updates, etc.
[18:35] <dholbach> we're not going to have the time here to discuss it, sorry
[18:35] <dholbach> <rugby471> QUESTION: If we package the hello program separately for ubuntu, why does it still retain the 'unstable' bit from debian
[18:36] <dholbach> rugby471: because we got the source package unmodified from Debian
[18:36] <dholbach> <Arc> QUESTION: does "unstable" thus mean that it was uploaded to debian directly, so we'd s/unstable/jaunty if we were uploading to (ie) a PPA for jaunty?
[18:36] <dholbach> Arc: if you add a new changelog entry, use the current development release, yes
[18:36] <dholbach> <maix> QUESTION: isn't it that urgency=high is used for security fixes?
[18:36] <dholbach> maix: yes, in Debian - for us it's irrelevant
[18:36] <dholbach> OK, let's crack on
[18:36] <dholbach> please ask further versioning questions in #ubuntu-motu please :-)
[18:37] <dholbach> the rest of the changelog entry is obvious
[18:37] <dholbach> it describes what was done following the " * "
[18:38] <dholbach> and in the bottom there's the content of DEBFULLNAME and DEBEMAIL
[18:38] <dholbach> plus the current timestamp (date -R)
[18:38] <dholbach> let's move on to     debian/control
[18:38] <dholbach> this is much more exciting
[18:39] <dholbach> it's always divided into at least 2 stanzas
[18:39] <dholbach> the first one is about the source package
[18:39] <dholbach> the following ones (in this case just one) about the resulting binary packages (.deb files)
[18:39] <dholbach> Source: just repeats the source package name
[18:39] <InHisName> :q
[18:39] <dholbach> Section: is one of few sections that are defined in debian policy
[18:40] <dholbach> Priority: is also defined in the debian policy
[18:40] <dholbach> the Maintainer: name defines who takes care of the package
[18:40] <MrKanister> You all should bookmark http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/  ;)
[18:40] <MrKanister> sorry for interupting
[18:40] <dholbach> Standards-Version: mentions which version of the debian policy the package complies with
[18:41] <dholbach> <bullgard4> QUESTION: You used the term 'build service'. What do you mean by that?
[18:41] <dholbach> bullgard4: we always deal with source packages when we introduce changes, which means we upload the .diff.gz the .dsc and the .orig.tar.gz file to a build server where it will be compiled and result in a bunch of .deb files
[18:41] <dholbach> as I said before: this package is very very simple
[18:42] <dholbach> and thus is does not contain a Build-Depends line
[18:42] <dholbach> which you will encounter in almost every other package
[18:42] <dholbach> in this line you specifiy which packages are necessary to build and compile the package
[18:42] <dholbach> it always assumes that build-essential (including libc, gcc, make and so on) is installed
[18:43] <dholbach> but every other Build dependency is specified explicitly
[18:43] <dholbach> <GSMX_> QUESTION: how can you see who the ubuntu mainainer is?
[18:43] <dholbach> apt-cache show hello
[18:43] <dholbach> <ia> QUESTION: if i make some changes in package, so i should enter my name in "Maintainer" field, but current "Maintainer" line should replace by XSBC-Original-Maintainer, right? and what XSBC stands for?
[18:43] <dholbach> ia: good question - this package is unmodified but for all the other packages which we decide to modify (over Debian)...
[18:44] <dholbach> our friends at Debian asked us to preserve the Debian Maintainer in XSBC-Original-Maintainer and add a new Maintainer: which is specific to Ubuntu
[18:44] <dholbach> this was done to prevent stray bug mails from Ubuntu users to go to the Debian maintainer
[18:44] <dholbach> this can automatically be done by running update-maintainer (in the ubuntu-dev-tools package)
[18:45] <dholbach> alright
[18:45] <dholbach> so far to the debian/control section about the source package
[18:45] <dholbach> let's come to the binary package
[18:45] <dholbach> "Package:" just contains the name of the binary package we want to get created
[18:46] <dholbach> in this simple case    upstream project name = source package name = binary package name
[18:46] <dholbach> "Architecture: any" is slightly more exciting
[18:46] <dholbach> this means: please build the package on any architecture individually
[18:46] <dholbach> let me explain
[18:47] <dholbach> when I upload a modified hello source package to the ubuntu build service
[18:47] <dholbach> it will be independently built on armel, i386, amd64, powerpc, sparc, hppa, etc etc
[18:47] <dholbach> so all the architectures that we have available in the data center
[18:47] <dholbach> this is necessary where the binary package afterwards contains architecture dependent code
[18:48] <dholbach> if you compile a C program, it's different on amd64 and powerpc
[18:48] <dholbach> if you just ship a bunch of artwork in a package, you can safely change Architecture to "all"
[18:48] <dholbach> which means: build it once, use the same package on all architectures
[18:48] <dholbach> <ronj> QUESTION: in apt-cache show hello I see it depends on libc6 (Depends: libc6 (>= 2.5-0ubuntu1)), though there's no build-depends. How can that be?
[18:48] <dholbach> ronj: just a sec
[18:49] <dholbach> Depends: ${shlibs:Depends}
[18:49] <dholbach> this means: these packages are necessary to install the package
[18:49] <dholbach> ${shlibs:Depends} is not a package name (obvious, ha!)
[18:49] <dholbach> but it's a variable that is substituted after the build
[18:50] <dholbach> and replaced with all the libaries that the code in the binary package is linked against
[18:50] <dholbach> magic!
=== GSMX_ is now known as GSMX
[18:50] <dholbach> <maix> QUESTION: hasn't support for powerpc etc been dropped recently?
[18:50] <dholbach> maix: we still build packages for powerpc, it's a community port
[18:50] <dholbach> The description contains a short (first line) and a long description for the package management tools
[18:51] <dholbach> if you want to look at a non-trivial package, check out      apt-cache showsrc mono
[18:51] <dholbach> it will show you that the mono source package is split up into 34567654567 different binary packgaes
[18:51] <dholbach> packages
[18:51] <dholbach> it got a lot better recently though :)
[18:51] <dholbach> let's crack on to the next file, we're running out of time
[18:52] <dholbach> debian/copyright is a file that the archive admins are very picky about
[18:52] <dholbach> it contains information about
[18:52] <dholbach>  - who packaged the piece of software
[18:52] <dholbach>  - who the upstream developer(s) are
[18:52] <dholbach>  - who has copyrights on the source
[18:52] <dholbach>  - which individual licenses ALL the files in the source code are under
[18:52] <dholbach> we have to be VERY VERY VERY careful when filling out that file
[18:53] <dholbach> if we miss copyrights or miss files that are maybe unredistributable we're in trouble
[18:53] <dholbach> and you'll make archive admins unhappy if you don't take it seriously :)
[18:54] <dholbach> for a insufficient quick overview, try out this:
[18:54] <dholbach> find . -iname '*.c' -o -iname '*.h' | xargs head | less
[18:54] <dholbach> it will show you the headers of all the .c and .h files in the source tree
[18:54] <dholbach> and show some of the copyrights
[18:54] <dholbach> as I said, it's insufficient
[18:54] <dholbach> <ia> QUESTION: does ubuntu maintainers use some scripts for searching "Copyright" strings in source code tree of project before packaging?
[18:54] <dholbach> ia: there are a few tools for that, best to ask in #ubuntu-motu or #ubuntu-devel about it
[18:55] <dholbach> also check out https://wiki.ubuntu.com/MOTU/GettingStarted because it links to a lot of important information about this stuff
[18:55] <dholbach> (packaging guide, ubuntudevelopment processes, etc.)
[18:55] <dholbach> the last file we just briefly mention is    debian/rules
[18:55] <dholbach> it is a Makefile that wraps around the Makefiles that are used by the upstream source
[18:56] <dholbach> it basically makes use of what you'd do to build and install the software
[18:56] <dholbach> ./configure && make && sudo make install    is something you probably can relate to
=== gabrielix is now known as elisa
[18:57] <dholbach> the new targets   build, clean, binary, etc.   wrap around whatever build infrastructure your project has
=== elisa is now known as elisabeth
[18:57] <dholbach> this is a very blunt and very spartanic package, so it does not make use of debhelper, cdbs or other tools which make the job of maintaining a package a lot lot easier
[18:58] <dholbach> <rugby471> QUESTION (sorry if this is too far ahead) : As far as I understand, if I found a bug, it wasn't being patched and I wnated to fix it, the best way would be for me to download the source (as you have shown) fix the problem, package the package and then ... , is this correct and what happens after the ... ?
[18:58] <dholbach> rugby471: I'll talk much more about that topic at Wednesday 17:00 UTC
[18:58] <dholbach> "fixing bugs in Ubuntu"
[18:59] <dholbach> very short version: generate patch, attach to bug, subscribe ubuntu-main-sponsors (or ubuntu-universe-sponsors team) to get review
[18:59] <rugby471> ok, I'll wait with anticipation! (sorry for interrupting)
[18:59] <dholbach> <ia> QUESTION: Could you advise some concrete docs, where describes in detail, how can create "rules" file manually to understand each line? (so as to don't look at dh_* commands like at some spells :-)
[18:59] <dholbach> ia: https://wiki.ubuntu.com/MOTU/GettingStarted - check out Packaging Guide
[18:59] <dholbach> <maix> QUESTION: if we for example had a python package we'd put a byte-compiling script in that debian/rules?
[18:59] <dholbach> maix: you'd wrap around   python setup.py install  etc (but we have clever tools for that - google for "debian python policy")
[19:00] <dholbach> <oliver_g_1> QUESTION: what if the upstream project did not include a Makefile? Can I put the installation commands (cp) directly into debian/rules?
[19:00] <dholbach> oliver_g_1: you can, there's a lot of different ways to do it
[19:00] <dholbach> OK, the session is over
[19:00] <dholbach> thanks a lot everybody
[19:00] <dholbach> have a great Ubuntu Developer Wekk
[19:00] <dholbach> Week
[19:00] <dholbach> bookmark https://wiki.ubuntu.com/MOTU/GettingStarted
[19:00] <dholbach> hope to see you in #ubuntu-motu
[19:00] <dholbach> make Ubuntu better!
[19:00] <dholbach> make me proud! :-)
[19:00] <NetSKaVeN> great session dholbach!!
[19:00] <CrownAmbassador> Thanks dholbach!!! Was great!
[19:00] <h00k> thanks, dholbach
=== rmcbride_ is now known as rmcbride
[19:00] <rugby471> THanks great seession, It was a great idea to have that command at the start, so that everyone cna see what you are talking about, and also look at it in their won time. Thanks!!
[19:00]  * xnox applauds
[19:01]  * mneptok hugs dholbach 
[19:01] <xnox> thank you
[19:01] <maix> thanks dholbach
[19:01] <audriusz> Big thanks to comes to you :D
[19:01] <bullgard4> Thank you dholbach !
[19:01]  * dholbach hugs y'all
[19:01]  * iulian hugs dholbach as well.
[19:01] <rugby471> cna * can   won * own
[19:01] <ronj> thanks
[19:01] <tictacaddict> thanks, it was a fun!
[19:01] <ganbat> thx
[19:01] <GSMX> thx
[19:01] <ia> thanks a lot )
[19:01] <creek23> thanks...
[19:02] <theseas> thanx dholbach! :)
[19:02] <ikis> thanks!
[19:02] <dholbach> next up is nxvl and bddebian!
[19:02] <creek23> holy! done already. i was just review ing the earlier messages because messages pops too fast :-(
[19:02] <dholbach> "Working Well With Debian!"
[19:02] <nxvl> :D
[19:02] <creek23> oh well. :P
[19:03] <dlynch> yes, thanks very much
[19:03] <mneptok> nxvl: is this a how-to on how to configure flame-mail filters and body armor? ;)
[19:03] <nxvl> mneptok: sort of :P
[19:03] <creek23> really?!?
[19:03] <nxvl> creek23: no
[19:04] <nxvl> well, lets start
[19:04] <nxvl> Debian is the base upon which Ubuntu is built
[19:04] <nxvl> Almost all packages in Ubuntu come from Debian, and most are used unchanged
[19:04] <nxvl> This means that Ubuntu owes a lot to Debian
[19:04] <nxvl> and should endeavour to maintain a good relationship with them
[19:05] <nxvl> There are several differences in the way that Debian and Ubuntu are organised
[19:05] <nxvl> and in the decisions that they have made on some issues that you need to understand in order to work with them most effectively
[19:05] <nxvl> The biggest difference is that in Debian all packages have a maintainer
[19:05] <nxvl> which may be a team, who controls the package
[19:06] <nxvl> They generally make all the decisions about the package
[19:06] <nxvl> and are normally the only ones to perform uploads
[19:06] <nxvl> There are some moves away from this, but it remains the status quo
[19:06] <nxvl> This is different to Ubuntu where in general a package doesn't have a maintainer as such
[19:06] <nxvl> it is just looked after by all contributors
[19:07] <nxvl> This has effects on both Ubuntu and Debian
[19:07] <nxvl> For Ubuntu it means that generally a contributor isn't familiar with a package
[19:07] <nxvl> and doesn't know the Debian maintainer's opinion on things
[19:07] <nxvl> For Debian maintainers it means that they generally don't know who to contact if they wish to discuss a package in Ubuntu
[19:08] <nxvl> The differences in some policy differences can also make it difficult for a Ubuntu contributor to know whether what they are doing also applies to Debian as well
[19:08] <nxvl> This can be especially true for bugs
[19:08] <nxvl> where differing versions of packages
[19:08] <nxvl> or different dependencies in the chain can hide or expose bugs
[19:09] <nxvl> It can be helpful to not consider Debian as a "whole"
[19:09] <nxvl> but more as a group of people who each work in their own little area
[19:09] <nxvl> You will find that if you contact most of them with a bug report, a patch, or a question they will be very friendly and helpful
[19:09] <nxvl> There are a few people that this wouldn't really apply to, but they are definitely in the minority
[19:10] <nxvl> You will probably find if you contact them in a friendly manner about a specific issue then they will probably still help you
[19:10] <nxvl> but it can be a scary thing to do
[19:10] <nxvl> What I am trying to tell you here is not to let the actions of a noisy few spoil your opinions of the whole community
[19:10] <nxvl> Ubuntu takes all source packages from Debian that aren't on a blacklist
[19:11] <nxvl> and automatically "syncs" them in to Ubuntu
[19:11] <nxvl> This means that the source package is taken unmodified and just rebuilt in the latest development version of Ubuntu
[19:11] <nxvl> There are certain things that may be done while building which mean that you may get different binary packages
[19:11] <nxvl> but they do not alter the functionality, for instance
[19:12] <nxvl> https://wiki.ubuntu.com/DebianMaintainerField
[19:12] <nxvl> This process stops at DebianImportFreeze
[19:12] <nxvl> In order to sync a package after that stage you must file a sync request
[19:12] <bddebian> Hey I thought it was at 4:00pm?
[19:12] <nxvl> following the process at https://wiki.ubuntu.com/SyncRequestProcess
[19:13] <nxvl> bddebian: :D
[19:13] <nxvl> Where Ubuntu has to make changes to the package a new upload is done
[19:13]  * bddebian checks his calendar
[19:13] <nxvl> This upload has a version number containing "ubuntu"
[19:13] <nxvl> which ensures that the package won't be synced without manual action
[19:14] <nxvl> so that the changes are not lost
[19:14] <nxvl> When this has been done in the past and a new upload is made to Debian
[19:14] <nxvl> the package will be eligible for "merging"
[19:15] <nxvl> This means taking the two versions of the package and reconciling the changes so that you get the new changes from Debian
[19:15] <nxvl> but also keep the Ubuntu changes
[19:15] <nxvl> See https://wiki.ubuntu.com/UbuntuDevelopment/Merging for more information
[19:15] <SherokiX> apt-cache show hello; apt-cache showsrc hello; /kpom #ubuntu-es
[19:15] <SherokiX> utia
[19:15] <SherokiX> perdon
[19:15] <SherokiX> sorry
[19:15] <nxvl> Sometimes when you go to merge a package you will find that the new Debian version includes all the changes that were made in Ubuntu
[19:15] <nxvl> In that case you perform a sync
[19:15] <SherokiX> is a error... :S
[19:16] <nxvl> meaning that again Ubuntu is using Debian's package for that software
[19:16] <nxvl> now bddebian will tell you how to share with debian
[19:16] <nxvl> bddebian: stage is all yours
[19:16] <bddebian> Eeks, sorry I'm late
[19:16]  * xnox had a question on the chat channel
[19:17] <nxvl> 14:14 < xnox> QUESTION: do 0-ubuntu1 get automaticly synced with -1? or are  they still "merged"
[19:17] <mok0> Thanks nxvl!!!
[19:17] <nxvl> xnox: it's merged
[19:17] <nxvl> xnox: in that case is a special merge, but definetely not a sync
[19:17] <bddebian> Do we need more clarification on that before moving on?
[19:17] <xnox> nope
[19:18] <bddebian> OK
[19:18] <bddebian> There are many ways that you can work together with Debian. For instance
[19:18] <bddebian> you can share patches, work together to package new upstream versions,
[19:18]  * xnox thanks nxvl for intro on the session
[19:18] <bddebian> coordinate transitions, security fixes. You can even become maintainer
[19:18] <bddebian> or co-maintainer of a package in Debian so that the package can always
[19:19] <bddebian> be used unmodified in both with less work.
[19:19] <bddebian> And of course there are several teams, of which you may join.
[19:19] <bddebian> For instance, I actually became a member of the Debian Games team before becoming a DD.
[19:20] <bddebian> OK, moving on..
[19:20] <bddebian> When you are about to make some changes in Ubuntu you can look to
[19:20] <bddebian> see whether these apply to Debian as well, and if they do contact the
[19:20] <bddebian> Debian maintainers and propose that you work together on the issue, or
[19:20] <bddebian> just send them the result of your work.
[19:21] <bddebian> It's always a good practice to coordinate your changes with the debian
[19:21] <bddebian> maintainer, so you can check if there is on his plans, there will never
[19:21] <bddebian> be or he's working on something like the change you are doing.
[19:21] <bddebian> Hmm, grammatical error there.
[19:23] <bddebian> Obviously Ubuntu tends to work a little "faster" than Debian because of the release cycles.
[19:23] <bddebian> Basically the ideal thing is to try to get your fix or proposed fix to Debian first if it is applicable.
[19:23] <nxvl> 14:22 < xnox> QUESTION: where you originally Ubuntu user before you stated to  develop Debian? Or have you switched from Debian to use/develop  Ubuntu?
[19:24] <bddebian> Heh, that's probably too long of a story to get into here. :)
[19:25] <bddebian> In short, I actually started with Debian, got more into maintenance with Ubuntu and have since gotten more into Debian.
[19:25] <bddebian> I didn't (and really still don't have) uber hacking sk1llz and Ubuntu as a community was much more welcoming.
[19:26] <bddebian> Obviously some Debian Developers are much more open/welcome to suggestions, changes, etc.  In many cases Debian Developers are Ubuntu developers.
[19:27] <bddebian> xnox: Did that answer your question or would you like more detail? :)
[19:28] <xnox> bddebian: yeap thanks
[19:28] <bddebian> OK, let's move on to Reporting back to Debian, unless there are any questions.
=== phreakalltheway is now known as brianz0r
[19:29] <bddebian> Many of the bugs on ubuntu are present on debian, but it's important
[19:29] <bddebian> to keep in mind and be VERY careful is that not every bug on ubuntu
[19:29] <bddebian> applies to debian, there are software error which are not reproducible
[19:29] <bddebian> on debian, so if you will ping the maintainer or report back to debian,
[19:29] <bddebian> you mas be sure it applies, so you don't make the Debian maintainer work
[19:29] <bddebian> and test looking for a bug that doesn't exist.
[19:29] <bddebian> s/mas/must/
[19:30] <bddebian> Obviously this can be a bit difficult if you are strictly running Ubuntu.
=== thinkstrohi is now known as strohi
[19:31] <bddebian> Also if you are going to send your work to them (more on this later) you
[19:31] <bddebian> must keep in mind that he or she is also a volunteer as you are, they can add
[19:31] <bddebian> your changes if they think it will help them, but maybe they don't want
[19:31] <bddebian> to apply them, also they don't want to read long diff files with lots of
[19:31] <bddebian> changes, it's better to send them small and separate patches with your
[19:31] <bddebian> changes so they can use the ones they find usefull and discards the ones
[19:31] <bddebian> who doesn't.
[19:31] <bddebian> <bullgard4> QUESTION: So the proper way  would be to report to Launchpad?
[19:32] <bddebian> It really depends on the maintainer.  Many DDs won't pay much attention to LP unfortunately.
[19:32] <bddebian> If you know it is a bug, I would send it directly to Debian BTS.
[19:33] <bddebian> If you aren't sure, a quick e-mail to the maintainer (maybe with a link to the LP bug) would probably be good.
[19:34] <bddebian> That's where timing becomes frustrating.  Some DDs are more responsive than others, obviously.
[19:36] <bddebian> This is getting a bit better, so let me post the next paragraph that may also help:
[19:36] <bddebian> Ok, but, what if i'm a triager? You can test if the bugs are also present
[19:36] <bddebian> on debian and report them back using BTS, being careful on the points
[19:36] <bddebian> talked about earlier, also, LP and bts have a "link" option so you can have
[19:36] <bddebian> on the Bug report at LP the link to the debian bug report so it's easier
[19:36] <bddebian> to keep track of what's going on with the debian bug, also bts has an option
[19:36] <bddebian> like this that you can use with the command 'forwarded $bug $upstream_url'
[19:36] <bddebian> so you can have it backwards, so please use the tools to have a better
[19:36] <bddebian> comunication and avoid the packagers to duplicate efforts on patching.
[19:36] <Flim1> I can't believe I missed the packaging session, I had a question!
[19:36] <Flim1> Ooops, sorry, thought I was in chat
[19:36] <bddebian> NP
[19:37] <bddebian> OK, any other questions before moving on to Finding Information about Debian packages?
[19:37] <bddebian> bullgard4: Did that answer your question sufficiently?
[19:38] <bddebian> OK, let's move on.
[19:38] <bddebian> There are several places from which you can find information about
[19:38] <bddebian> packages in Debian. Knowing where to look to find something out
[19:38] <bddebian> can be quite an art in itself. Luckily there is one place that tries
[19:38] <bddebian> to gather as much of this information as possible. That place is the
[19:38] <bddebian> Package Tracking System, known as the PTS.
[19:38] <bddebian>  
[19:38] <bddebian> The PTS lives at http://packages.qa.debian.org/. You can quickly go
[19:38] <bddebian> to the page for a package using http://packages.qa.debian.org/package.
[19:38] <bddebian> Note that it works using the source package name, but if you enter
[19:38] <bddebian> a binary package name you get a helpful redirect page. Let's take
[19:38] <bddebian> a look at a typical page: http://packages.qa.debian.org/gnupg. Starting
[19:38] <bddebian> from the top left you can see information about the source package,
[19:39] <bddebian> such as versions, and the priority. You also have links to the components
[19:39] <bddebian> of the source package, so using "dget" you can quickly download the current
[19:39] <bddebian> Debian source package.
[19:39] <bddebian>  
[19:39] <bddebian> If you click on the version numbers in the second pane from the top
[19:39] <bddebian> you are taken to http://packages.debian.org/ which gives information
[19:39] <bddebian> about the source package in that version. In the bottom of the left hand
[19:39] <bddebian> pane you have the binary packages that are produced. Clicking on the name
[19:39] <bddebian> leads you back to packages.debian.org and shows you a page with
[19:39] <bddebian> information on that version of the binary package. You also have there
[19:39] <bddebian> links to the bug reports on the package.
[19:39] <bddebian>  
[19:39] <bddebian> In the centre of the PTS page you have a "News" section, and at the top
[19:39] <bddebian> you can have various notices that will appear only if they apply to this
[19:39] <bddebian> package.
[19:39] <bddebian>  
[19:39] <bddebian> In the right hand pane, you have some links to bug reports for the source
[19:39] <bddebian> package. These include the bug reports on all of the binary packages, but
[19:39] <bddebian> can also reports on the source package itself, so I usually use these
[19:39] <bddebian> so that I don't miss them (though they are rare).
[19:39] <bddebian>  
[19:40] <bddebian> Below that you can subsribe to the PTS. This means that if you are really
[19:40] <bddebian> interested in a package you can get emails when things happen with the
[19:40] <bddebian> package. If you select advanced mode from the drop down menu you can select
[19:40] <bddebian> what sort of information you would like to receive.
[19:40] <bddebian>  
[19:40] <bddebian> Lastly in that column you have links to more information about the package,
[19:40] <bddebian> including the buildd logs.
[19:40] <bddebian>  
[19:40] <bddebian> The other important source of information is the Bug Tracking System, known
[19:40] <bddebian> as the BTS. If you go to http://bugs.debian.org/src:gnupg you can see the
[19:40] <bddebian> page for the gnupg source package. This shows an overview of the bugs, with
[19:40] <bddebian> them divided in to sections. You can click on a bug report to get more
[19:40] <bddebian> information.
[19:40] <bddebian> Email is used to communicate with and control the BTS. You can find
[19:40] <bddebian> information on doing this at http://www.debian.org/Bugs/. You can also
[19:40] <bddebian> use "reportbug -B Debian" and the "bts" tool to generate the emails.
[19:41] <bddebian> There's a lot to digest there..
[19:42] <bddebian> Debian PTS has actually been going through quite a few changes lately and has gotten some pretty nice information on it now.
[19:49] <bddebian> OK, so the question came up, does dget download Debian packages or Ubuntu.  It really doesn't matter.  You point dget at a .dsc file and it will pull the corresponding .orig.tar.gz and .diff.gz files.
=== ast_ is now known as |ast|
[19:51] <bddebian> <oliver_g_1> QUESTION: this is probably not nice, but: what happens if I just work on a bug in Launchpad? Will the bugfix eventually reach Debian?
[19:51] <bddebian> This is actually where some of the friction lies between Debian and Ubuntu.
[19:52] <bddebian> The answer, unfortunately is, it can.  As I mentioned earlier, it is really up to the maintainer.
[19:53] <mok0> PTS has links to LP bug pages
[19:53] <bddebian> If you are looking at the PTS page for gnupg you will see in the bottom right corner, the Ubuntu links page.  It gives a link to LP patches that have been submitted against the package
[19:53] <bddebian> As a good maintainer, we really should be checking those.
[19:54] <bddebian> Unfortunately some do not.  Some of it honestly is just ego and some maintainers aren't big fans of Ubuntu.  Some of it is laziness.
[19:55] <bullgard4> @all: In 7 Minutes there will be a class in #ubuntu-classroom about "Understanding GNOME Technologies".
[19:55] <bddebian> Doh, let me post the last bit of this session so it is at least up here and we can discuss if needed.
[19:55] <bddebian> Thanks bullgard4
[19:56] <bddebian> Submitting a patch to Debian:
[19:56] <bddebian> I want to talk a little about submitting patches to Debian. I chose this
[19:56] <bddebian> topic for several reasons. Firstly, it is often requested that Ubuntu
[19:56] <bddebian> forwards more of its patches to Debian. Secondly, it is quite an easy
[19:56] <bddebian> thing to do. Thirdly, if Ubuntu pushes all its patches for a package
[19:56] <bddebian> back to Debian then the package can just be synced in future, reducing
[19:56] <bddebian> the amount of work it takes to maintain them.
[19:56] <bddebian> In order to submit a patch to Debian you should first create a standalone
[19:56] <bddebian> patch that fixes a specific issue. You should then check the BTS to see
[19:56] <bddebian> if a bug has been filed about the issue. If it has then you can email
[19:56] <bddebian> the bug report and attach the patch, sending a control command to
[19:56] <bddebian> tag the bug "patch" ("bts tag #12345 patch").
[19:56] <bddebian> If there is no bug report already then you should file a new one
[19:57] <bddebian> which attaches the patch and sets the patch tag directly. You can use
[19:57] <bddebian> reportbug to do this, but I find it easier to just use my mail client to
[19:57] <bddebian> do it. You can see one of the mails that I sent at
[19:57] <bddebian> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451683.
[19:57] <ubot5> Debian bug 451683 in aiksaurus "aiksaurus: Please add a .desktop file" [Wishlist,Fixed]
[19:57] <bddebian> One thing that we would like you to do when filing bugs in Debian, with
[19:57] <bddebian> or without a patch, is to set a "usertag" on them. This allows the
[19:57] <bddebian> bugs to be tracked as one, so that it can be seen where Ubuntu is
[19:57] <bddebian> contributing back. You can find out how to do this at
[19:57] <bddebian> https://wiki.ubuntu.com/Bugs/Debian/Usertagging.
[19:57] <bddebian> To make all this even more easy if you have well separated changes in
[19:57] <bddebian> your diff to Debian you can use the submittodebian script in the
[19:57] <bddebian> ubuntu-dev-tools package. This automates all of the above steps for
[19:57] <bddebian> you.
[19:57] <bddebian> I would like to point you to one last thing that will make all of
[19:57] <bddebian> this easier in an environment where we have multiple people working on
[19:57] <bddebian> the packages. That is the proposal described at
[19:57] <bddebian> https://lists.ubuntu.com/archives/ubuntu-devel/2007-November/024743.html.
[19:57] <bddebian> If you could all start using this technique when creating patches it will
[19:57] <bddebian> make it easier to understand what patches are meant for upstream.
[19:57] <bddebian> My closing comment would be that there are many people involved in
[19:57] <bddebian> Ubuntu
[19:57] <bddebian> development that are knowledgeable about Debian, so if you need to
[19:57] <bddebian> know where to find something, or would like advice about whether a
[19:57] <bddebian> change is applicable to Debian then you should just ask
[19:59] <bddebian> My apologies to everyone for cutting short, sounds like we are running out of time.  I'll hang around in #ubuntu-classroom-chat and #ubuntu-motu if you have any specific questions.
=== KennethP_ is now known as KennethP
[19:59] <mok0> Thanks bddebian!
[19:59] <oliver_g_1> thanks a lot!
=== KennethP is now known as KennethP_
[19:59] <bddebian> And thanks to those that came and especially to nxvl for the content!
=== KennethP_ is now known as KennethP
[20:00] <iulian> Yea, that was interesting, thanks!
[20:00] <bullgard4> Thank you, bddebian !
[20:01] <bddebian> And if you happen to see me on, feel free to hit me up privately also.  I'm a new DD but I will do what I can.
[20:01] <GSMX> thx
[20:01] <xnox> thank you for the session!
[20:01] <schmiedc> thx !
[20:01] <mbudde> Thank you!
[20:01] <james_w> thanks bddebian and nxvl
[20:01] <theseas> thanx
[20:02] <cool2k> thx it was great
[20:02] <james_w> next up is Ted with "Understanding GNOME Technologies"
[20:02] <james_w> should be an interesting one
[20:03] <james_w> when he turns up :-p
[20:03] <agoliveira> james_w: Ted Gould?
[20:03] <james_w> yup
[20:03] <james_w> ta-da!
[20:04] <tedg> Sorry everyone, I messed up the time conversion.
[20:04] <james_w> tedg: the floor is yours when you are ready
[20:04] <tedg> Cool, hello everyone, I'm Ted Gould.
[20:04] <co0lingFir3> hi ted!
[20:04] <tedg> I'm here to talk a little bit about some Core GNOME Technologies, specifically GConf and DBus.
[20:04] <theseas> hi Ted!
[20:05] <tedg> There is of course many more, but we do have a limited amount of time to get through all of them.
[20:05] <tedg> So, let's get started with GConf.
[20:05] <tedg> GConf at it's most basic level is just a configuration storage mechanism.
[20:06] <tedg> Instead of every application inventing it's own configuration file format, each of them uses a standard API to build.
[20:06] <tedg> Which can be very handy for people like sysadmins and users writing scripts.
[20:07] <tedg> One of the most standard way for people to interact with GConf is through gconf-editor
[20:07] <tedg> It kinda looks like Microsoft's registry editor, which is where it gets it's bad reputation.
[20:07] <tedg> But, I assure you, it's not like the Windows Registry.
[20:08] <tedg> Sometimes apps do put settings inside GConf that they don't export in other ways, so it's a good place to look to see if you can get a setting you're looking for.
[20:08] <tedg> One thing that you might notice as you're looking in GConf editor is that each key has a short and long description.
[20:08] <tedg> This is a translated string that can be used to describe the values or the impact of changing that value.
[20:09] <tedg> Because GConf is a daemon running in the user's session you can change the values in gconf-editor and they'll change live in the application
[20:09] <tedg> This also means that you should be careful when changing values!
[20:09] <james_w> <bullgard4> QUESTION: Why has Configuration Editor  its keys branched in 2 branches 'apps' and 'schemas'?
[20:10] <tedg> Another way that you can access GConf is through the command line tool "gconftool-2"
[20:10] <tedg> bullgard4, Let me answer that in a little bit, I'll get there I promise :)
[20:11] <tedg> So if you want to see all the keys for GNOME Panel you can do: gconftool-2 -R /apps/panel/global
[20:11] <tedg> This gives you a way to start to parse things with scripts and change settings based on icons or other effects.
[20:11] <tedg> So if you wanted to add the  buttons on your panel you could do: gconftool-2 -s /apps/panel/toplevels/top_panel_screen0/enable_buttons -t bool true
[20:12] <tedg> (and you can fix it with: gconftool-2 -s /apps/panel/toplevels/top_panel_screen0/enable_buttons -t bool false)
[20:12] <tedg> Again this is live, as you execute that your top panel should have the buttons appear.
[20:12] <tedg> We can also get the documentation using the gconf tool.
[20:13] <tedg> Short docs: gconftool-2 --short-docs /apps/panel/global/confirm_panel_remove
[20:13] <tedg> Long Docs: gconftool-2 --long-docs /apps/panel/global/confirm_panel_remove
[20:13] <tedg> Another thing that is neat about GConf is that it provides a set of defaults, and then the user's configuration is layered on top of that.
[20:14] <tedg> You can see that in this slide: http://gould.cx/ted/presentations/oscon08/index.php?slide=20
[20:14] <tedg> What happens here is that the upstream values are the lowest level of settings that are used.
[20:14] <tedg> Then we layer on the distro specific changes.
[20:14] <tedg> Then any other changes a user/admin/dept. wants.
[20:15] <tedg> Lastly, the user's specific configuration is put in.
[20:15] <tedg> So, we can also use gconf-tool to revert our settings to the defaults: gconftool --recursive-unset /apps/gnome-power-manager
[20:16] <tedg> (and I'd recommend saving your old ones first: gconftool --recursive-list /apps/panel > panel.gconf.values.txt )
[20:16] <tedg> So if you're debugging a problem that might be a local setting, you can ensure that you have the defaults.
[20:16] <tedg> This is helpful, also in determining which setting broke things.
[20:16] <tedg> The lowest level of settings that GConf provides are called the GConf Schemas.
[20:17] <tedg> These involve the default values, but also the descriptions that are translated.
[20:17] <tedg> We can look at some of the schemas in the system by going to /usr/share/gconf/schemas
[20:18] <tedg> For example you can look at panel-general.schemas to see some of the settings we were just looking at.
[20:18] <tedg> Typically there is a set of schemas for every application that uses GConf
[20:18] <tedg> The way that this layering is built up is through the GConf path.
[20:19] <tedg> The path that starts everything out is: /etc/gconf/2/path
[20:19] <tedg> If you look at that file you'll see that it's basically a list of directories and other paths to include.
[20:19] <tedg> So if the user goes and includes a path in ~/.gconf.path that'll also get included in the list of settings that come through.
[20:20] <tedg> You can include a repository based on what machine you're on, or any other variable of your liking on a per-user basis.
[20:20] <tedg> But a sysadmin could also install some defaults for his/her site by putting a path in /etc/gconf/2/local-defaults.path
[20:20] <tedg> To customize the distribution for their site specifically.
[20:21] <tedg> Now, let's look a little bit at how the other defaults are set up.
[20:21] <tedg> The tree that is derived from the schemas shows up in /var/lib/gconf/defaults
[20:21] <tedg> You probably want to look at %gconf-tree.xml.
[20:22] <tedg> If you search for 'dir name="panel"' in your editor you can see the default panel settings from upstream.
[20:22] <tedg> But those get changed by Ubuntu/Debian in /var/lib/gconf/debian-defaults
[20:22] <tedg> And that tree is built a little bit differently by dh_gconf: http://manpages.ubuntu.com/manpages/intrepid/en/man1/dh_gconf.1.html
[20:23] <tedg> dh_gconf uses a file 'gconf-defaults' in the debian directory of the package to set the settings for that package.
[20:23] <tedg> I wanted to show one, the easiest way that I could find is this, but it might take a while: apt-get source gnome-power-manger ; cd gnome-power-manager-* ; vi debian/gconf-defaults
[20:24] <tedg> Basically the file gets copied to /usr/share/gconf/defaults
[20:24] <tedg> So you can look at 10_gnome-power-manager to see basically the same file.
[20:24] <tedg> It's just a list of keys and values.
[20:25] <tedg> So you can see we're setting the icon type with this line:
[20:25] <tedg>  /apps/gnome-power-manager/ui/icon_policy charge
[20:25] <tedg> And you can see what that does: gconftool-2 --short-docs  /apps/gnome-power-manager/ui/icon_policy
[20:26] <james_w> <maix> QUESTION: where are the translated descriptions of the schemas?
[20:26] <tedg> So, the basics of GConf is that it's a set of configuration storage.
[20:26] <tedg> That provides a good way to store settings in a uniform file format which lets the users and sysadmins have control over the settings in a universal way.
[20:27] <tedg> maix, the translated values are installed in /var/lib/gconf/defaults/%gconf-tree-{locale}.xml but they are built from the schemas.
[20:28] <james_w> <creek23> QUESTION: is there no chance to export settings from GConf Editor -- like windows' regedit does?
[20:28] <tedg> I'm going to stop for a second, for GConf questions.
[20:28] <james_w> <oliver_g_1> QUESTION: how can I import a list created with gconftool --recursive-list ?
[20:29] <tedg> oliver_g_1, creek23, you can export the settings and install them using gconftool.  Let me get the syntax.
[20:30] <tedg> Ah, it's not coming quickly there.  There is a way I can't find right now :(
[20:30] <james_w> <Arc> QUESTION: is GConf intended for just gnome-specific apps or is it used for more general purpose apps (ie, those that may run under other desktop environments)
[20:31] <tedg> Arc, there is no reason that other applications couldn't use GConf, but most do not.  There is some work on a "DConf" which is DBus based which could be more universal across desktops, though it hasn't been released yet.
[20:31] <tedg> Arc, one of the issues with GConf is that it's dependent on CORBA which is a dependency that most folks don't want to carry.
[20:32] <james_w> (gconftool --dump and gconftool --load look like candidates for backup and restore)
[20:32] <tedg> james_w: Yes, thank you.
[20:33] <tedg> Okay, if there aren't any more questions I'll start talking some about DBus.
[20:33] <tedg> DBus is a generic IPC mechanism for applications to talk to each other.
[20:33] <tedg> What makes DBus interesting is that it's designed to be rather small and that it communicates in messages.
[20:34] <tedg> These messages have parameters which are typed in a defined way.
[20:34] <maix> stop, there are some questions
[20:34] <maix> <creek23> QUESTION: is it recommended that user settings should be saved on gconf instead of ~/.foobar?
[20:34] <maix> <maix> QUESTION: it is not possible to have two instances of a program with different settings, is it? (like with other programs where one can specify another conf file by a command line option)
[20:34] <tedg> So when you're building or using a DBus API you have more guarantees about how that API would work.
[20:34] <tedg> maix: Okay.
[20:35] <tedg> creek23: Yes, that is generally preferred.
[20:36] <tedg> creek23: Of course that can be a pretty big change, as doing that users will expect you to be able to respond to configuration file changes.
[20:36] <creek23> ty.
[20:36] <tedg> creek23: Which most apps don't do if they're not GConf enabled.
[20:36] <tedg> maix: I'm not sure of an easy way to do that.  It would be possible to provide a different path, but I don't know of any applications that do that.
[20:37] <tedg> Any more Q's?
[20:38] <maix> not seen more in -chat
[20:38] <tedg> Okay, I'll continue with DBus.
[20:38] <tedg> So DBus is one of the first things specified by Freedesktop
[20:39] <tedg> And so it typically works with most GNOME and KDE applications.
[20:39] <tedg> One interesting development in the DBus world is that there was talk at the Linux Plumbers conference about integrating DBus into the kernel.
[20:39] <tedg> Which would also make it a very fast way for applications to communicate.
[20:40] <tedg> Currently dbus is a daemon, and there are two of them.
[20:40] <tedg> One of them runs the system bus and one runs the session bus.
[20:40] <tedg> The system bus is all of the applications that are executing on your system with privileges and that there should be only one of even with multiple users.
[20:41] <tedg> Probably the most famous of these is HAL, or Hardware Abstraction Layer, which abstracts out the different events that happen at the system level (like plugging in a USB key) and sends out that message.
[20:42] <tedg> One tool to use to start playing with DBus is called "d-feet" and provides a graphical way to send messages on DBus.
[20:42] <tedg> It'll also let you see which applications are exposing themselves over DBus.
[20:42] <tedg> And what functions they're providing.
[20:42] <tedg> Oh, I had a slide for the broadcast point a few lines back :)  http://gould.cx/ted/presentations/oscon08/index.php?slide=27
[20:43] <tedg> The session bus is allocated on a per-user basis.
[20:43] <tedg> So if there are multiple users logged into the system then they'll each have a session bus.
[20:43] <tedg> Applications that sit on the session bus are those that are working with the user, usually providing their desktop environment.
[20:44] <tedg> You can do fun stuff like most media players provide a way to switch songs over DBus.
[20:44] <tedg> The easiest way over IRC to tickle DBus is by using dbus-send
[20:44] <tedg> So you can do something like: dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
[20:45]  * tedg waits to see how many people drop off with a suspended laptop :)
[20:45] <xnox> <Ng> QUESTION: are there any nice wrappers for using dbus from, say, python?
[20:45] <xnox>      the raw API seems kind of cumbersome to use
[20:45] <tedg> Ng: Yes, there is a bunch.  Python-dbus is nice.  And if you're using C and GLib the glib bindings are very nice.
[20:46] <tedg> Ng: I haven't used any others, but in general there are a ton of bindings available for DBus.
[20:46] <tedg> A command that you can play with more safely is: dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
[20:46] <tedg> No, cut-and-paste error.
[20:46] <tedg> dbus-send --session --dest="org.freedesktop.PowerManagement" /org/freedesktop/PowerManagement/Backlight org.freedesktop.PowerManagement.Backlight.SetBrightness int32:50
[20:46] <tedg> There.
[20:47] <tedg> That should (on most laptops) set your backlight to 50%.
[20:47] <tedg> What's also interesting about DBus is the broadcast side, and we can see that from teh command line also.
[20:47] <tedg> To do that we can use dbus-monitor.
[20:47] <tedg> So if we want to watch for backlight events:
[20:48] <tedg> dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement.Backlight'"
[20:48] <tedg> So if you run the previous command in another window, you should see the events show up as their broadcast across the bus.
[20:48] <tedg> Even though you're running on the command line, both the other window and GNOME Power Manger are both getting the event.
[20:50] <tedg> While you can see the interfaces with d-feet, you can also discover them programatically.  As DBus also provides a way for introspection data to come across the bus.
[20:50] <tedg> I'd recommend looking at that in d-feet as it's a rather large XML file.
[20:50] <tedg> A good over view of DBus is at Linux Journal: http://www.linuxjournal.com/article/7744
[20:51] <tedg> Let me take questions, as otherwise we'll run out of time.
[20:51] <Arc> tedg: are you watching #ubuntu-classroom-chat?
[20:51] <tedg> <meebey> QUESTION: who defines the path/namespace/method (or whatever it's called) for dbus, so other applications can call it? and can other applications "hijack" APIs?
[20:51] <tedg> arc: trying :)
[20:51] <xnox> <meebey> QUESTION: who defines the path/namespace/method (or whatever it's
[20:51] <xnox> 	 called) for dbus, so other applications can call it? and can other
[20:51] <xnox> 	 applications "hijack" APIs?
[20:52]  * xnox is sorry
[20:52] <tedg> meebey: The applications apply for a name when they start up, so it is possible for another application to implement the same API and use the same name.  But, DBus ensures that only one app has that name at a time.
[20:53] <tedg> meebey: For instance, with the work you've probably seen about notifications, we're implementing the same DBus API so many applications can work unchanged.
[20:53] <mneptok> xnox: please do not paste to this channel without being asked
[20:54] <tedg> meebey: But, if you try to run our notification daemon and the upstream one is running, one will fail depending on which starts first.
[20:54] <tedg> <Arc> QUESTION: is inotify setup to use DBus on Ubuntu?
[20:55] <tedg> Arc, I'm not sure of a way that inotify could broadcast over DBus.  Really it would probably be more advisable that applications that were interested in doing something like that use Tracker to get that information.
[20:55] <tedg> Arc, that way only Tracker is opening an inotify connection for every file on the system :)
[20:55] <tedg> <GSMX> QUESTION: (sorry, gconf, missed out a bit) What's the difference between regedit en gconf-editor?
[20:56] <tedg> GSMX, well I think a better question there is what's the difference between the windows registry and GConf.
[20:56] <tedg> GSMX: GConf is only for configuration storage.
[20:56] <tedg> GSMX: While the windows registry also does registration of objects.
[20:56] <tedg> GSMX: Also, GConf has a layered approach where regular users rarely have a reason to need administrator access.
[20:57] <tedg> GSMX: Where in Windows you end up with a lot of users needing some level of editing of the windows registry just to be productive.
[20:57] <tedg> GSMX: Which, while they've tried hard to block them, seems to related to quite a few of their security issues.
[20:57] <mneptok> tedg: also of note is that gconf outputs its configuration to human-readable markup, while regdit is the only interface to the Win registry. if you have enough GNOME-fu, you can configure gconf with vi ;)
[20:58] <tedg> mneptok: For the record, I don't recommend that :)
[20:58]  * mneptok does not, either.
[20:58] <mneptok> (vi, that is) >:)
[20:58] <tedg> Arc, AFAIK, DBus doesn't use inotify directly.
[20:59] <tedg> Okay, considering I think we have 15 seconds or so left.  Probably a good time to call it a session.
[20:59] <tedg> Thanks to everyone for showing up.
[20:59]  * Israphel claps
[20:59] <ikis> thanks to you
[20:59] <Arc> thanks tedg!
[20:59] <GSMX> thx!
[20:59] <tedg> I'm usually in #ubuntu-desktop if you have more questions.
[20:59] <ikis> nice session
[20:59] <ronj> thanksthanksthanksthanks
[20:59] <dinxter> cheers ted, interesting stuff
[20:59] <mbudde> Thanks tedg!
[21:00] <meebey> thanks tedg
[21:00] <arch> very thanks :D
[21:00] <xnox> thank you!!!!
[21:00] <maix> thank you!
[21:00] <EnCuKou> Thank you!
[21:00] <audriusz> thanks. this was very interesting
[21:00] <theseas> thanx tedg ang goodnight!!! :)
[21:00] <creek23> thanks you!
[21:00] <oliver_g_1> thanks tedg!
[21:00] <xlazarus> good work, thanks
[21:00] <mnemo> thanks a lot tedg :)
[21:00] <rooivalk> thank you for your corporation! :)))))))))))
=== beDrung is now known as bdrung
[21:02] <creek23> so, that does it for day 1...
[21:02] <theseas> bye everyone!
[21:02] <arch> bye to all!