[00:16] <Guest66012> anybody there
[00:17] <YokoZar> Indeed
[00:17] <Guest66012> your wine session was good
[00:33] <sg-voodoo> gde oni
[09:16] <sundown> Hi everyone! Requires the server openvpn for multiple client connections (to link multiple offices), encrypted using the x509 in ubuntu.
[09:16] <sundown> Need detailed instructions.
[14:30]  * meborc is away: sauna-party + vana tallinn
[14:40] <nalioth> meborc: when you return, can you disable the public away message?  Thanks  :)
[15:00]  * x_dimitri wonders why there's no session in progress
[15:01] <lordnoid> because it starts now :P
[15:02] <jcastro_> We will start in a few minutes!
[15:02]  * x_dimitri thanks jcastro
[15:02] <dholbach> welcome everybody to another Ubuntu Open Week session!
[15:03] <dholbach> Who's here for "Fixing a bug in Ubuntu - it's easier than you think"? Raise your hands! :)
[15:03] <joumetal> o/
[15:03]  * brobostigon raises his hand
[15:03]  * homy raises hand
[15:03]  * lordnoid raises hand too.
[15:04] <dholbach> ah... let me please know which version of Ubuntu you're running :)
[15:04] <brobostigon> 7.10 powerpc
[15:04]  * x_dimitri raises both hands...
[15:04] <homy> intrepid amd64
[15:04]  * xander21c 8,10 
[15:04] <lordnoid> ubuntu 8.10 and xubuntu 8.04 :)_
[15:04] <johnsgruber> hardy
[15:05] <Intey> intrepid, mostly "listening" though
[15:05]  * joumetal is trying jaunty now.
[15:05] <x_dimitri> ubuntu 8.04
[15:05] <dholbach> alright - let's get cracking then
[15:05] <dholbach> please install the following packages first, we're going to need them:
[15:05] <dholbach>   dpatch fakeroot devscripts pbuilder debhelper
[15:06] <dholbach> ok... we all want to fix Ubuntu bugs, but first we need to find a few that are probably going to be easy to fix :)
[15:07] <dholbach> we have a tool called 'Harvest' for that
[15:07] <dholbach> Harvest itself does not know much about bugs or packages or distros, it's just designed to find "low hanging fruit"
[15:07] <dholbach> you can find it at http://daniel.holba.ch/harvest
 QUESTION: Do I need to be on ubuntu machine for this session? I can ssh into one only. enough?
[15:07] <dholbach> CuriousMe: that should be good enough
[15:08] <dholbach> I selected a few bugs already, but while I talk a bit more about bugs and fixing them, please do the following (it will take some time to run in the background):
[15:08] <dholbach> create a file called ~/.pbuilderrc
[15:08] <dholbach> and put
[15:08] <dholbach> COMPONENTS="main universe multiverse restricted"
[15:08] <dholbach> into it
[15:09] <dholbach> if you installed the files I mentioned above, you should now only have to run
[15:09] <dholbach>   sudo pbuilder create
[15:09] <dholbach> to let pbuilder do the hard work of setting up a minimal environment for safely building packages while we're doing something else
[15:09] <dholbach> if you run into trouble, please say so on #ubuntu-classroom-chat
[15:10] <dholbach> alright, let's first have a look at http://daniel.holba.ch/harvest/handler.py?pkg=mwavem
[15:10] <charlie-tca> +
[15:10] <dholbach> harvest lists a one bugs (it's in two categories) for the mwavem package
[15:11] <dholbach> so let's all click on the 152712 link
[15:11] <dholbach> the bug was filed quite a while ago, it seems that something in the init script is wrong
[15:12] <dholbach> when a bug is a bit older, I always first try to find out "was it fixed in the meantime?"
[15:12] <dholbach> if you click on the "Overview" link at the top of the page, you will get an overview of the versions in all the Ubuntu releases
[15:12] <dholbach> does anyone see a changelog entry on the Overview page that might have fixed the issue?
[15:14] <dholbach> it's this line:
[15:14] <dholbach>  * Add LSB headers to initscript
[15:14] <dholbach> in this case we don't need to do anything, just mention that it was fixed in intrepid/jaunty
[15:15] <dholbach> so if somebody of you wants to close the bug with a friendly message, go ahead... :)
[15:16] <dholbach> I checked the new package already, the typo the reporter mentioned is fixed there
[15:16] <dholbach> let's take a look at this URL next:
[15:16] <dholbach>   http://daniel.holba.ch/harvest/handler.py?pkg=telepathy-haze
[15:16] <dholbach> it lists one bug that was resolved upstream already
[15:16] <dholbach> a crasher bug
[15:17] <dholbach> if you take a look at the last comment in the bug, somebody let us know that it was fixed in the 0.2.1 version of telepathy-haze
[15:18] <dholbach> if you check the overview page, you will find out that the version made it into intrepid and jaunty too
[15:18] <dholbach> anyone up for closing the bugs? :)
[15:18] <dholbach> you might ask: "hang on, this was fixed in a new version of Ubuntu, but what about the old releases?"
[15:18] <dholbach> does anybody have an answer?
[15:19] <johnsgruber> It would have to be an SRU, no?
[15:19] <dholbach> johnsgruber: exactly
[15:19] <dholbach> SRU stands for Stable Release Updates
[15:20] <dholbach> https://wiki.ubuntu.com/StableReleaseUpdates is the wiki page that explains the process for getting fixes into -updates
[15:20] <dholbach> we're conservative on what we let into -updates, so if there's a severe problem and somebody finds a minimal fix (not a huge new version) to the problem, it will be considered
[15:20] <dholbach> in the cases above, I'd say: if they're fixed in the new version, we should be good
[15:23] <dholbach> sorry, replied in the wrong channel :)
 QUESTION: Do SRU's apply to all of "main universe multiverse restricted" or just a subset?
 johnsgruber: good question
[15:23] <dholbach>  we fix them for all sections of Ubuntu
[15:23] <dholbach>  it just needs to be justified, somebody needs to be willing to extract the minimal fix, then we upload it into -proposed and after sufficient testing (we don't want to add a regression to the fix) it gets into -updates
[15:23] <dholbach> ok, I have another example:
[15:23] <dholbach>  http://daniel.holba.ch/harvest/handler.py?pkg=pyglet
[15:24] <dholbach> what do we do about this one?
[15:25] <dholbach> any ideas?
[15:25] <itnet7> check the upstream release against intrepid
[15:26] <itnet7> ?
[15:26] <dholbach> itnet7: did you take a look at the "pyglet overview page"?
[15:26] <dholbach> you're right, that should be right place
 upload (merge?) that package to develpment version?
[15:26] <thekorn_> assroom-chat
[15:27] <dholbach> thekorn_: that was rude! :-)
[15:27] <dholbach> if you click on the "Overview" link of the bug page, you will see that we have the new version in jaunty
 Yes that is where I looked and noticed that jaunty is using the Newer release
[15:27] <thekorn_> sorry, the eeepc has a way to small keyboard ;)
[15:27] <dholbach> itnet7: good work - can you close the bug?
[15:28] <dholbach> does anybody know if there's a way we could still get the new pyglet version into intrepid?
 dholbach: backports?
[15:28] <dholbach> gta47b: Exactly!
[15:29] <dholbach> we have the -backports repositories for all current releases and this link explains how to request one:
[15:29] <dholbach> https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages
 dholbach: I haven't really ever closed any bugs before... I would like to close it, but don't want to make a mistake :-P
[15:30] <dholbach> itnet7: it's good to be careful
[15:30] <dholbach> so if you click on the yellow bar saying "pyglet (Ubuntu)" it will let you change the status
[15:31] <dholbach> if you choose friendly words explaining that the new version is in jaunty, but that backporting might be possible and link to the process documentation you should be good
 QUESTION: Is there a list of requested backports ?
[15:31] <dholbach> gta47b: good one... it's a good idea to check if the backport was already requested
[15:32] <dholbach> gta47b: if you check the process page I linked to above, you will see links to the open backport requests for all current releases
[15:32] <dholbach> alright... those were all very simple bugs where we could close them without much work
[15:33] <dholbach> it just requires some detective work to find out "who has been working on that already?"
[15:33] <dholbach> that detective work is what makes good bug fixers, packagers, maintainers and developers
[15:34] <dholbach> you've been all very careful and asked good questions - that's great :-)
[15:34] <dholbach> let's now come to a bit more complicated example
[15:34] <dholbach> did the pbuilder setup work out alright for all of you?
[15:35] <dholbach> hands up? :)
[15:36] <CuriousMe> ^^__^^
[15:36] <dholbach> excellent... some people replied in -chat as well - let's crack on then :)
[15:36] <dholbach> let's take a look at http://daniel.holba.ch/harvest/handler.py?pkg=transmission
[15:36] <dholbach> it lists a lot of bugs that were resolved-upstream and a few fedora patches
[15:37] <dholbach> let's take 291205 as an example
[15:37] <dholbach> you will see that the bug is "confirmed" in Ubuntu and that it's "fix released" in the upstream bug tracker
[15:37] <dholbach> now click on "transmission-trac #1317"
[15:37] <dholbach> it will take you to the upstream bug tracker
[15:38] <dholbach> it says the bug is fixed and the milestone is 1.40
[15:38] <dholbach> if you investigate some more, you will see that neither Ubuntu nor Debian has that new version
[15:38] <dholbach> so we're going to package it ourselves
[15:38] <dholbach> first: try to make sure you have a line like this one in your /etc/apt/sources.list
[15:38] <dholbach> deb-src http://de.archive.ubuntu.com/ubuntu/ intrepid main restricted universe multiverse
[15:39] <dholbach> replace "intrepid" with whatever you're running
[15:39] <dholbach> run this afterwards
[15:39] <dholbach>   sudo apt-get update
[15:39] <dholbach> now run
[15:39] <dholbach>   apt-get source transmission
[15:39] <dholbach> this will download the current source package for transmission
[15:41] <dholbach> now change into the directory that it created
[15:41] <dholbach> (transmission-<version number>)
 QUESTION: am I the only one with transmission-trac 1153?
[15:41] <dholbach> charlie-tca: which Launchpad bug were you on
[15:41] <dholbach> ?
[15:42] <charlie-tca> 291205
[15:42] <dholbach> charlie-tca: try https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/292929
[15:42] <ubot5`> Launchpad bug 292929 in transmission "transmission 1.34 inhibits hibernation by default" [Undecided,Confirmed]
[15:43] <dholbach> alright
[15:43] <dholbach> if you check the contents of the directory, you will see a directory called "debian" in the source code
[15:44] <dholbach> I can't go into too much detail here, I'll give out a few links about packaging later on, for now I'll just say: this directory contains all the changes that are necessary to make a package out of the source code
[15:44] <dholbach> basically "make it build the Debian/Ubuntu way"?
[15:44] <dsto> cd .
[15:44] <dholbach> what we'd normally do is the following:
[15:44] <dholbach>  - go to the homepage of the software developers of transmission
[15:44] <dholbach>  - download the new source code
[15:45] <dholbach>  - apply all the changes to the new version that were necessary for the old version
[15:45] <dholbach> luckily we have tools to make that easier for us :)
[15:46] <dholbach> please open  ~/.bashrc  (or the equivalent if you use another shell) in your favourite editor
[15:46] <dholbach> and add something like the following to it:
[15:46] <dholbach> export DEBFULLNAME='Daniel Holbach'
[15:46] <dholbach> export DEBEMAIL='daniel.holbach@ubuntu.com'
[15:46] <dholbach> save the file and run
[15:46] <dholbach>   source ~/.bashrc
[15:46] <dholbach> (or restart your terminal)
[15:46] <dholbach> that way the variables will be set in your session and the tools we're going to use now will pick them up
[15:47] <dholbach> if you run
[15:47] <dholbach>   cat debian/watch
[15:47] <dholbach> you will see one of the files in the debian directory that will make the process of "download the new version, unpack it, apply the changes, etc." a lot easier
[15:48] <dholbach> please run
[15:48] <dholbach>   uscan --download
[15:48] <dholbach> it will then check which new versions are available and get them for us
[15:49] <dholbach> that worked out OK?
[15:49] <dholbach> if you take a look at  debian/changelog  now, it will probably look somewhat like this: http://paste.ubuntu.com/68884/
[15:50] <dholbach> the first thing we do is change "intrepid" to "jaunty" - we can't upload to intrepid anymore, because it's released already
[15:51] <dholbach> the next thing, which is very important, but which we're going to skip because of time concerns is: explicitly list all the bugs that were fixed in Ubuntu with the new version in a format similar to this: http://paste.ubuntu.com/68885/
[15:52] <dholbach> the (LP: #12345678) syntax will then automatically close all the bugs when the package gets uploaded
 QUESTION: if we want to package for jaunty, do we have to change the 'pbuilder create' then?
[15:53] <dholbach> weboide: yes, if you want to be a good developer, you might even want to run the development release, so you can test things properly
[15:53] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases has more information how you can do that in a sane and safe way
 Question: When you close a bug with comments can you edit those comments to include further info if necessary?
[15:54] <dholbach> itnet7: yes, good point: it's important to be very verbose in the changelog because the next developer who touches the package (we maintain everything as a big team) needs to know what you changed and why
[15:54] <dholbach> OK, if you take a look at the debian/patches directory you will see a couple of patch files there
[15:55] <dholbach> the people who worked on the package before needed to apply them apparently
[15:55] <dholbach> 10_fix_crasher_from_upstream.dpatch is included in version 1.40b1 already, so we can delete it
[15:55] <dholbach> make sure to remove it from debian/patches/00list as well
[15:56] <dholbach> my changelog entry looks like this now: http://paste.ubuntu.com/68887/
[15:57] <dholbach> did that work our alright for everybody?
[15:57] <volo> hi
[15:58] <dholbach> oh, I just found another thing... it seems that since the last time the package was built, some library packages changed their name
[15:58] <Aeoris_> gekki
[15:58] <Aeoris_> *hello
[15:58] <dholbach> so please also change libcurl-dev to libcurl4-openssl-dev in debian/control
[15:59] <dholbach> sorry, I just found it out now
[15:59] <dholbach> then please run
[15:59] <dholbach>   debuild -S -us -uc
[15:59] <dholbach> this will generate a new source package
[15:59] <dholbach> now please run
[15:59] <Aeoris> hey dholbach, back on berlin? ;)
[15:59] <dholbach>   cd ..; sudo pbuilder build transmission_1.40b1-0ubuntu1.dsc
[15:59] <dholbach> this will start the build process for the new version
[16:00] <dholbach> I'm a bit sorry we had to rush through the whole process a bit quickly now
[16:00] <dholbach> please all bookmark this one:    https://wiki.ubuntu.com/MOTU/GettingStarted
[16:00] <dholbach> because it links to all the necessary links (like the packaging guide, like the tutorial videos, etc)
[16:01] <dholbach> and also to the SponsorshipProcess which explains how to get packages uploaded to Ubuntu
[16:01] <dholbach> thanks a lot everybody - I hope you all had as much fun as I did! :)
[16:01] <jcastro> thanks daniel!
[16:01] <jcastro> Now it's Xubuntu with cody-somerville!
[16:01] <dholbach> make me proud! :-)
[16:02] <cody-somerville> :)
[16:02] <cody-somerville> Hello everyone!
[16:02] <Intey> hihou
[16:03] <volo> hi
[16:03] <knome> hello cody :]
[16:03] <cody-somerville> For those of you who don't know, Xubuntu is an official derivitive of the Ubuntu project and is developed and maintained by members of the Ubuntu and Xubuntu community. In the recent months, the Xubuntu community of contributors has grown significantly.
[16:04] <cody-somerville> For example, knome is responsible for our nice new website :)
[16:04] <knome> o/
[16:04] <knome> Check it out: http://xubuntu.org/
[16:05] <cody-somerville> Another accomplishment in the last six months has been the adoptions of a Xubuntu strategy document. We intend to use this document to help us communicate our long term goals for Xubuntu.
[16:05] <cody-somerville> From the document: "The goal of Xubuntu is to produce an easy to use distribution, based on Ubuntu, using Xfce as the graphical desktop, with a focus on integration, usability and performance, with a particular focus on low memory footprint. The integration in Xubuntu is at a configuration level, a toolkit level, and matching the underlying technology beneath the desktop in Ubuntu. Xubuntu will be built and developed as pa
[16:05] <cody-somerville> rt of the wider Ubuntu community, based around the ideals and values of Ubuntu."
[16:06] <cody-somerville> The latest release of Xubuntu provides a more polished experience over Hardy along with a number of new features such as the improved Network Manager 0.7. We had intended to ship the new Xfce 4.6 with Intrepid but unfortunately it was unavailable. Luckily, however, we do intend to provide the recently released Xfce 4.4.3 to Hardy and Intrepid users.
[16:07] <cody-somerville> For Jaunty, I'm happy to report that a number of new and exciting features will be included - such as samba browsing, metadata and search within Thunar, Xfce 4.6, and of course less bugs! :)
[16:09] <cody-somerville> Another goal for Jaunty is to improve and expand our community of artists and doc writers. For this, I'll give the floor to knome for the rest of the session to discuss how and why you should get involved in Xubuntu. :)
[16:09] <knome> Ok, I'm Pasi Lallinaho and I'm the newly appointed Xubuntu Marketing Lead.
[16:10] <knome> If you have any questions throughout the session, please feel free to ask them @ #ubuntu-classroom-chat, we'll answer them with Cody.
[16:10] <knome> So, Xubuntu like Ubuntu consists of separate teams.
[16:10] <knome> One is obviously developers, but there's a lot more to it.
[16:11] <knome> - Documentation team, which is responsible for the Docs
[16:11] <knome> - Web team, which keeps the website updated
[16:11] <knome> A few more words about the web team now
[16:12] <knome> We've recently appointed Vincent (vinnl) as the new Web team leader
[16:12] <knome> He's put a *lot* work on the content of the new website lately
[16:13] <knome> - Artwork team
[16:13] <knome> The artwork team provides the artwork for the project, including the website, themes, wallpapers, ads...
[16:13] <knome> We're currently quite short on artist, feel free to join us!
[16:14] <knome> - Marketing team
[16:14] <knome> The marketing team is relatively new in Xubuntu.
[16:14] <knome> This idea was brought up when i joined the project.
[16:15] <knome> The marketing teams controls and leads the overall branding and promotion
[16:15] <knome> This includes for example soon to be released Artwork guidelines
[16:16] <knome> These guidelines explain further what kind of artwork we want
[16:16] <knome> For example, we have some keywords which should describe the looks of the artwork contributed to Xubuntu
[16:17] <knome> They're goal is also to keep the artwork and brand consistent
[16:17] <knome> *Their
[16:18] <knome> The marketing team (me) works closely with the artwork team (me and a few more) and the web team (vinnl and me)
[16:18] <knome> Without this close cooperation we couldn't have so nice website now - and released on time!
[16:19] <knome> The marketing team is responsible for any other advertising we might want: T-shirts, stickers, maybe some giveaway CDs, screencasts... The sky is the limit!
[16:19] <knome> That was about the teams of Xubuntu
[16:20] <knome> Now I'd like to emphasize on the easyness to join Xubuntu
[16:21] <knome> We're a relatively small project, and I can assure you we're very welcoming and warm community
[16:21] <knome> It was really easy for me to jump in - only after a few months since I joined, we released the new website which was mostly my work
[16:22] <knome> So you can get quite big part on the project when joining.
[16:22] <knome> That means freedom and rights, but also responsibility.
[16:23] <knome> Still I encourage you to join, if you like Xubuntu. We always need more people to help. Even if you didn't know what you could do, just join #xubuntu-devel and tell who you are and that you want to join and we'll make up something.
[16:23] <knome> < homy1> QUESTION: Shouldn't Ubuntu itself be able to run on lower hardware specs instead of making a special Xubuntu for that?
[16:24] <knome> Kind of yes and no. Xubuntu has Xfce as window manager and not Gnome, like Ubuntu has.
[16:24] <knome> So that's already a big difference. Xubuntu is not only for old/low spec hardware, but also for people who want the most out of their PCs.
[16:25] <knome> It's an another alternative.
[16:25] <knome>  < popey> QUESTION: I've seen a lot of comments recently about Xubuntu not being as lean and quick as people expect it might be. What is the Xubuntu team doing to rectify this (on top of anything which applies across all of the derivatives like kernel/upstart changes)?
[16:25] <cody-somerville> :)
[16:26] <knome> cody-somerville, want to answer?
[16:26] <cody-somerville> Sure.
[16:27] <cody-somerville> Xubuntu is not meant to run on legacy hardware. Its intended to run on lower powered machines. People expecting Xubuntu to run on 32mb of ram with a Pentium I simply misunderstand the objective of Xubuntu. However, performance is a concern of ours.
[16:28] <knome> QUESTION: "maybe some giveaway CDs" - does that mean Xubuntu CDs from ShipIt?
[16:28] <cody-somerville> As our team and pool of expertise grows, we'll continue to invest efforts into that objective while attempting to maintain a delicate balance. We want Xubuntu not only to be zippy but also usable and productive.
[16:28] <cody-somerville> Ah, yes. shipit.
[16:28] <cody-somerville> Unfortunately, there are no plans to ship Xubuntu via shipit at this time.
[16:28] <popey> cody-somerville: if that's the case then perhaps https://help.ubuntu.com/community/LowEndSystemSupport needs changing - "Some systems with lower memory configurations will be more responsive without the extra eye candy provided by the Gnome interface. To install XFCE, a lightweight alternative to Gnome"
[16:29] <knome> About the CD thingy:
[16:29] <cody-somerville> popey, I think thats an accurate statement. :)
[16:29] <knome> Offering CDs from ShipIt would have some serious costs.
[16:30] <knome> We don't have the money for that.
[16:31] <cody-somerville> [11:29] <toros> QUESTION: How much help does Xubuntu get from Canonical?
[16:31] <cody-somerville> toros, We receive significant support and assistance from Canonical.
[16:32] <cody-somerville> :)
[16:32] <knome> True.
[16:32] <knome> Any other questions?
[16:35] <Intey> Will you ship persistent USB sticks and the likes with xubuntu on em in the future? I'd need one @ work, alot of old PCs at that place....
[16:35] <knome> < gta47b> QUESTION: XUBUNTU = Ubuntu -GNOME -other heavy apps + light apps ...is that accurate ?
[16:35] <Intey> Ubuntu do so with flash drives, which basically are "too flashy"
[16:36] <cody-somerville> Intey, A lot of old PCs can't boot from USB. However, you can use the new ubuntu tool to create a bootable usb.
[16:36] <Intey> Well it's broken for me and I fiolled a bug after folliwing the session yesterday ))
[16:36] <cody-somerville> :)
[16:37] <knome> gta47b, You're right.
[16:37] <knome> lordnoid said on -chat that Firefox isn't lightweight.
[16:37] <knome> That's also true, but we don't want to ship unready apps with Xubuntu either.
[16:38] <knome> Sometimes we just have to make a choice between a not-so-lightweight and a yet-to-be-finished product.
[16:38] <knome> < rzr> QUESTION: is today xubuntu more suitable than ubuntu than old distro for old computozors ?
[16:39] <knome> rzr, can you clarify?
[16:39] <knome> < toros> QUESTION: What's the main target group of Xubuntu? People with low spec hardware? Geeks, how want better performance? Netbook users? Or all of them?
[16:39] <knome> It's a common misunderstanding that Xubuntu is only for old hardware.
[16:40] <knome> "All of them" would be the best answer, though for example Netbook users there is the Netbook Remix.
[16:41] <knome> As i said earlier, Xubuntu is an alternative for Ubuntu, just like Kubuntu is.
[16:41] <knome> It might be faster, but everybody has to judge it theirselves.
[16:41] <knome> < gta47b> QUESTION: Can the recent xubuntu run as well as win95 on the h/w that win95 runs well on ?
[16:42] <knome> cody-somerville, can you?
[16:42] <cody-somerville> I doubt it.
[16:43] <knome> More questions?
[16:44] <knome> < gta47b> QUESTION: Can you say use ubuntu on recent < 1 year old h/w, use Xubuntu on > x year old h/w, what would you say is "x" here ?
[16:46] <cody-somerville> It would be tough for me to give an accurate number. However, I'd recommend 256mb of ram and atleast 500mhz for a decent experience.
[16:46] <cody-somerville> However, Xubuntu can most certainly run on lower specs and does very well on higher specs.
[16:46] <knome> < rzr> QUESTION: about computozors :) I meant I remember using debian potatoe w/ KDE on a 133 MHz  64MB , this will be probally impossible with today distros how comes ?
[16:47] <knome> I think this is much the same as Cody said about the win95 machine.
[16:47] <cody-somerville> Changes to core components have seen system requirements rise over the last decade.
[16:47] <knome> Ok, any other questions about the Xubuntu community/teams?
[16:48] <cody-somerville> Xubuntu will run on 133Mhz 64MB if you use the alternative cd but it'll be painful :)
[16:48] <cody-somerville> I imagine debian potatoe with KDE on a 133mhz 64MB of ram was painful too - but not as pretty :)
[16:49] <b33r> lol people still use that kind of hardware?
[16:50] <rzr> cody-somerville: it was less painfull in my memories than using windows today :)
[16:50] <Intey> by offering a more lightweight distro, ain't there a danger of pushing the plain Ubuntu to a more demanding future?
[16:51] <knome> There is always people who prefer Gnome over Xfce.
[16:51] <cody-somerville> :)
[16:51] <cody-somerville> Unfortunately that is all the time I have for today.
[16:51] <knome> Yet again: it's your choice.
[16:51] <cody-somerville> I'd encourage everyone to join us in #xubuntu-devel and to get involved!
[16:51] <knome> Me too. See you there!
[16:51] <Intey> OK that sounded weird and almost harsh what I mean is on top of Xfce versus Gnome, they tend to add more and more Eye candy than fixing bugs in recent ubuntu versions
[16:52] <cody-somerville> Xubuntu is easy to get involved with and there is lots of room to air your creativity :)
[16:52] <Odd-rationale> thx, cody-somerville!
[16:52] <Odd-rationale> and knome
[16:52] <knome> My pleasure.
[16:54] <charlie-tca> great job, cody-somerville and knome
[16:54] <knome> Great job all Xubuntu developers and contributors! :)
[16:55] <knome> See you at #xubuntu-devel
[16:59] <jcastro> thanks guys!
[16:59] <knome> o/
[16:59]  * RainCT is waiting for jcastro to change the topic :)
[16:59]  * sebner winks RainCT :P
[16:59] <RainCT> so, who's all here for the REVU session?
[17:00] <knome> hiya RainCT
[17:01] <RainCT> well, I'll suppose most people are shy but will talk later ;)
[17:01] <RainCT> So, hi all. My name's Siegfried Gevatter. I'm a MOTU and the current REVU Coordinator (and Developer).
[17:02] <gta47b> RainCT: Yes!
[17:02] <RainCT> For those of you who are just hanging around and don't know what REVU (pronounced like "review") is, it is the web application that we use at Ubuntu to review new packages from other people for inclusion into Ubuntu.
[17:02] <RainCT> So, people can just upload their packages there and eventually Ubuntu Developers will look at them and suggest improvements. The uploader should then submit new revisions doing the requested changes, and once a Developer things that the package candidate is good enough to enter universe/multiverse, he/she will "advocate it".
[17:02] <RainCT> *thinks
[17:02] <RainCT> Once a package has two advocates (and no negative comments for the last revision) the package will enter Ubuntu.
[17:03] <RainCT> Ah, REVU can be found at: http://revu.ubuntuwire.com
[17:03] <RainCT> If you look at REVU's start page, you'll see that there are currently a lot of packages pending review. This is because there are way more people submitting new packages than developers reviewing them, but also because the last cycle wasn't very good for REVU and packages have accumulated there.
[17:03] <RainCT> We hope that this will improve this cycle, though (and are actively thinking of new strategies to make REVU work more efficient). So, if you have some package there waiting for review please be patient :).
[17:04] <RainCT> By the way, today is "REVU Day" (a day on which many developers will give special importance to package reviewing), so if you have a package on REVU don't hesitate to join #ubuntu-motu and ask for someone to review it (and wait for a while there; it may take time for people to answer).
[17:04] <RainCT> If you are wondering when the next REVU Day will be, there's going to be one every Friday in the coming months. Note that there's also a big announcement on the top-left corner of all REVU pages announcing when the next one will be (or if there's currently one running, like now).
[17:04] <RainCT> Anyway, let's start with the Q&A. I hope for this to be an open and participative session, so let me hear your questions, and feel free to speak here instead of in -chat :).
[17:05] <woody86> How could we (as normal non-motu) help out reviewing the packages in REVU?
[17:05] <homy1> So if I would like a program to be included in official ubuntu universe, I'll start out with uploading it to REVU?
[17:06] <RainCT> homy1: If you feel comfortable enough writting a package from scratch, yes. But first ensure that there's no one already working on it, neither on Ubuntu nor on Debian.
[17:07] <RainCT> You can find packages which are being worked on at Debian here: http://www.debian.org/devel/wnpp/
[17:07] <homy1> well, I'm sure it isn't worked on in debian....
[17:09] <RainCT> (For normal users who want to request a package but don't want to package it, you can file a needs-packaging bug as described on https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages)
[17:09] <RainCT> and for those who want to create on, there's information on it on the same page :)
[17:09] <homy1> Will every package be accepted for universe automatically if it is
[17:10] <homy1> * in a correct package format (ie. lintian checks etc ok)
[17:10] <homy1> * and qualifies for the licenses of universe?
[17:10] <RainCT> homy1: (on your previous comment) Then it would be great if you work on it, but note that it can be a bit difficult to get it right if you haven't done any packaging before, so don't get easily frustrated :)
[17:11] <RainCT> It's usually recommended that new contributors start by fixing bugs, working on syncs/merges, etc., but if you would like to start creating a package from scratch rather than that's perfectly fine, too
[17:11] <RainCT> And no, no packages will be accepted "automatically".
[17:12] <RainCT> As I said, they will be reviewed by MOTUs or Core Developers, and at least two of them have to be happy with the package quality
[17:13] <RainCT> so it will be accepted if a) the licensing is correct, and b) you do everything necessary to get the package into good shape
[17:14] <RainCT> (note that packages can be rejected if they are not considered worthwile for inclusion into Ubuntu, but this doesn't happen usually)
[17:14] <RainCT> (in fact, I think I've never seen this :))
[17:16] <RainCT> Ah, if you decide to create a package then it's also important that you are happy to maintain it afterwards. There are currently many packages in Ubuntu with no one interested to look after them, so please do not "package and leave" :)
[17:16] <RainCT> did this solve your question?
[17:16] <homy1> what happens with those orphaned packages? Are they eventually deleted?
[17:17] <RainCT> Usually not, unless there's a reason for this (very buggy, obsolete and no longer useful, etc.).
[17:17] <homy1> QUESTION: <marrow>  Where can the "orphaned" packages checked out?
[17:17] <RainCT> I think there's currently some discussion on creating a team to look after them
[17:18] <RainCT> and get them into better shape (fix pending bugs, etc)
[17:19] <RainCT> There's a pretty useful tool called "Ubuntu External Health Status" which does list some information on packages that are either not in Debian or in Debian but maintained by the "Debian QA Team" (ie, they haven't a real maintainer)
[17:19] <RainCT> http://qa.ubuntuwire.com/uehs/
[17:19] <homy1> QUESTION: <marrow>  Is there some website where the orphaned packages are listed?
[17:20] <RainCT> This page is actually a pretty good start point if you want to get involved with packaging tasks
[17:20] <RainCT> I've just answered that :). The UEHS page does list many such pages which have some problem, but I don't know of any list listing them absolutely all
[17:22] <RainCT> Harvest (http://daniel.holba.ch/harvest/) is by the way also a quite useful page to find easy tasks, but it focuses on all sorts of packages. If you want more information about this check the logs of Daniel's session on "Fixing a bug in Ubuntu - it's easier than you think"
[17:23] <RainCT> I'll answer woody86's question now, why I skipped before :P
[17:23] <RainCT> < woody86> How could we (as normal non-motu) help out reviewing the packages in REVU?
[17:23] <RainCT> This is actually a very good question (and a bit difficult to answer :))
[17:24] <weboide> QUESTION: Can we upload packages built against jaunty on REVU yet? And is it possible to upload a package for both intrepid (for backports for example) and jaunty?
[17:24] <RainCT> (weboide: I'll answer that after the current question)
[17:24] <weboide> np :)
[17:25] <RainCT> If you have absolutely no packaging experience then there isn't really much you can do to help on REVU
[17:25] <RainCT> Perhaps trying to install packages from there and verifying if they work correctly
[17:25] <RainCT> which will be easier once I add the possibility to link REVU packages to PPAs (there's an "Import from PPA" option in the pipeline, btw)
[17:26] <RainCT> but if you really want to help I'd suggest you to learn about packaging, which will allow you to do much more useful stuff
[17:27] <RainCT> once you are confident with packaging, feel free to review packages and leave comments if you think you've found an issue
[17:27] <woody86> RainCT- sounds good, thanks :)
[17:27] <woody86> I'm being mentored right now, so hopefully I can help you guys out a little more really soon
[17:28] <RainCT> I'm thinking about adding an option for UUC (Ubuntu Contributing Developers - people who have acquired Ubuntu membership through work on packages) to give "recommendations" on packages
[17:28] <RainCT> (well, perhaps this isn't the best word)
[17:30] <RainCT> I don't mean comments with this (which is already possible, and encouraged :)), but the possibility to reject/advocate a package, but instead of couting the rejection or moving the package to the "needs work" section this will just show a special sign to let MOTUs/Core Devs know that someone has looked at it
[17:30] <RainCT> so if an UUC finds many obvious errors in a package he can recommend for it to be moved to "needs work" and a Developer can then do this
[17:31] <RainCT> Oh, something I've forget before. If you have no packaging skills you can help verifying if a package is also being worked on in Debian, but this will be done by automatic tools somewhen soon
[17:32] <RainCT> woody86: is this what you wanted to know? :)
[17:32] <RainCT> any doubt related to this particular question?
[17:33] <RainCT> I'll assume no then, feel free to ask later if you have a question. Now to weboide's question
[17:33] <RainCT> < weboide> QUESTION: Can we upload packages built against jaunty on REVU yet? And is it possible to upload a package for both  intrepid (for backports for example) and jaunty?
[17:33] <RainCT> Yes, you *should* upload packages for Jaunty, but only for Jaunty.
[17:34] <RainCT> If you want to get it backported later then it's helpeful to ensure that it works (eg, the dependencies aren't too high unnecessarily, etc.)
[17:34] <RainCT> but there can't be two different versions of a package at the same time on REVU, and only packages against the current development release are accepted
[17:35] <RainCT> so, first get it into Jaunty, and then you can request a backport of it the usual way
[17:35] <RainCT> as explained on https://help.ubuntu.com/community/UbuntuBackports
[17:36] <weboide> Thank you RainCT i'll focus on jaunty then ;)
[17:37]  * RainCT waits for more questions :)
[17:38] <sebner> Question: What is planned for the future (features , changes for Developers and Users) besides those you already mentioned :)
[17:38] <woody86> RainCT- no, that cleared everything up! Thanks :)
[17:38] <RainCT> Suggestions on how to improve REVU and the current processes are also welcome, btw. If you later have any question/comment, feel free to contact me on IRC or by mail. For problems with REVU, #ubuntu-motu is usually a better place to ask, though
[17:39] <RainCT> now that's a question I've been waiting for :)
[17:40] <RainCT> there are many things in the pipeline and many more ideas about which I'm still thinking
[17:40] <RainCT> some which you may expect to be available within the coming weeks/months are:
[17:41] <RainCT> Seeing the IRC (Freenode) username of REVU users next to their nick, linking (manually or automatically ) REVU packages to Launchpad, Debian, PPAs and Brainstorm (if we decide that package requests should be accepted there)
[17:42] <RainCT> the PPA import being finished, a possibility for reviewers to post neutral comments (to ask questions, leave comments, etc. without moving the package to the "needs work" queue)
[17:42] <RainCT> a "My uploads" section showing all your packages at the top of the index page, to have a better overview over them
[17:43] <RainCT> and more :)
[17:43] <sebner> :)
[17:43] <RainCT> ah, another interesting one: statistics and graphics on how many packages are pending review, how many are accepted, etc.
[17:43] <weboide> QUESTION: When uploading to REVU, the package version should be normal format (2.4.3-0ubuntu1 for example)?
[17:45] <RainCT> Further, I'm heavily thinking about how to improve the current processes and also about work with Debian (if you are interested in this, I may send a message with my toughts to the utnubu mailing list within the coming days/weeks).
[17:45] <RainCT> weboide: that's right! :)
[17:45] <RainCT> the Debian revision for new packages on REVU should always be "-0ubuntu1"
[17:46] <sebner> RainCT: send it ;D
[17:46] <weboide> thanks, just makin sure :)
[17:46] <RainCT> and the upstream version (what comes before the last "-") should be the upstream version, but in some cases you'll have to change it
[17:46] <sebner> Questions. So you will also try to collaborate with Debian mentors?
[17:46] <RainCT> you may find weird upstreams who use versions like "2.0beta1"
[17:47] <RainCT> using this as the version of the package would break updates, so you'll have to use 2.0~beta1 instead
[17:47] <RainCT> the "~" means "before" (and there's also "+" which means "after)
[17:47] <RainCT> so the complete version in this example would be "2.0~beta1-0ubuntu1"
[17:48] <weboide> that would mean "before the version 2.0-0ubuntu1"
[17:48] <RainCT> weboide: indeed
[17:48] <RainCT> Note that you don't need to bump the Ubuntu revision in order to upload new candidates (though this may be required if you go the PPA way once there's the PPA Import feature; I'll figure something out to automatically fix the version string for those)
[17:49] <RainCT> I'll also mention that it's a common mistake for new contributors to upload packages with changelog entries coming from their PPA - this will always be rejected
[17:50] <weboide> You mean with a ppa version?
[17:50] <RainCT> debian/changelog must only have one entry, and the Debian revision must be 0ubuntu1
[17:51] <RainCT> also, using a version like "1.0-0ubuntu5" because «I've uploaded this package previously to my PPA using broken versioning and have "1.0-0ubuntu4" there. I want -0ubuntu5 now to ensure proper upgrads» is usually not accepted
[17:51] <RainCT> weboide: yes, version and changelog entries
[17:52]  * sebner slightly feels ignored :P
[17:52] <RainCT> sebner: Yes. Collaboration with Debian, in any way, is a very interesting topic and it would be great to get something working there
[17:52] <RainCT> but there are no specific plans yet
[17:53] <sebner> RainCT: but keeping in mind that a package in ubuntu won't always get automatically accepted in Debian :\
[17:53] <RainCT> Sure. We still have a few minutes until Mike can rock with Launchpad i18n, so, is there any other question?
[17:54] <sebner> How many people are working on Revu currently?
[17:54] <RainCT> I missed this one:     < marrow> QUESTION: If only those packages are accepted, which are aimed for the  current developement release, than what happens  with those which are still in REVU, but originally they were submitted for an older release?
[17:55] <RainCT> This is a good question. If a package has "intrepid" in the changelog but is otherwise good it may still be advocated and this will be changed by the uploader before uploading it
[17:56] <RainCT> Those packages may be moved to the "needs-work" section at some point, though, to ensure that their submitters are still around and interested in getting them into Ubuntu - so that we don't review them for nothing
[17:56] <RainCT> (but it's unsure if and when this will happen)
[17:57] <RainCT> < sebner> How many people are working on Revu currently?
[17:57] <RainCT> sebner: in which regards? Developers, reviewers..?
[17:57] <sebner> RainCT: everthing you can tell me :P
[17:59] <RainCT> At the moment, actively working on the code there's basically only me. Michael Casadevall (Ncommander) did some important contributions a couple months ago, though (and apachelogger provided some great icons :))
[17:59] <garferi> omg http://www.youtube.com/watch?v=2eSLaQQiok0&feature=related
[17:59] <RainCT> if you want to know the total amount of people with upload rights to the branch, check https://launchpad.net/~revu-hackers
[17:59] <garferi> sry, wrong place
[18:00] <RainCT> Finally, there's a list of the most active reviewers on http://revu.ubuntuwire.com/stats.py
[18:00] <sebner> RainCT: kay, thx. and the hour is over :P
[18:00] <RainCT> It's time, so the session ends here. Feel free to catch me later if you still have anything you'd like to ask/tell me.
[18:00] <nand> Ok, nice session RainCT, thanks!
[18:00] <RainCT> Thanks all for your interest! :)
[18:00] <nand> Next is a presentation about translation and internationalization in Launchpad by mrooney!
[18:01] <mrooney> Hello!
[18:01] <mrooney> I am Michael Rooney, and I'll be talking about setting up a project for translations, getting translations, and then integrating them into your project, with the help of Launchpad.
[18:01] <mrooney> I won't be talking explicitly about the overall Ubuntu translation effort, instead more on a per-project level.
[18:01] <mrooney> Including what developers can do, how users can help, and how multi-lingual speakers can help. Really anyone can contribute to the process.
[18:02] <mrooney> But I will try to address any questions to the best of my ability, don't forget to ask in #ubuntu-classroom-chat, prefacing them with QUESTION and/or mrooney :)
[18:02] <mrooney> I have also recently overviewed this process on my blog at http://mrooney.blogspot.com/ , so if you want to ask questions later feel free to head over there and leave a comment.
[18:02] <mrooney> Okay so first, let's give a brief overview, what is internationalization (i18n) and localization (i10n)?
[18:02] <mrooney> Who here already has an idea?
[18:03] <mrooney> Okay well good, I shall explain!
[18:03] <mrooney> Firstly, they are often abbreviated as above because of the number of letters between the first and last letters.
[18:03] <mrooney> i18n is the process of making locale-specific elements of your application translatable.
[18:04] <mrooney> i10n is then integrating translations into the project so that users of those languages see their language by default instead of English.
[18:04] <mrooney> The scope of this is generally more than just language, and includes the way currencies are displayed, among other things. Everything to do with another culture.
[18:04] <mrooney> For a more thorough explanation, see http://en.wikipedia.org/wiki/Internationalization_and_localization
[18:04] <mrooney> I am now going to cover why and how to do this, but first let me ask if there are any questions before going on, such as about the goals of this process?
[18:05] <mrooney> Basically, we want people speaking other languages to be able to use applications!
[18:05] <mrooney> If you don't localize, people not speaking English can't use your application!
[18:05] <mrooney> And that's no fun.
[18:06] <mrooney> Plus to be included into Ubuntu, at least the main repository, a project will need to have translations.
[18:06] <mrooney> So now the first step is i18n, making a project translatable!
[18:06] <mrooney> I am going to start out with a really simple python example, so anyone can follow allow if they want.
[18:06] <mrooney> *along
[18:07] <mrooney> This is where developers of projects can help, but it is also simple enough that a casual user of the application could contribute to this process as well.
[18:07] <mrooney> Basically, we need to wrap all user-visible text under a translation lookup layer.
[18:07] <mrooney> Initially this will be slightly technical but I think we can handle it :)
[18:07] <mrooney> We will use gettext (http://en.wikipedia.org/wiki/Gettext) for this.
[18:08] <mrooney> Let's use a simple python program. We will create a file called "example.py"
[18:08] <mrooney> Now we will put one line in it: print "Hello, world!"
[18:08] <mrooney> When run, this will print "Hello, world!" to the console!
[18:08] <mrooney> But there is a problem, does anyone see it?
[18:09] <mrooney> Okay the problem is, anyone not speaking english won't understand this program!
[18:10] <mrooney> (while the examples I use are Python, any modern language should have very similar equivalents)
[18:10] <mrooney> First let's make python aware of what language the user is using!
[18:10] <mrooney> Let's add one line to the top
[18:10] <mrooney> import locale; locale.setlocale(locale.LC_ALL, "")
[18:10] <mrooney> What we do here is import the locale module and tell it, for all aspects of a locale: language, currency, dates, etc. (LC_ALL), use the users default language ("")
[18:11] <mrooney> Any questions there?
[18:11] <mrooney> Now we need to add the translation layer for text:
[18:11] <mrooney> import gettext; gettext.install("yourAppName", "locales")
[18:12] <mrooney> This tells gettext to install itself and use "yourAppName" as the scope
[18:12] <mrooney> the name you use here won't matter unless you get into more complex translations
[18:12] <mrooney> the "locales" is telling gettext where to attempt to find translations
[18:12] <mrooney> ie a folder named "locales" wherever test.py is located.
[18:13] <mrooney> QUESTION: ilia: mrooney: don't you mean "l10n" (i.e. L10N ) when you write "i10n"?
[18:13] <mrooney> Yes, I do, sorry :)
[18:13] <mrooney> forgot to connect the dot :)
[18:14] <mrooney> QUESTION: Is the «import locale; locale.setlocale(locale.LC_ALL, "")» chunk really necessary? I've a Python project using gettext but I don't do that there; could this cause any problem?
[18:15] <mrooney> It is definitely useful for other aspects of l10n including currency and dates, though gettext may be able to pick up on the default language by itself
[18:15] <mrooney> If you are only localizing your application with translations and you have found that it works without that, it is probably fine!
[18:16] <mrooney> Okay, now, what gettext.install has done is create a function, named _ (the underscore key), so that it is quick and easy to type and spot.
[18:16] <mrooney> So now we can change: print "Hello, world!" to print _("Hello, world!")
[18:16] <mrooney> What this does is give "Hello, world!" to gettext and ask, do you have a translation for this text, for the users language?
[18:17] <mrooney> Now in the case of English, it will just give back the same text.
[18:17] <mrooney> So if you are following along you can run it now, and it will still print "Hello, world!"
[18:17] <mrooney> So that is the first step, wrapping all user-visible strings in _(), which an intermediate user could probably take a stab at, by downloading a projects source and searching for text they find in the application, assuming it isn't already internationalized, of course.
[18:18] <mrooney> Okay, now we are through the technical part, does that process make sense? Any questions?
[18:18] <mrooney> QUESTION: C++ equivalent?
[18:19] <mrooney> The wrapping of the strings is going to be the same in almost any language
[18:19] <mrooney> The only different part is going to be the initializing line, I don't know it off hand for other languages but it should be easy enough to find online
[18:20] <mrooney> Sorry I can't be more specific, there
[18:20] <mrooney> Okay, now we need to make a translation template that translators can use!
[18:20] <mrooney> This is fairly easy and involves running xgettext on the files you updated.
[18:21] <mrooney> There are language specific programs, python has one, but I am using xgettext as it should work with Python, Java, C++, and others
[18:21] <mrooney> so in this case, you'll want to run "xgettext example.py > messages.pot"
[18:22] <mrooney> If you have a bunch of files you can string them, such as "xgettext file1.py file2.cpp > messages.pot"
[18:22] <mrooney> This will create a template called messages.pot, which contains all the strings necessary for translation.
[18:22] <mrooney> Now from this, an experienced translator could make a translation for you.
[18:23] <mrooney> But to make it as easy as possible, we want to use Launchpad's Rosetta service, which provides a simple web UI to do this!
[18:23] <mrooney> If the project isn't already in Launchpad, go to launchpad.net to register, which is completely free.
[18:23] <mrooney> From here on out I'll be using my project, wxBanker, as an example
[18:23] <Intey> link plz
[18:23] <mrooney> Edit your projects details (in my case: https://launchpad.net/wxbanker/+edit) and check the box that says "Translations for this project are done in Launchpad", scroll to the bottom, and click "Change".
[18:24] <mrooney> You probably won't be able to edit my project :)
[18:24] <mrooney> but the general page is https://launchpad.net/wxbanker
[18:24] <mrooney> Now click the Translations tab of your project in Launchpad and upload the .pot file you just generated with xgettext.
[18:24] <mrooney> If this is your first time doing so, it will need to be reviewed by a human, and will take perhaps a day to get approved, at which point you will receive an email letting you know it has been and you are good to go.
[18:25] <mrooney> Once it has been approved, your project can now be translated!
[18:25] <mrooney> So go to say https://translations.launchpad.net/wxbanker, and if your language settings are configured for more than English, you can start translating!
[18:25] <mrooney> (there is "Select languages" option in the lower right)
[18:26] <mrooney> QUESTION: Could you explain why new translation templates have to be manually reviewed before being accepted, please?
[18:26] <mrooney> So you have upload messages.pot, which is basically a text file containing all the strings
[18:26] <mrooney> However before it goes into Launchpad, someone needs to make sure you actually generated it correctly, that it looks sane, et cetera
[18:27] <mrooney> So that someone doesn't say try to make their own by hand or otherwise do something silly
[18:27] <mrooney> Perhaps someone wasn't wrapping their strings correctly, or another issue. Maybe the original strings aren't in English!
[18:28] <mrooney> So in this way a human needs to verify it is sound.
[18:28] <mrooney> Make sense?
[18:28] <Intey> does.
[18:28] <RainCT> Yep, thanks :)
[18:28] <mrooney> So now, how can you get it translated?
[18:29] <mrooney> Well, if you know another language you can tell launchpad via the language settings button
[18:29] <mrooney> Then you translate into that language yourself.
[18:29] <mrooney> However, this probably isn't the case for a lot of people, and one language won't be enough.
[18:30] <mrooney> A very interesting feature of Launchpad however is that it will show translations from other projects, so you can do common ones yourself without knowing the language.
[18:30] <mrooney> For example if "Hello" is in your template, it will tell you that other projects use "Hola" for Spanish and allow you to select that.
[18:30] <mrooney> So in this way you can make all the basic File, Help, Save, and such translated
[18:31] <mrooney> There are a lot of projects in Launchpad, you might be surprised to find that translations already exist for a lot of strings!
[18:31] <mrooney> QUESTION: will there be a special howto available for those of us who dont write code at all, consider themselves power users though and are literate enuff...in short: ppl that just want to translate, efficient, sound, clean. supportive....blah..?
[18:32] <mrooney> Intey: do you mean people that know another language and want to translate from English into that?
[18:32] <Intey> exactly^
[18:33] <mrooney> In that case what you will want to do is probably is join ubuntu-translators (https://translations.launchpad.net/+groups/ubuntu-translators)
[18:33] <mrooney> However you will probably need to demonstrate you have translation experience as those users can translate all of Ubuntu (and we need definite help there!)
[18:33] <mrooney> So you may want to find projects (like wxBanker) which is open and allows anyone to translate
[18:34] <mrooney> So I would start off volunteering to translate new projects
[18:34] <mrooney> There are going to be a lot of new UIs made for Jaunty, for example, I imagine, so if you want to start asking around how you can help translate those
[18:34] <mrooney> QUESTION: What do we have to do in case of changes made to the source code? Should we just freeze the project and wait for the translatians to be done and then release the project?
[18:35] <mrooney> Well, the advantage of gettext is that it won't cause any regressions
[18:35] <mrooney> So you can wrap all your strings and generate a template , and it will still function the same
[18:35] <mrooney> So you don't have to freeze the project development, you can release it internationalized with no translations for example
[18:35] <mrooney> Does that make sense?
[18:36] <weboide> yes, and what happens when you upload new/updated *.pot files to LP?
[18:36] <mrooney> weboide: so when you upload a new template, any strings already translated are naturally not lost
[18:37] <mrooney> so if you forgot to wrap say the "Help" menu (a real example that happened to me :)
[18:37] <mrooney> you can wrap that in the code, generate a new template, upload it, and now there is one new string
[18:37] <mrooney> When people translate that string (or you use suggestions), just download the translations again and replace the old ones
[18:38] <mrooney> and now you have that translation for the new string
[18:38] <weboide> Thanks :)
[18:38] <mrooney> QUESTION: How are translations done for static content like SVG images, themes and books? Can those be helped via Launchpad as well?
[18:38] <mrooney> It depends :)
[18:39] <mrooney> As long as you can generate a list of text that needs to be translated, yes
[18:39] <mrooney> Picklesworth: It should also be noted, on the topic of translations, that GTK offers a lot of Stock content for things like menu items and buttons, which magically translate themselves too
[18:39] <mrooney> Yes, that is a good point
[18:40] <mrooney> And addresses what RainCT asked earlier I believe, with setting up the locale module
[18:40] <mrooney> When you do that, stock names including File, Edit, About items will often be automatically translated if the framework suppots it
[18:41] <mrooney> QUESTION: how do you handle constraints (like: there's only so much room for a line of text)
[18:41] <mrooney> This gets more into UI design, but it is a great point
[18:42] <mrooney> If you are using a UI framework properly, you ideally won't have such constraints
[18:42] <mrooney> It is important to almost never use absolute positioning, for example
[18:42] <mrooney> this will cause painful issues
[18:43] <mrooney> You want to design it from the ground up ideally, to make minimal assumptions about length, such as using controls that support word-wrapping
[18:44] <mrooney> GTK and wxWidgets for example have the concept of sizers
[18:44] <mrooney> And you will want to use layout elements like that
[18:44] <mrooney> samgee: does that answer your question at all?
[18:44] <samgee> I guess so
[18:45] <Intey> wait, as a end-translator, does launchpad offer ways to see the maximum character lenght or somesuch? if not..blueprint?
[18:45] <mrooney> Basically you want to attempt to eliminate constraints by word-wrapping and laying out without making assumptions
[18:46] <mrooney> Intey: You can add comments to each string, which I didn't mention
[18:46] <mrooney> Intey: but for example you might put // TRANSLATORS: this string can only be 100 chars
[18:46] <mrooney> before the string
[18:46] <mrooney> and if you pass something like --coments=// to xgettext, it will add that to the template and show up on Rosetta
[18:47] <mrooney> I don't remember the exact xgettext argument, it probably isn't exactly that
[18:47] <mrooney> But in that way you can inform translators of specific knowledge
[18:47] <mrooney> and context
[18:48] <mrooney> So that can help address samgee's issue perhaps as well. When you have to have a constraint, you can at least make translators aware
[18:48] <mrooney> Let's see before I explain getting the translations into your project, which is easy, there was one more ?
[18:48] <mrooney> Intey: I sometimes find myself accidentoly adding translations that have already been suggested, whilst proof-reading them...
[18:48] <mrooney> Intey: as a result fellow translaters think Im stealing their work ...sort of
[18:49] <mrooney> Rosetta will inform you of whether you can freely use a suggested translation or not
[18:49] <mrooney> It will put a yellow warning sign next to a suggestion, if Launchpad isn't sure that you can freely use it
[18:49] <mrooney> and in that case you would need to ask or review the license
[18:50] <mrooney> And conversely when you make translations in an open-source project, you are typically allowing OTHER translators to use what you used
[18:50] <mrooney> in another project
[18:50] <mrooney> Okay lets go to the final step!
[18:51] <mrooney> Once you have some translations in Launchpad, you are basically done and it is super easy to integrate them into the project!
[18:51] <mrooney> Visit the translations page for your project in Launchpad, and click the "Download translations" link on the right.
[18:51] <mrooney> From here ensure "Everything" is selected, and change the Format to "MO format" (what gettext will use). Now click "Request download".
[18:51] <mrooney> This isn't always instant, although you will be emailed with a link to the file if it isn't.
[18:51] <mrooney> Now, remember that "locales" folder we told gettext about earlier?
[18:52] <mrooney> Once you downloaded your file "launchpad-export.tar.gz", extract that into where your source is, and rename it to "locales".
[18:52] <mrooney> Bam! Now gettext will find your translations and use them instead of English when available
[18:52] <mrooney> Bam! Now gettext will find your translations and use them instead of English.
[18:52] <mrooney> whoops, well twice for emphasis
[18:52] <mrooney> Now anyone using a language that you have a translation for, will now see the translations instead of English!
[18:52] <mrooney> So that is the process from start to finish
[18:53] <mrooney> Any other questions?
[18:53] <mfoniso> yeah...
[18:54] <mrooney> RainCT: Did I address your locale.setlocale question, on the advantages of how frameworks such as GTK and wxPython will pick up on that and translate stock strings automatically?
[18:54] <mrooney> QUESTION: what are the limitations of gettext? Are there any alternatives that provide advantages (I remember a Mozilla talk at FOSDEM about something better in the works)
[18:54] <mrooney> One limitation is that strings are translated in an all or nothing approach
[18:55] <mrooney> either you have a translation that exactly matches or it doesn't get translated
[18:55] <RainCT> mrooney: Yes, thanks :). (It isn't an issue for my project as it uses pygame, but that's good to know).
[18:55] <mrooney> so if you have a translation for "Hello" and "world", you still need one for "Hello world"
[18:55] <mrooney> if you use all of those
[18:55] <mrooney> mfoniso: a question?
[18:56] <mrooney> QUESTION: is automatic translation an option (babelfish etc.) an option if there are not enough volunteers?
[18:56] <mrooney> not that I know of, and that would generally produce poor translations
[18:56] <mrooney> however, using the suggestions from Rosetta is almost as good and will get you better results
[18:56] <mfoniso> mrooney: I've asked in #ubuntu-classroom-chat
[18:56] <mrooney> however it is a one-at-a time operation
[18:57] <mrooney> QUESTION:how does one go about doing translations into other langauges, for ubuntu
[18:57] <mrooney> Okay let's see if I can address this as my last question
[18:57] <mrooney> If you look at https://translations.launchpad.net/ubuntu, you will see we need a LOT of translations!
[18:58] <mrooney> So help in this area is hugely appreciated and needed
[18:58] <mrooney> and rewarding because you can see your own translations :)
[18:58] <mrooney> to be able to translate here, you need to be a member of ubuntu-translators
[18:58] <mrooney> So you'll want to look into joining https://translations.launchpad.net/+groups/ubuntu-translators
[18:59] <mrooney> which will allow you translate almost all of Ubuntu that supports it
[18:59] <mrooney> So find the sub team that you want to translate in
[18:59] <mfoniso> nice
[19:00] <mrooney> And you can ask to join their group
[19:00] <mrooney> Okay, I hope that wraps it up!
[19:00] <jcastro> Yay, thanks Mike!
[19:00] <mfoniso> what do you mean by sub team?
[19:00] <mfoniso> sorry, I don't mean to drag it out
[19:00] <mrooney> If you have any questions relating to this, feel free to get in touch me , details are on launchpad.net/~michael
[19:00] <samgee> thanks mrooney
[19:00] <Intey> Awesome class there, thanks
[19:00] <mfoniso> ok, thanks mrooney
[19:01] <jcastro> ok great
[19:01] <jcastro> next session is how to write Python apps using the Launchpad API
[19:02] <jcastro> barry: take it away!
[19:02] <barry> jcastro: thanks! hello everybody
[19:03] <barry> i'm going to to try to provide some instruction on using launchpadlib to write python programs that access launchpad through its webservice
[19:04] <barry> i've never done an ubuntu open week session before so please be gentle :)
[19:04] <barry> first some background:
[19:04] <barry> as you know, there are lots of things you can do through launchpad's web interface.  you can submit and manage bugs, register branches, answer questions ,etc.
[19:05] <barry> you also have a lot of data in launchpad that you can access through the web ui
[19:05] <barry> our intent is that anything you can do through the web ui, you shoudl be able to do in a script
[19:06] <barry> we've published a REST interface to launchpad, making it a "web service"
[19:06] <barry> and we provide supported python bindings to that REST interface, to make it really easy for you to script launchpad via python
[19:06] <barry> it's feasible for third parties to write bindings for the REST interface in other languages, though we won't support it officially
[19:07] <barry> you can get the python bindings from here:
[19:07] <barry> https://launchpad.net/launchpadlib
[19:07] <barry> and...
[19:07] <barry> https://code.launchpad.net/launchpadlib
[19:08] <barry> and all the documentation is here:
[19:08] <barry> https://help.launchpad.net/API/launchpadlib
[19:08] <barry> any questions so far?
[19:09] <barry> stdin: reminds me that launchpadlib is packaged in intrepid, so it's easier to get
[19:09] <barry> stdin: thanks
[19:09] <barry> python-launchpadlib
[19:09] <barry> we haven't yet put the code in the cheeseshop, but that will happen at some point
[19:11] <barry> the api docs mentioned above provide a nice starter for scripting launchpad, but there are a couple of things to be aware of
[19:12] <barry> first, there's an open bug describing a problem scripting the staging server, so it is recommended that you test against edge for now.  be careful though because edge has real data, so try to use read-only changes to start with
[19:12] <barry> also, you will need a web browser available because launchpadlib must authenticate you through your browser
[19:12] <barry> your browser is the only client you trust :)
[19:13] <barry> also, you need to be a launchpad beta tester currently to have access to the launchpad web service
[19:14] <barry> when you go through the tutorial on the docs page, you will be asked to grant your application various levels of authorization
[19:15] <barry> does anybody have any questions?
[19:16] <barry> i should also mention that full launchpad functionality is not yet exposed in the web service.  you can do a lot of stuff right now and over time we'll be fleshing out the missing pieces
[19:16] <barry> our intent is that you should be able to access any data you have permission to in the web ui
[19:16] <barry> and perform any tasks you have permission to also
[19:17] <barry> i highly recommend reading the tutorial mentioned above, it will give you a great start into scripting launchpad via python
[19:22] <barry> alright, so let's go through a simple example
[19:23] <barry> i'm assuming you already have launchpadlib installed.  if not, and you're having problems with that, let me know
[19:23] <barry> note that you'll also need wadllib installed.  i would think the intrepid package dtrt, but if you're installing from source, launchpadlib's setup.py doesn't yet depend on wadllib
[19:24] <barry> you need to start by authenticating to launchpad, through your browser
[19:24] <barry> make sure your browser is open and that you're logged into launchpad
[19:25] <barry> then fire up your python interpreter
[19:25] <barry> start by importing some useful objects:
[19:25] <barry> >>> from launchpadlib.launchpad import Launchpad, EDGE_SERVICE_ROOT
[19:25] <barry> generally, you will want to set up caching, as this makes interacting with launchpad much faster.  to do this you need to set up a cache directory
[19:26] <barry> in the following i'm going to use /tmp/cache but you can use anything you have write permission to
[19:26] <barry> the next step is to authenticate to launchpad (again, note that i'm using edge here)
[19:26] <barry> launchpad = Launchpad.get_token_and_login('just testing', EDGE_SERVICE_ROOT, '/tmp/cache')
[19:27] <barry> this creates an aplication for you called "just testing"
[19:27] <barry> it sets your client to talk to edge and to cache data in /tmp/cache
[19:27] <barry> you'll now see a message at stdout and your python will be waiting for you to complete the task
[19:28] <barry> you should also notice your web browser has opened an authentication page
[19:28] <barry> it's at this point that you are going to grant the appropriate access to  your launchpadlib application
[19:28] <barry> i   recommend for now to select read-only data
[19:29] <barry> any questions or problems so far?
[19:29] <barry> great
[19:30] <barry> once you've given access to your application, go back to your python prompt and hit return
[19:30] <barry> your python client is now primed and ready to talk to launchpad
[19:31] <barry> the 'launchpad' object is your door into the vast array of objects and actions you can take
[19:31] <barry> you can think of it as the root of a big tree of resources
[19:31] <barry> i.e. web resources
[19:31] <barry> 'launchpad' has a number of top level objects directly under it
[19:32] <barry> and through it you can access bugs, people, etc
[19:32] <barry> for example, the first thing you can do is view the person object that represents yourself:
[19:32] <barry> >>> launchpad.me
[19:32] <barry> <person at https://api.edge.launchpad.net/beta/~barry>
[19:32] <barry> it's through 'launchpad.me' that you can script changes to your presence in lp
[19:33] <barry> for example, if i wanted to see my own display name, i could do
[19:33] <barry> >>> launchpad.me.display_name
[19:33] <barry> u'Barry Warsaw'
[19:33] <barry> note that the value of this attribute is a python unicode
[19:34] <barry> that's important to keep in mind for those of you with non-ascii characters in your name!
[19:34] <barry> i can find out if i'm a team <wink>
[19:34] <barry> >>> launchpad.me.is_team
[19:34] <barry> False
[19:34] <barry> and i can see my own timezone
[19:35] <barry> >>> launchpad.me.time_zone
[19:35] <barry> u'America/New_York'
[19:37] <barry> one nice thing you can do is use python's dir() function to see all the things you can find out about an object
[19:37] <barry> >>> dir(launchpad.me)
[19:37] <barry> ['FIND_ATTRIBUTES', 'FIND_COLLECTIONS', 'FIND_ENTRIES', 'JSON_MEDIA_TYPE', '__class__', '__delattr__', '__dict__', '__doc__', '__getattr__', '__getattribute__', '__hash__', '__init__', '__members__', '__methods__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__', '_create_bound_resource', '_dirty_attributes', '_ensure_representation', '_get_external_param_name', '_get_parameter
[19:37] <barry> _names', '_root', '_transform_resources_to_links', '_wadl_resource', 'acceptInvitationToBeMemberOf', 'addMember', 'admins', 'confirmed_email_addresses', 'date_created', 'deactivated_members', 'declineInvitationToBeMemberOf', 'display_name', 'expired_members', 'getMembersByStatus', 'hide_email_addresses', 'homepage_content', 'invited_members', 'irc_nicknames', 'is_team', 'is_valid', 'jabber_ids', 'join', 'karma', 'languages', 'latitude',
[19:38] <barry>  'leave', 'longitude', 'lp_attributes', 'lp_collections', 'lp_entries', 'lp_get_named_operation', 'lp_get_parameter', 'lp_has_parameter', 'lp_operations', 'lp_refresh', 'lp_save', 'mailing_list_auto_subscribe_policy', 'members', 'members_details', 'memberships_details', 'mugshot', 'name', 'open_membership_invitations', 'participants', 'preferred_email_address', 'proposed_members', 'resource_type_link', 'self_link', 'setLocation', 'setLo
[19:38] <barry> cationVisibility', 'sub_teams', 'super_teams', 'team_owner', 'time_zone', 'visibility', 'wiki_names']
[19:38] <barry> not all of those are of interest to you though
[19:38] <barry> method with names starting with an underscore are private
[19:39] <barry> methods that start with lp_ are special in the sense that they are actions you can take on client-side objects
[19:39] <barry> they don't correspond to actions in launchpad
[19:39] <barry> for example, if you make a change to an object, you would need to call lp_save() on it to "push" those changes back to launchpad
[19:41] <barry> let's say you wanted to get some information on a different user, how would you do that?
[19:41] <barry> well, there's a 'people' object at the top level, and we can use that to access people by their launchpad id
[19:41] <barry> e.g.
[19:41] <barry> >>> launchpad.people['salgado']
[19:41] <barry> <person at https://api.edge.launchpad.net/beta/~salgado>
[19:42] <barry> >>> salgado = launchpad.people['salgado']
[19:42] <barry> >>> salgado.display_name
[19:42] <barry> u'Guilherme Salgado'
[19:42] <barry> we can also get people by their email addresses, through a different interface
[19:43] <barry> >>> salgado = launchpad.people.getByEmail(email='guilherme.salgado@canonical.com')
[19:43] <barry> >>> salgado.display_name
[19:43] <barry> u'Guilherme Salgado'
[19:43] <barry> something important to note here...
[19:43] <barry> you're used to providing positional arguments in "normal" python
[19:44] <barry> so by looking at this example, you might ask, why did you type the argument name in the above call?
[19:44] <barry> (e.g. the 'email=' part)
[19:44] <barry> the answer is that because of the peculiarities of our wadl definition, the python client side of the rest api doesn't understand positional arguments
[19:44] <barry> so all method arguments are keyword arguments and must be entered explicitly
[19:45] <barry> we may fix this some day, but for now, it's something you need to keep in mind
[19:45] <barry> any questions up 'til now?
[19:45] <barry> ok
[19:46] <barry> one other way to find people
[19:46] <barry> you can actually do a full text search, so if you only know part of a user's name, you can do it like this:
[19:47] <barry> >>> for person in launchpad.people.find(text='salgado'):
[19:47] <barry> ...   print person.display_name
[19:47] <barry> ...
[19:47] <barry> abel
[19:47] <barry> agustincsw
[19:47] <barry> Ariel_salgado
[19:47] <barry> axlsal
[19:47] <barry> Bruno Fecchio Salgado
[19:47] <barry> Camilo Salgado
[19:47] <barry> and so on...
[19:48] <barry> similar to the top level object 'people', you have access to bugs, like so:
[19:48] <barry> >>> bug1 = launchpad.bugs[1]
[19:48] <barry> >>> bug1.title
[19:48] <barry> u'Microsoft has a majority market share'
[19:49] <barry> note that bugs are accessible via their bug id
[19:50] <barry> currently, the only two top-level objects available are bugs and people
[19:51] <barry> a lot of the introspective power of python is available to you, so if you're pretty comfortable with python and launchpad, you should be able to build fairly sophisticated applications
[19:52] <barry> as i mentioned the dir() function above gives you too much information you don't care about, you can use one of the other 'launchpad' objects instead
[19:52] <barry> e.g. to find out the things you can do to a person, you can try this:
[19:52] <barry> >>> launchpad.me.lp_operations
[19:52] <barry> ['leave', 'setLocationVisibility', 'addMember', 'declineInvitationToBeMemberOf', 'join', 'getMembersByStatus', 'setLocation', 'acceptInvitationToBeMemberOf']
[19:53] <barry> unfortunately, python's built-in help() function is currently not very useful
[19:54] <barry> a couple of other interesting tidbits
[19:54] <barry> objects like launchpad.me are called 'entities' and things like launchpad.people are called 'collections'
[19:55] <barry> thik of entities as the leaves of the big object tree, though of course entities can be linked to other entities or collections
[19:56] <barry> whenever you make a change to an entity's properties, you need to call 'entity.lp_save()' to save them on launchpad
[19:56] <barry> otherwise the changes only occur locally and will be lost when you quit your client
[19:56] <barry> there's also something called a 'hosted file', which you can mostly think of as a binary blob
[19:56] <barry> your mugshot is that way for example
[19:57] <barry> to read the data of a hosted file, you need to open it and read it.
[19:57] <barry> hosted files also have a content_type
[19:57] <barry> so:
[19:58] <barry> >>> f = launchpad.me.mugshot.open()
[19:58] <barry> >>> data = f.read()
[19:58] <barry> >>> f.content_type
[19:58] <barry> 'image/jpeg'
[19:58] <barry> data would now be the image data of your mugshot
[19:58] <barry> well, i'm just about out of time so let me just repost the documentation link
[19:58] <barry> https://help.launchpad.net/API/launchpadlib
[19:59] <barry> and i encourage you to submit enhancement requests and bugs, and in general test out the launchpadlib to script your applications
[19:59] <barry> i think that's it for me, thanks for your time!
[19:59] <jcastro> thanks barry!
[20:00] <iulian> Nice session, thanks barry.
[20:00] <barry> iulian: thanks!
[20:00] <stdin> an interesting talk, I already have a couple ideas on what to use launchpadlib for :)
[20:01] <barry> cheers everyone
[20:01] <jcastro> ok guys, benc is having some network issues in his hotel room
[20:01] <jcastro> so we're going to give him a few minutes to sort it out
[20:02] <jcastro> benc will be discussing what the kernel has been up to this past cycle and what they're planning on doing during the jaunty cycle
[20:03]  * BenC made it
[20:04] <BenC> jcastro: Appologies, thanks for contacting me
[20:05] <jcastro> BenC: no worries
[20:05] <jcastro> BenC: take it away!
[20:05] <BenC> Welcome everyone
[20:06] <BenC> For this session I wanted to review a lot of what we did in Intrepid in relation to the kernel, and how we will apply that to jaunty moving forward
[20:08] <BenC> For those that followed the development cycle, you will realize we started a new tree called ubuntu-next (not to be confused with linux-next) where we continued to track the latest upstream kernel source
[20:08] <BenC> This in fact allowed us to make a last minute decision to go with 2.6.27 in Intrepid instead of 2.6.26
[20:09] <BenC> While over all that paid off, I'm sure it doesn't mean we will always follow bleeding edge that much...it just happened to work out well this time
[20:09] <BenC> I think we will continue to have an ubuntu-next tree regardless though
[20:10] <BenC> Laney: QUESTION: What made you decide to switch to .27?
[20:10] <BenC> The team reviewed a lot of the infrastructure that was going into .27, which would satisfy a lot of hardware support we were aiming for, and additionally fix a lot of issues we were having
[20:11] <BenC> Most notable in suspend/resume area, and wireless support
[20:11] <BenC> I don't think we have any regrets on the decision, but it was a little scary having something so new being pushed for release :)
[20:12] <BenC> It does mean that if jaunty follows past cycles, it will be .28, but we haven't decided that quite yet (UDS topic)
[20:13] <BenC> One other thing we did in Intrepid was to remove all support for ports from our main tree
[20:14] <BenC> While this helped us immensely for our main support, it is definite that it also hurt ports such as sparc and powerpc
[20:14] <BenC> The kernel wasn't as consistent as it had been in the past
[20:14] <BenC> We will be reviewing this at UDS and decide if certain ports (namely sparc and powerpc) can be added back to our main tree
[20:15] <BenC> QUESTION: <persia> Is there a plan to change the architecture sets for Jaunty?  Currently there seems to be one kernel for i386/amd64, another for lpia, and yet another for everything else.
[20:16] <BenC> first off, lpia is a special case...it's been tossed around between the Ubuntu Mobile folks and kernel team, and I think settling this down will be of major concern next cycle.
[20:16] <BenC> I don't know enough about the criteria for this kernel to comment well
[20:17] <BenC> But as I just said, some of the ports may find themselves back in the main tree
[20:17] <BenC> It's worth pointing out that each architecture has it's own set of criteria, and sometimes these clash enough to force a split in development methods
[20:18] <BenC> We strongly encourage community to help, especially with the ports
[20:19] <BenC> Any other questions on this before I move on?
[20:19] <jcastro>  < Laney> QUESTION: What made you decide to switch to .27?
[20:20] <BenC> jcastro: Already pasted and answered :)
[20:20] <jcastro> oops, my bad
[20:20] <BenC> hehe, np
[20:20] <BenC> Another major change in the kernel development was how we organized third-party modules
[20:21] <BenC> A lot of what used to be in linux-ubuntu-modules has moved back to the kernel tree under the ubuntu/ subdirectory
[20:21] <BenC> The reason was consistency in source maint. The split was not giving us any benefit
[20:21] <BenC> Yet another change was linux-restricted-modules
[20:22] <BenC> Most of this was split out into dkms style packages for nvidia and fglrx
[20:22] <BenC> We are trying to encourage more use of dkms, especially in restricted modules
[20:23] <BenC> The reason is that it allows better support for custom kernels (e.g. -rt)
[20:23] <BenC> QUESTION: <marrow> Why was it necessary to take these into the kernel? What are the benefits?
[20:23] <BenC> Easier to maintain, and easier to track ABI, plus module conflicts
[20:24] <BenC> being built with the kernel retains a lot of the sanity checking that we already have in the kernel build, some which can only be done at build time with the kernel
[20:24] <BenC> Means we don't have to worry about actual changes in the ABI of these third-party modules, since it will be controlled by the kernel ABI as a whole
[20:25] <BenC> Before, if linux-ubuntu-modules changed ABI, first off, it would not be noticed or tracked
[20:25] <BenC> Secondly, it required us to export headers, sometimes conflicting with the kernel headers, for user installed modules to be able to use
[20:27] <BenC> Jaunty is going to see some continued changes in this area, attempting to build on the experience gained thus far
[20:28] <BenC> One thing I know is that we will be doing a rework of our firmware packaging, which showed up last minute as linux-firmware in intrepid
[20:31] <BenC> Ok, so sebner asked what linux-backports-modules was about, and I can answer that quickly
[20:32] <BenC> It's a package that allows us to introduce new or updated drivers without forcing existing users to install what may be a regression or not very well tested driver
[20:33] <BenC> This package isn't installed by default, and is generally installed by people experiencing a known problem that we have attempted to fix with an updated version of the driver
[20:34] <BenC> QUESTION: <johanbr> In the past, it has happened that patches not yet included upstream have been dropped by mistake when the kernel is rebased for the next Ubuntu release, thus causing regressions. Is there a procedure in place to minimize these occurrences?
[20:35] <BenC> Unfortunately, this is a manual and error prone procedure
[20:35] <BenC> Usually these patches get dropped because they either fail to apply cleanly, or fail to compile cleanly
[20:35] <BenC> The person doing this rebase is expected to retain a list of such patches in an effort to reintroduce them later
[20:36] <BenC> I've been responsible for dropping the ball on this, so I'm definitely not pointing fingers :)
[20:36] <BenC> That's a good topic for UDS I believe
[20:36] <BenC> I don't have any good suggestions off-hand
[20:37] <BenC> QUESTION: <sebner> A goal for jaunty is faster boot time. Did you decide that before knowing this 5 seconds boot thing? Also how many seconds do you think will the 28er kernel be faster? Or do you plan further work on init/xorg? How many seconds to you plan to be faster than intrepid? I hope it's not too early to answer this question
[20:37] <BenC> Boot time is one of the top priorities for jaunty
[20:38] <BenC> While a lot of this can be handled in the kernel, a good portion of boot time is unrelated to the kernel itself
[20:39] <BenC> Compiling in some modules, and reducing the amount of time spent loading and initializing modules is one of the biggest factors I've been informed of so far
[20:40] <BenC> The exact numbers we want to meet are held by others in the ubuntu dev team. How much we have to reduce it by and where these precious seconds will come from, is a system wide issue
[20:40] <BenC> The kernel team will definitely do it's part though
[20:41] <BenC> The first two parts of your question I cannot answer
[20:41] <BenC> (because I don't know)
[20:41] <BenC> QUESTION: <gQuigs> How about Kernel Mode Setting for Jaunty?
[20:42] <BenC> We review all new features in the kernel for whether they will benefit us...kernel-mode-setting is one of them
[20:42] <BenC> Since it requires some close synchronization with Xorg, it will require more decision making and information that I can provide
[20:43] <BenC> It is something we want, is the short answer
[20:43] <BenC> I believe we looked at it for jaunty, but it was still just too unstable for us (required a lot of bleeding edge stuff for Xorg)
[20:44] <BenC> s/jaunty/intrepid/
[20:44] <BenC> QUESTION: <gQuigs> what kernel is alpha 1 going to come with, ubuntu-next?
[20:45] <BenC> ubuntu-next isn't a kernel version, we will be tracking 2.6.28-rc in jaunty, and hope that it will make Alpha 1
[20:45] <BenC> ubuntu-next is what we use to continue tracking upstream kernel after we have settled on a stable point release
[20:45] <BenC> it isn't meant for uploading
[20:46] <BenC> QUESTION: <sebner> What I've read so far is that jaunty will have .28 if not something important leads to 29er. right?
[20:46] <BenC> That's correct. Our normal development cycle would put us at .28, but that has yet to be decided for sure
[20:47] <BenC> QUESTION: <Yasumoto> It seems like a lot of cool features (Kernel Mode Setting, faster boot) may require either bleeding-edge upstream stuff or even some work on our end to get it working right. Is there a general feel for how to deal with this balance of new features vs. stability?
[20:47] <BenC> First off, faster boot doesn't require anything bleeding edge...just some detailed review of the boot process and looking at alternatives to the main problem points
[20:48] <BenC> Things like kernel-mode-setting, we generally lean toward stability, especially in a feature that is very limited on who benefits, very superficial in the benefit, and very difficult to maintain for 18 months
[20:50] <BenC> QUESTION: <sebner> This faster boot thing is really popular now. As you just said mostly it's not magic but "some detailed review of the boot process and looking at alternatives to the main problem points". Why do you think wasn't this make earlier. months, years ago?
[20:51] <BenC> I believe boot time has always been watched...the only thing that seems to have changed was the bar we want to reach for how long is too long
[20:51] <BenC> Checkout bootchart, and searching google/wiki you will find that it's been used for quite a few years
[20:52] <BenC> Ok, looks like I have time for one or two more questions is all
[20:54] <BenC> QUESTION: <sebner> How many dev's work currently on the kernel in ubuntu?
[20:55] <BenC> As with many community oriented projects, it's hard to put a number on some of these things :)
[20:55] <BenC> I can tell you that Canonical employs 6 kernel devs now, most of which are dedicated to the dev and stable releases
[20:55] <sebner> BenC: canoncial guys? .. to make it easier :)
[20:55] <sebner> heh
[20:56] <BenC> I would guess at least that many community folks are out there, and several times as many from vendors interested in Ubuntu's kernel
[20:57] <BenC> e.g. AMD, Intel, nVidia, etc...
[20:57] <BenC> Last question...
[20:57] <BenC> QUESTION: <pwnguin> how far in the future before btrfs is default?
[20:57] <sebner> BenC: mine is last :P
[20:58] <BenC> I only have two minutes :)
[20:58] <BenC> pwnguin: My crystal ball is in the shop at the moment...
[20:58] <BenC> sebner: "maybe"
[20:58] <sebner> BenC: 50-50?
[20:58] <BenC> I would say 40-40
[20:59] <sebner> and 20% are?
[20:59] <BenC> with 20% going to the off chance ext5 comes out, or reiser is set free
[20:59] <sebner> heh
[21:00] <BenC> sebner: Honestly I don't know, but we will bring it up at UDS I'm sure
[21:00] <pwnguin> 1 in 5 chance. very generous
[21:00] <jcastro> ok, that's about it for time
[21:00] <BenC> pwnguin: I was being generous to ext5 :)
[21:00] <jcastro> thanks Ben and thanks to everyone for participating
[21:00] <BenC> Thanks everyone!
[21:00]  * sebner hugs BenC. Thx for answering all the questions 
[21:00] <jcastro> ok, one last session for openweek
[21:01] <jcastro> after this there won't be any more planned sessions in here
[21:01] <jcastro> of course you can hang out after the session
[21:01] <jcastro> as always please feel free to mail me comments, jorge@ubuntu.com
[21:02] <jcastro> DougieRichardson: ok take it away!
[21:02] <DougieRichardson> Hi all
[21:02] <DougieRichardson> I'm here to discuss contributing to Ubuntu's documentation
[21:03] <DougieRichardson> The first link you need to get started is https://wiki.ubuntu.com/DocumentationTeam
[21:04] <DougieRichardson> Documentation is split into two main areas - system help and online help
[21:05] <DougieRichardson> System help is written in DocBook XML and packaged with each release.
[21:05] <DougieRichardson> Online help, again is split into two areas: help.ubuntu.com which is built from the system documentation
[21:06] <DougieRichardson> and help.ubuntu.com/community which is where the community contributed wiki docs are
[21:06] <DougieRichardson> So how do you start conributing?
[21:07] <DougieRichardson> The easiest place to start is by proof reading. Checking through the system documentation and picking up on errors.
[21:08] <DougieRichardson> The team itself is split into two groups - committing members and students.
[21:09] <DougieRichardson> the only difference being that committing members push patches into the current branch.
[21:10] <DougieRichardson> As a student, you are assigned a mentor to guide you.
[21:11] <DougieRichardson> The current source can be downloaded from Launchpad
[21:11] <DougieRichardson> using bzr
[21:12] <DougieRichardson> https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Repository
[21:14] <DougieRichardson> Once you have a copy of the docs, the best place to get started is by looking for bugs listed on launchpad
[21:14] <DougieRichardson> There are two places to look: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs for bugs reported against the package
[21:15] <DougieRichardson> And https://bugs.launchpad.net/ubuntu-doc for the team
[21:15] <DougieRichardson> So lets talk through a typical bug, by following https://bugs.launchpad.net/ubuntu-doc
[21:16] <DougieRichardson> From the filter panel, we click "new"
[21:17] <DougieRichardson> Lets look at the techreview bug 235079
[21:18] <DougieRichardson> Here we have a list of corrections that someone has spotted, so we can go right ahead and start correcting them.
[21:19] <DougieRichardson> The first issue is to find out which file you need to edit - so open a file browser window and navigate to the ubuntu-docs folder
[21:20] <DougieRichardson> This case is apparent - its in programing
[21:20] <DougieRichardson> All folders will have two sub-folders, PO and C
[21:20] <DougieRichardson> PO is for translation, so we need to be in C
[21:21] <DougieRichardson> Now we can edit the programming.xml file by opening it, looking for the error and amending it.
[21:21] <DougieRichardson> So now we have a corrected version locally, we need to submit it to the team.
[21:22] <DougieRichardson> First though we will check that they are valid and will not break the package.
[21:23] <DougieRichardson> From the ubuntu-doc folder, run scripts/validate.sh index.xml
[21:23] <DougieRichardson> We need to run it on the root because otherwise it will pick up errors from linked files.
[21:23] <DougieRichardson> OK so it validates, now we create a patch to submit.
[21:24] <DougieRichardson> This involves just two commands:
[21:25] <DougieRichardson> bzr commit -m "Describe the change, include a bug number"
[21:25] <DougieRichardson> bzr bundle > diffname.txt
[21:26] <DougieRichardson> Or, if its just a small patch then bzr diff > patch.txt will do
[21:26] <DougieRichardson> Add a comment to the original bug attaching your patch and you've fixed your first bug.
[21:27] <DougieRichardson> So that brings us on to the second area we work on - the community docs.
[21:27] <DougieRichardson> As long as you have a Launchpad account, you can add and edit community documentation
[21:28] <DougieRichardson> http://www.ubuntu.com/community
[21:28] <DougieRichardson> Sorry - http://help.ubuntu.com/community
[21:29] <DougieRichardson> The best way to approach assisting on the wiki is to look up subjects you are familiar with.
[21:29] <DougieRichardson> If there is already a page, then you can proof read it for errors and improve it.
[21:29] <DougieRichardson> Otherwise you can create a page.
[21:30] <DougieRichardson> We just ask that you read the first page and follow the guide.
[21:30] <DougieRichardson> Both types of documentation are under a creative commons licence
[21:31] <DougieRichardson> Well that about covers it, so we'll move on to questions now. Remember that the largest problem that we have as a team is getting enough contributers. This is especially true for the wiki where we would love to get all the fantastic community howtos that are out there centralised.
[21:32] <DougieRichardson> So, lets take questions now.
[21:35] <DougieRichardson> OK, what are the main areas that still need work?
[21:35] <DougieRichardson> For the community docs, we would like to import as much from the forums as possible.
[21:36] <DougieRichardson> This requires that we get the permission of the original writer.
[21:36] <DougieRichardson> So if you see a great guide, nudge the writer to submit it to the team.
[21:37] <ssole> how do you manage translations?
[21:37] <DougieRichardson> Our mailing list is here: https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc
[21:37] <DougieRichardson> Translations are managed by Matthew East
[21:38] <DougieRichardson> The best place to start is https://wiki.ubuntu.com/DocumentationTeam/Translation
[21:38] <DougieRichardson> We use Rosetta
[21:39] <DougieRichardson> About two or three weeks before release, we eter string freeze.
[21:39] <DougieRichardson> Then the translators have a chance to translate all the changed strings for release.
[21:40] <DougieRichardson> I have to go in a few minutes, so I'd like to wrap up here.
[21:40] <DougieRichardson> Are there any more questions?
[21:41] <DougieRichardson> OK, The main link to remember is https://wiki.ubuntu.com/DocumentationTeam
[21:42] <DougieRichardson> If you can contribute any time or docs to us, or recommend any for us to follow up - its greatly appreciated.
[21:42] <DougieRichardson> Thanks for your time and I'l hand back over to jcastro now
[21:42] <jcastro> thanks everyone!
[21:42] <jcastro> see you next time!
[21:42] <knome> \o/
[21:43] <knome>  |
[21:43] <knome> /'\
[21:44] <james_w> nice work jcastro
[21:44] <knome> definitely.
[21:44] <knome> i wish i had more time to take part on the conversations.
[21:46] <charlie-tca> great job this week, jcastro
[21:50] <snap-l> Awesome job, jcastro