[00:49] <deathmask> ez
[01:59] <j-noise> hi
[01:59] <j-noise> any on can pls tell me where to start contributing to ubu
[01:59] <j-noise> I m not an expert programmer .
[02:02] <ecubuntu> hi j-noise
[02:03] <ecubuntu> you can start from here: https://bugs.launchpad.net
[02:05] <MattJ> j-noise: http://www.ubuntu.com/community/participate
[06:10] <[Green]> hi all
[06:12] <nickishappy> hello
[06:13] <jaredbuck> no more classes until tomorrow morning. i can't wait. LOL.
[07:08] <Motor> Hello all
[07:39] <libregeek> I am using Malayalam(Indian language) in ubuntu-8.04 desktop and noticed that the malayalam words are rendered incorrectly.
[08:08] <Lynoure> libregeek: you could report a bug on Launchpad, or ask for help on #ubuntu
[10:02] <[chronos]> QUESTION: Can i play doom3 on ubuntu?
[10:02] <[chronos]> i have windows version
[10:02] <karmelek> wine?
[10:03] <[chronos]> wine?/
[10:04] <[chronos]> what about it ?
 this is not a support channel, may you could ask in #ubuntu
[11:05] <afa> join #ubuntu-classroom-chat
[13:16] <suff0beast> at what timezone is the class schedule?
[13:17] <ubuntu_demon> suff0beast: UTC
[13:17] <Waistless> http://www.worldtimeserver.com/current_time_in_UTC.aspx
[13:18] <Waistless> lucky me, it starts at 2.00am in australia :(
[13:20] <ububtero> Packaging 101 starts in 2h and 40 minutes, correct?
[13:22] <suff0beast> ok that would be 8pm in Baghdad
[13:22] <suff0beast> cool
[14:03] <asfiuyerjj> still 2 hr to start ??
[14:03] <asfiuyerjj> what is the exact time .. ?
[14:10] <SanjayB> 1:50 to start now, i believe, yes .
[14:55] <soyyo> hi
[14:55] <CLEARviewF> hi
[14:55] <CLEARviewF> good morning
[14:55] <CLEARviewF> from peru
[14:55] <soyyo> good afternoon
[14:56] <soyyo> from spain xDD
[14:56] <CLEARviewF> jeje
[14:56] <CLEARviewF> Eres tú?
[14:56] <CLEARviewF> :D
[14:56] <soyyo> si
[14:56] <CLEARviewF> jaja
[14:56] <hax> 4 o'clock in germany
[14:57] <CLEARviewF> 9am in Peru
[14:57] <stepler> good evening from russia )
[14:57] <soyyo> hax germany = spain
[14:57] <CLEARviewF> Tusday April 29th 9am Peru
[14:57] <SilverOwl> 9:57 in USA
[14:58] <CLEARviewF> east time SilverOwl
[14:58] <CLEARviewF> DC time
[14:58] <soyyo> wow many countries
[14:58] <lunitik> Anyone know what that is UTC? First session in a couple mins right?
[14:59] <valemon> good afternoon from Greece
[14:59] <CLEARviewF> Universal Time Coordinated, lunitik
[14:59] <raven2223> @lunitik http://www.worldtimeserver.com/current_time_in_UTC.aspx
[15:00] <lunitik> CLEARviewF: I know what it is... I was asking what time it is now in UTC
[15:00] <lunitik> raven2223: thank you
[15:00] <soyyo> http://en.wikipedia.org/wiki/Coordinated_Universal_Time
[15:00] <kain> you can do date -u in your terminal
[15:00] <CLEARviewF> lunitik: 2pm at UTC i think so
[15:00] <soyyo> at this moment is 15:00 UTC
[15:00] <PriceChild> @now
[15:00] <lunitik> +m ?
[15:01] <Lardarse> PriceChild: the bots aren't running
[15:01] <PriceChild> it is 15 utc now right?
[15:01] <PriceChild> Lardarse: i know, forgot :)
[15:01] <Lardarse> aand no, it's only 14:00
[15:01] <CLEARviewF> :D
[15:01] <PriceChild> whoops
[15:01]  * PriceChild thwacks tricksy BST
[15:01] <Lardarse> the UK is at UTC +1 right now, which might be confusing you :-)
[15:01] <doff> 6.01 pm in Moscow
[15:02] <lunitik> How technical is the first packaging session going to be?
[15:03] <doff> I think you should have such links with time of every event http://www.timeanddate.com/worldclock/fixedtime.html?day=29&month=04&year=2008&hour=14&min=00&sec=0&p1=179
[15:03] <lunitik> kain: btw, thank you for that command, I probably should have read date()'s man page  :P
[15:04] <kain> lunitik np
[15:14] <Symbios> devolopers speack russian?
[15:16] <ScottK> Symbios: Try #ubuntu-ru
[15:18] <polyakstar> Ё
[15:42] <CLEARviewF> 15 minutes left for the class to begin?
[15:43] <dholbach> yep :)
[15:43] <CLEARviewF> nice!
[15:43] <CLEARviewF> thank you, dholbach
[15:43] <Pat_from_TLLTS> pretty good crowd so far
[15:43] <nand> btw, "Packaging 101", why "101"?
[15:44] <Chrysalis> what was the command to get rid of all join, parts etc
[15:44] <itnet7> introductory packaging ?
[15:45] <toobuntu> see https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn, it's /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[15:46] <Chrysalis> toobuntu: thank you
[15:46] <toobuntu> np
[15:51] <lunitik> Chrysalis: You can also just right click the tab and uncheck 'Show Join/Parts'
[15:58] <eragon> Hi
[15:58] <Scrounch_> Irc's students
[15:58] <LjL> !question-#ubuntu-classroom is <reply> Please ask your questions in #ubuntu-classroom-chat (type /join #ubuntu-classroom-chat).
[15:58] <Ubotwo> But question-#ubuntu-classroom already means something else!
[15:58] <LjL> !question-#ubuntu-classroom
[15:58] <Ubotwo> Please ask your questions here in #ubuntu-classroom-chat rather than #ubuntu-classroom (prefix them with "QUESTION: " or the instructor's nickname)
[16:00] <dholbach> Welcome everybody to the first of today's Ubuntu Open Week Sessions!
[16:00] <josc>  /ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[16:00] <LjL> Please ask your questions in #ubuntu-classroom-chat (type /join #ubuntu-classroom-chat), and prefix them with "QUESTION:"
[16:00] <dholbach> Can we make it so that you either reply to questions for feedback or ask your own questions in #ubuntu-classroom-chat?
[16:01] <LjL> IRC commands start with / without any leading space
[16:01] <immesys> Please can we +m this room?
[16:01] <SanjayB> ﻿/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
[16:01] <SanjayB> oops. sorry.
[16:01] <dholbach> We're going to go through a few tutorials together and I'll check back on how things are going every now and then - please speak up in #ubuntu-classroom-chat if that's OK :)
[16:02] <dholbach> So how are you all doing? How were yesterday's Ubuntu Open Week sessions?
[16:02] <dholbach> OK, let's get cracking
[16:03] <dholbach> in our first tutorial we're going to package a small piece of software - for that to work out we need to install a few tools first
[16:03] <dholbach> Which version of Ubuntu are you running?
[16:03] <dholbach> Anybody running Intrepid already? ;-)
[16:04] <dholbach> lots of Hardy users - excellent
[16:04] <dholbach> the tutorials should work on all the mentioned Ubuntu versions - if things should go wrong though, please speak up in #ubuntu-classroom-chat
[16:04] <dholbach> Please install the following packages:
[16:04] <dholbach>   sudo apt-get install devscripts build-essential wget fakeroot dh-make
[16:05] <dholbach> So we're going to package ed, the gnu line editor - first we'll download the tarball from the gnu ftp page
[16:06] <dholbach>  wget ftp://ftp.gnu.org/pub/gnu/ed/ed-0.9.tar.bz2
[16:06] <dholbach> The Debian and Ubuntu build-system expects us to upload .tar.gz tarballs afterwards, but as the upstream authors don't offer tar.gz, we will have to repack the tarball
[16:06] <dholbach>  tar xfj ed-0.9.tar.bz2
[16:06] <dholbach>  tar cfz ed_0.9.orig.tar.gz ed-0.9
[16:07] <dholbach> it's also important to note that we have to stick to this kind of nomenclature: ed_0.9.orig.tar.gz
[16:07] <dholbach> <upstream software name>_<upstream version>.orig.tar.gz
[16:08] <dholbach> and the 'orig' in the name is there for a reason: we don't introduce any changes, we keep the source as it is
[16:08] <dholbach> (there are a very very few exceptions to that - for example cases where we can't ship certain parts of the source code due to licensing problems, etc)
[16:09] <dholbach> did that work out for everybody up until now?
[16:09] <dholbach> excellent
[16:10] <dholbach> next we're going to use a utility called dh-make which will provide us with default values and default files for the packaging which will make our lives a lot easier
[16:10] <dholbach>  cd ed-0.9
[16:10] <dholbach>  dh_make -s -c gpl
[16:11] <dholbach> we told dh_make that we're packaging a single binary package (-s) and that the copyright is GPL
[16:11] <dholbach> So what does single binary package mean?
[16:13] <dholbach> As a package maintainer and developer you only work on the source of package, this involves the tarball (our .orig.tar.gz) plus some patches to make it build the debian/ubuntu way (we'll come to that in a bit)
[16:13] <dholbach> We upload this "source package" to the build daemon which will then generate the .deb files (binary packages) that we, our friends and our mothers will download and install
[16:14] <dholbach> from one source package we can generate multiple binary packages (at least one though)
[16:14] <dholbach> this is a simple example :)
[16:14] <dholbach> mono is a good example for how you can split up one source package into multiple binary packages:
[16:14] <dholbach>  apt-cache showsrc mono | grep Binary
[16:15] <dholbach> this lists some ~80 binary packages which are all built from one source package
[16:15] <dholbach> LjL: do we have questions already? :)
[16:15] <LjL> dholbach, i think the couple we had were answered already in the chat channel
[16:16] <LjL> [17:15:51] <czambran> QUESTIONS : Why would you break once source package into multiple binary packages?
[16:16] <dholbach> czambran: a very good question
[16:16] <dholbach> there are multiple reasons
[16:16] <dholbach> the most obvious one is: because some user groups have a different interest than others
[16:16] <dholbach> take a library package for example
[16:17] <dholbach> my mother will be only interested in the library runtime
[16:17] <dholbach> I might be interested in developing with the library, so I might need all the header files in /usr/include
[16:17] <dholbach> the same goes for huge directories of documentation, etc
[16:17] <dholbach> it saves space on the disk (and CDs!), bandwidth, etc
[16:17] <dholbach> another question I saw was this one:
 QUESTION: How to change e-mail showed after executing  dh_make -s -c gpl
[16:18] <dholbach> RoAkSoAx: thanks a lot for prodding me about it - it's something I forgot and should have said earlier
[16:18] <dholbach> dh_make (and other packaging tools) can use an environment variable we should probably set before to make things easier
[16:19] <dholbach> please edit your   ~/.bashrc   file (or .zshrc if you use zsh) and add something along the lines of:
[16:19] <dholbach>  export DEBFULLNAME='Daniel Holbach'
[16:19] <dholbach>  export DEBEMAIL='daniel.holbach@ubuntu.com'
[16:19] <dholbach> then save it and please run
[16:20] <dholbach>  source .bashrc        (or restart your terminal)
[16:20] <LjL> [17:17:39] <Syntux> QUESTION: What if the source included the application dependent libraries; do we have to include them in the package ?
[16:21] <dholbach> Syntux: good question - in that case it's definitely worth to tallk to the upstream developers and ask them to ship just their own source in their tarballs
[16:21] <dholbach> unfortunately some (but not too many) upstream authors think that it would make their users live easier if they shipped all kinds of source code in their tarballs
[16:22] <dholbach> the ubuntu archive admins can get a bit shirty with you because of that for a simple reason: duplicated code
[16:22] <dholbach> we really like to have all code just in one place, so if there's a critical fix (like a security problem) we only need to fix it in one place
[16:22] <LjL> perhaps it's also worth pointing this one out although it was answered, as there could be some confusion due to most packages having source that needs to be compiled: <phil_> QUESTION:  What about programs that don't need compiling, like written python?
[16:22] <dholbach> did everybody update their  ~/.bashrc ?
[16:24] <dholbach> phil_: we use one build process for all kinds of packages, so no matter if it's C, Mono, Java, Python, Perl or just a bunch of .png files you want to ship to your users: all use the same build process and all install the files that are shipped to the user during that build process
[16:24] <dholbach> after the  ~/.bashrc  change, please run:
[16:24] <dholbach>  rm -r debian; dh_make -s -c gpl
 QUESTION: AFAIK, Debian and Ubuntu are not fully compatible anymore. Can I make sure a built package works on both?
[16:25] <dholbach> memnon: you can have a debian chroot where you can test the build, if it works in debian (https://wiki.ubuntu.com/DebootstrapChroot) or use pbuilder (https://wiki.ubuntu.com/PbuilderHowto)
[16:26] <dholbach> alright.... let's crack on
[16:26] <dholbach> we just generated the defaults again, after we set DEBFULLNAME and DEBEMAIL - things should look a bit better now :)
[16:26] <dholbach> let's see what dh_make generated for us:
[16:26] <dholbach>  cd debian/
[16:27] <dholbach>  ls
[16:27] <dholbach> you can see a lot of files, lots of them have a very special purpose only and it's just too much to cover in this session
[16:27] <dholbach> http://wiki.ubuntu.com/PackagingGuide has a lot of useful information and lots of links to docs you will need to make use of the advanced features
[16:28] <dholbach> our package is going to be very simple and very straightforward, that's why we're going to remove a lot of example files now
[16:28] <dholbach>  rm *.ex *.EX dirs docs README.Debian
[16:28] <dholbach> changelog  compat  control  copyright  info  rules          should be it now
[16:29] <dholbach> let's edit the changelog first
[16:29] <dholbach> every change in Ubuntu and Debian has to be properly documented
[16:29] <dholbach> if you want to figure out why something broke or behaves differently you usually check the changelog first
[16:30] <dholbach> and because people are going to use your package and you collaborate with a lot of people on it you do them a favor and let them know very explicitly what you do :)
[16:30] <dholbach> the first changelog entry is not very exciting though: something like "Initial release" should be enough
[16:30] <dholbach> it might also be worth pointing out that we re-packed the tarball (without changes)
 QUESTION: Does this chagelog just contain package-related changes or source code related changes?
[16:31] <dholbach> Zelut: good question
[16:31] <dholbach> Zelut: some maintainers like to point out major changes that a new upstream version introduced, but there's no strict must
[16:32] <dholbach> if you'Re on hardy, check out:
[16:32] <dholbach>  zless /usr/share/doc/gedit/changelog.Debian.gz
[16:32] <dholbach> you can see that seb128 explained what the new upstream version gained us
[16:32] <dholbach> but let's crack on - let's make the changelog ubuntu compliant :)
[16:32] <dholbach> our changelog.... :)
[16:33] <dholbach> first we'll change the version number to 0.9-0ubuntu1
[16:33] <dholbach> the version number has the following format:
[16:33] <dholbach>  - packages that have no ubuntu changes:    <upstream version>-<debian revision>
[16:34] <dholbach>  - packages that HAVE   ubuntu changes:    <upstream version>-<debian revision>ubuntu<ubuntu revision>
[16:34] <dholbach> as our own package never was in debian, <debian revision> will be "0" in our case
[16:34] <dholbach> hence 0.9-0ubuntu1
[16:35] <dholbach> we'll also change 'unstable' (the debian default) to 'intrepid'
[16:35] <dholbach> why?
[16:35] <dholbach> because intrepid is the current development release and we can only upload to the current development release
[16:35] <dholbach> (hardy-updates, hardy-security, hardy-backports, etc are exceptions)
[16:35] <dholbach> we'll not change the urgency as it has no effect in the ubuntu build system
[16:36] <dholbach> the "changelog part" of the entry should be something like
[16:36] <dholbach>   * Initial release.
[16:36] <dholbach>   * Re-packed from .tar.bz2 (no changes).
[16:37] <dholbach> can you post your changelog entry to http://paste.ubuntu.com/ and post the link in #ubuntu-classroom-chat if you made it?
[16:38] <dholbach> mfm: good work
[16:38] <dholbach> lmontrie: that looks good
 QUESTION: Do we have to stick to certain text format in changelog? tabs/spaces ?
[16:39] <dholbach> Syntux: if you use an editor like 'vi' it will let you know about syntax problems in debian/changelog - also the packaging tools we're going to use to build the packages will complain
 QUESTION: when packaging or merging for the current development release... in this case, should be do it using Intrepid or we can do it on hardy. How, using a pbuilder
[16:40] <dholbach> RoAkSoAx: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases is the answer
[16:40] <dholbach> there are lots of ways in which you can use the development release - it's important that you're able to
[16:40] <dholbach>  - test build your package
[16:40] <dholbach>  - test your package
[16:40] <dholbach> in the release that you're going to upload to
 QUESTION: Should we package restricted content such as graphics drivers too? Or should we stick to Debian packages?
[16:41] <dholbach> Syntux: yours looks good too, although I'd personally add a newline below the last bullet point (but yours is OK)
[16:42] <dholbach> immesys: there are restrictions on what we're allowed to ship in Ubuntu - it has to be redistributable - there's a wiki page which explains that but I don't have the URL handy right now - can somebody give it to immesys?
[16:42] <dholbach> so we have the changelog sorted out, let's crack on
[16:44] <dholbach> we'll skip the files compat (defines debhelper compatibility level - check out debhelper(7) for more info) and info (info page for the ed package) as they should be OK as they are
[16:44] <LjL> dholbach: it might be http://www.ubuntu.com/community/ubuntustory/licensing that you wanted to point immesys to
[16:44] <dholbach> LjL: thanks - that looks like a good start
[16:45] <dholbach> a lot of important information is available from http://wiki.ubuntu.com/UbuntuDevelopment too (how the archive works, ubuntu policies, etc)
[16:45] <dholbach> let's edit the  control  file now
[16:45] <dholbach> it carries the important information about binary and source packages I talked about earlier
[16:46] <dholbach> it consists of a source stanza (always the first in the file) and one or multiple binary stanzas
[16:46] <dholbach> we'll only make minimal changes to it right now
[16:47] <dholbach>  Section: editors              should be fine
[16:47] <dholbach> one important field in the source section is "Build-Depends"
 QUESTION: Is there a list of possible 'section's that can be referred to?
[16:48] <dholbach> it means: installing these packages into a minimal system will suffice to make it built
[16:48] <dholbach> Zelut: http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[16:50] <dholbach> what happens if we upload our source package to a build machine is: use a fresh minimal environment, then install the build-depends
[16:51] <dholbach> in our case we'll stick to the defaults as ed doesn't need a lot of build-dependencies (just libc6-dev, which is always installed by means of 'build-essential')
[16:51] <dholbach> if you package a C or C++ piece of software it's usually worth reading configure.ac or configure.in to find out what the build-dependencies are
[16:51] <dholbach> also the README file is a good source for that
[16:52] <dholbach> the pbuilder tool I referred to earlier does the same as the build machines in the data centre: it uses a fresh minimal environment, then installs the build-depends, then build your package
[16:52] <dholbach> http://wiki.ubuntu.com/PbuilderHowto if you want to try it out
 QUESTION: So do I have to add libc6-dev to my Build-Depends?
[16:53] <dholbach> mfm: no, build-essential is always installed and get libc6-dev for you
[16:53] <dholbach> other than that the source stanza is looking quite good now
[16:54] <dholbach> the second stanza is about the binary package we install
[16:54] <dholbach> of couse we want a nice description, so adept and synaptic users know what "ed" is all about
[16:54] <dholbach> so let's get the description from the README file:
[16:55] <dholbach> Description: standard Unix line editor
[16:55] <dholbach>  GNU ed is an 8-bit clean, more or less POSIX-compliant implementation
[16:55] <dholbach>  of the standard Unix line editor. These days, full-screen editors have
[16:55] <dholbach>  rendered `ed' mostly of historical interest. Nonetheless, it appeals
[16:55] <dholbach>  to a handful of aging programmers who still believe that "Small is
[16:55] <dholbach>  Beautiful".
[16:55] <dholbach> is what I put in there
 QUESTION: What does the 'Standards-Version' field means ?
[16:56] <dholbach> the first line is the "short description", the subsequent lines (all indented by one space) are the long description
[16:56] <dholbach> lmontrie: good question - I omitted that
[16:56] <dholbach> Standards-Version refers to the version of the debian policy your package complies with
[16:56] <dholbach> if you type:
[16:56] <dholbach>  apt-cache show debian-policy | grep ^Version
[16:56] <dholbach> if will show which version of the debian policy is available on your system
[16:57] <dholbach> it's an important document that will in most of the cases have the answer to your question :)
[16:57] <dholbach>     Architecture: any     is important too
[16:57] <dholbach> it means that our package will be built on any of the architectures in the data centre
[16:58] <dholbach> which means: i386, amd64, powerpc, sparc, hppa, lpia, ia64, etc
[16:58] <dholbach> we compile C code in this package which is going to be architecture specific
[16:58] <dholbach> if you just happen to ship some perl scripts, you can change the field to
[16:58] <dholbach>     Architecture: all
[16:59] <dholbach>    Depends: ${shlibs:Depends}, ${misc:Depends}
[16:59] <dholbach> is the most daunting looking line - what is it about?
[16:59] <dholbach> ${shlibs:Depends} is a variable that will be substituted after the build
[17:00] <dholbach> it will contain all the library packages that contain libraries that the binaries in the ed package are linked to
[17:00] <dholbach> does that make sense? :)
[17:01] <Mez> Mixed opinion it seems dholbach.. An example maybe?
[17:02] <dholbach> OK, I just installed the existing ed package of the archive, if I run ldd on the /bin/ed binary, it gives me:
[17:02] <dholbach> daniel@lovegood:~/1$ ldd /bin/ed
[17:02] <dholbach> 	linux-gate.so.1 =>  (0xb7f9e000)
[17:02] <dholbach> 	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e3e000)
[17:02] <dholbach> 	/lib/ld-linux.so.2 (0xb7f9f000)
[17:02] <dholbach> daniel@lovegood:~/1$
[17:03] <dholbach> what it spits out is the libraries /bin/ed is linked against
[17:03] <dholbach> the build process will translate library file names into library packages and note them in the Depends: field afterwards
[17:04] <dholbach> never specify explicit library dependencies by hand
[17:04] <dholbach> this process is really elegant
[17:05] <dholbach> ${misc:Depends} is another substitution variable which is used in special cases like gnome (it will for example contain gconf if one of the packaging tools identifies gconf schemas are installed, etc)(
[17:05] <dholbach> ${misc:Depends} is empty most of the time
[17:05] <dholbach> debian/control should be all set now
[17:06] <dholbach> can you post your debian/control file to http://pastebin.com/ (or any other pastebin site that works) and post the link  in  #ubuntu-classroom-questions ?
[17:08] <dholbach> MattJ: looks good, PartyBoi2: could do with a bit of editing in the description - other than that good
[17:08] <Mez> dholbach, I think you mean #ubuntu-classroom-chat ?
[17:08] <dholbach> Zelut: good
[17:08] <dholbach> Mez: yes, sorry
[17:08] <dholbach> lmontrie: great
[17:09] <dholbach> kef_kf: looking good
[17:09] <dholbach> Syntux: one newline too much in the description - you'd at least need a " ." to split the text up a bit
[17:10] <dholbach> mfm: good
[17:10] <dholbach> czambran: make it one space instead of a tab - other than that good
[17:10] <dholbach> wow.... good work everybody :)
[17:11] <dholbach> the next file we're going to look at is really really important
[17:11] <dholbach> copyright
[17:11] <dholbach> it contains information about the authors, the copyright holder and license of each file that you're shipping
[17:12] <dholbach> the archive admins will make sure that debian/copyright is in tip-top state and that you've not left anything out and that all source is perfectly redistributable
[17:12] <dholbach> the more careful you are in making sure that it's alright, the happier they'll be with you - and you want them happy :)
[17:13] <dholbach> can you open another terminal, cd into the ed-0.9 directory and run:
[17:13] <dholbach>   find . -name '*.c' | xargs head | less
[17:14] <dholbach> this will display you the top lines of each .c file in the source
[17:14] <dholbach> please note that that's not enough to ensure that everything you ship is alright, but just illustrates what you look at and what you look for
[17:15] <dholbach> for now we'll just refer to:
[17:15] <dholbach>     Copyright (C) 1993, 1994 Andrew Moore, Talke Studio
[17:15] <dholbach>     Copyright (C) 2006, 2007, 2008 Antonio Diaz Diaz.
[17:15] <dholbach> as the copyright holders
[17:15] <dholbach> also please see the AUTHORS file
[17:15] <dholbach> we'll copy the authors from there into the   Upstream authors:   section in debian/copyright
[17:16] <dholbach> also you need to point out where you obtained the tarball from - pointing to    ftp://ftp.gnu.org/pub/gnu/ed/     should be good enough
[17:17] <dholbach> https://wiki.ubuntu.com/PackagingGuide/Howtos/DebianCopyright explains a bit more about it
[17:18] <dholbach> next let's take a quick look at debian/rules
[17:19] <dholbach> it's a Makefile which contains standard targets the debian/ubuntu build process expects
[17:21] <dholbach> it usually contains: build, binary, binary-arch, binary-indep, clean - if it confuses you right now, that's OK
[17:22] <dholbach> we'll leave debian/rules as it is for our example and I usually recommend to work on existing packages and modify existing bits to get a better feeling for the build process and which bits are called when
[17:22] <dholbach> what we'll do now is generate the source package from the changes we just did
[17:22] <dholbach> please run
[17:22] <dholbach>   debuild -S
[17:23] <dholbach> and see:
[17:23] <dholbach>  ls ../..
[17:23] <dholbach> you should have a .diff.gz and a .dsc file in addition to the .orig.tar.gz we created initially
 QUESTION: run dbuild from debian or ed-0.9?
[17:24] <dholbach> mfm: both should work
[17:25] <dholbach> .orig.tar.gz is the unmodified tarball
[17:25] <dholbach> .diff.gz is the compressed changes we had to make to make it build the ubuntu/debian way :)
[17:26] <dholbach> some of you got a GPG warning
[17:26] <dholbach> that does not indicate a failed build, but that you might need to set up GPG properly
[17:26] <dholbach> I didn't make this part of this tutorial to safe us a bit of time: https://help.ubuntu.com/community/GnuPrivacyGuardHowto is a very good guide to get you up and running
[17:27] <dholbach> the .dsc file is a description file that contains md5sums of .orig.tar.gz, the .diff.gz and the like - together they are what we call a source package
[17:28] <dholbach> ok... now that we have our source package all set - let's get us a binary package
[17:28] <dholbach> cd back into the ed-0.9 tree
[17:28] <dholbach> and run       debuild -us -uc            (this will run the build and omit the final step of signing the package)
 QUESTION: Is there a way to export GPG settings in a similar way we exported EMAIL and NAME?
[17:29] <dholbach> Zelut: the packaging tools will make use of the gpg key that has the key id that matches your DEBEMAIL
[17:29] <dholbach> at the end of our build lintian might emit a few warnings and errors: this is kind of things you will need to work out if you work on a real package and not a silly example as we do over here :)
[17:30] <dholbach> for now we can ignore them
[17:30] <dholbach> a    ls ../*.deb    should mention a package we just build
[17:30] <dholbach>  less ../ed_0.9-0ubuntu1_*.deb    should give you information about the package we just built
[17:30] <dholbach>  - contents
[17:31] <dholbach>  - package description
[17:31] <dholbach>  - version
[17:31] <dholbach> and note:
[17:31] <dholbach>  Depends: libc6 (>= 2.4)
[17:31] <dholbach> did that work out for everybody?
[17:33] <dholbach> excellent - a whole lot of succesfully built packages - congratulations everybody  :)
[17:33] <dholbach> do we have some questions? :)
 QUESTION: It shows "libc6 (>= 2.6-1)" for me - depends on the Release which it has been buid?
[17:34] <dholbach> mfm: yes, that depends on which release you built the package
 Okie, we got the package, whats the root pass to upload it :p
[17:34] <dholbach> Syntux: you need to have signed it with a gpg key that is registered on Launchpad for a user that is in the ~ubuntu-dev team
[17:35] <dholbach> the rest is here:   https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Uploading
[17:35] <dholbach> that's why following   https://help.ubuntu.com/community/GnuPrivacyGuardHowto   and reading it thoroughly is important :)
[17:36] <dholbach> other than that I recommend #ubuntu-motu on irc.freenode.net as a means of getting in touch with developers and asking questions regarding packages
[17:36] <dholbach> and ubuntu-motu-mentors@lists.ubuntu.com
[17:37] <dholbach> http://wiki.ubuntu.com/MOTU/GettingStarted is a good guide and links to all the important information
 QUESTION: If we've built a package that we want reviewed do we just annoy -motu or are there mentors we can ask?
[17:37] <dholbach> Zelut: https://wiki.ubuntu.com/MOTU/Packages/REVU explains how you can upload a package for review
[17:38] <dholbach> if you have specific questions you can always ask in #ubuntu-motu
[17:38] <dholbach> any more questions?
[17:39] <dholbach> who enjoyed their first ride through packaging? who wants more of it? :)
[17:40] <dholbach> https://wiki.ubuntu.com/PackagingGuide/HandsOn has some more tutorials you can go through on your own later
 QUESTION: this is PPA-related.  ive tried to upload the same .orig.gz before but with a different .diff.gz and a lower version number to upload for a different version (wanted to compile for gutsy and hardy), but it said the orig didn't match. What'd i do wrong there?
[17:40] <dholbach> for everybody who's not familiar with PPAs: please see http://help.launchpad.net/PPAQuickStart
[17:40] <dholbach> it's basically a build service for testing and sharing packages
[17:41] <dholbach> maco: a lower version number does not work out if it accepted a higher version number before - but that should have been explicit in the rejection mail
[17:42] <dholbach> best to ask in #launchpad or ask in the session later on at 19:00 UTC
 QUESTION: When a MOTU wannabe should apply to become part of the official team? do s/he have to be seriously fluent in packaging or there are another way of defining the expertise level.
[17:42] <dholbach> excellent question
[17:42] <dholbach> http://wiki.ubuntu.com/UbuntuDevelopers explains more about the actual process of applying
[17:42] <dholbach> so how does one become a MOTU?
[17:43] <dholbach> basically it boils down to: contribute, get good quality packages and patches uploaded by people who are in the ubuntu-dev team already (http://wiki.ubuntu.com/SponsorshipProcess)
[17:43] <dholbach> until they tell you: "hey you're doing great - why don't you apply for MOTU?"
[17:44] <dholbach> then you apply with a brief explanation of what you've done, what you want to do and your sponsors' feedback at the MOTU Council
[17:44] <dholbach> I generally recommend to work on existing packages and fix a few 'bitesize' bugs before starting to package random software
[17:44] <dholbach> it's better to start off small and get a feeling for the build process, for how packages work and so on
[17:45] <dholbach> https://wiki.ubuntu.com/MOTU/TODO should list a lot of tasks you can get cracking on
 QUESTION: Do you have an example copyright for ed you can show us?  We kinda breezed through that one quickly.
[17:45] <dholbach> Zelut: no, but I'll post one later
 QUESTION: What's the best way to find unpackaged applications that people need especially with the large repository of debian and Ubuntu it's really hard to find the kick start package.
[17:46] <dholbach> Syntux: as I said above: I *REALLY* recommend working on existing packages - in Ubuntu we maintain all the packages as a team
[17:46] <dholbach> of couse some people have more expertise with certain packages than others, but there's no "big maintainer lock" which prevents others from working on the same package or as a maintenance team
[17:47] <dholbach> so I'd rather start off with picking a bug, and getting a small piece of the puzzle to work again
[17:47] <dholbach> you can even do it as your http://wiki.ubuntu.com/5-A-Day :)
[17:48] <dholbach> but if you really want to package a piece of software that somebody else has good use for, try: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
[17:48] <dholbach> for that it's important to point out a few things:
[17:49] <dholbach>  - putting your name in the maintainer field means: you're going to take good care of it (read bug reports, talk to the upstream developers, take care of making it work as good as you can etc)
[17:49] <dholbach>  - that works best if you take care of a piece of software that you yourself have a good use for
[17:49] <dholbach> >RoAkSoAx> QUESTION: regarding to copyright question of Zelut , would it be like this?: http://pastebin.com/m6a7116d4
[17:50] <dholbach> the upper part looks quite OK already
[17:50] <dholbach> what's missing is the GPL3 text
[17:50] <dholbach> if you check out the top lines of the .c files you will notice that it mentions GPL3, not GPL2
[17:51] <dholbach> this makes a big difference and will be something the archive admins will complain about
[17:51] <dholbach> also we would have to make sure that
[17:51] <dholbach> #
[17:51] <dholbach>     Copyright (C) 1993, 1994 Andrew Moore, Talke Studio
[17:51] <dholbach> #
[17:51] <dholbach>     Copyright (C) 2006, 2007, 2008 Antonio Diaz Diaz.
[17:51] <dholbach> are the only copyright holders
[17:51] <dholbach> it'd require some more love
 QUESTION: If we write a peice of software that we want to submit for inclusion is it still the same REVU process?
[17:52] <dholbach> Zelut: yes, you will submit your new package to REVU, will let it get 2 ACKs, then it can be uploaded to the archive
[17:52] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages has more to say about that
[17:53] <dholbach> you'll get extra points for having a "good contact to the upstream author" though :)
[17:53] <dholbach> more questions?
 So it seems a MOTU works as a middle man between the upstream developers and Ubuntu repository, the scenario should be something like, picking a package (new or existing), follow up on bugs, patches, releases and put the result in a package
[17:53] <dholbach> Syntux: exactly
[17:54] <dholbach> and that's what makes it fun - you deal with a lot of people: your users, the debian maintainers, maintainers of other distributions, upstream developers etc
[17:54] <dholbach> and by making things work you'll make a lot of people very happy :)
[17:55] <dholbach> So who of you can we expect in #ubuntu-motu for making intrepid ROCK?
[17:56] <dholbach> excelltn :)
 QUESTION: how does making a debdiff differ from making a normal source deb?
[17:56] <dholbach> maco: if you post a source package for REVU you upload the full .orig.tar.gz .diff.gz and .dsc files somewhere
[17:57] <dholbach> in the case of a debdiff it's just a diff file with the changes you did in a fix upload for example
[17:57] <dholbach> Check out https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff for an example
[17:57] <dholbach> another important part of developing Ubuntu:
[17:57] <dholbach> Hugging!
[17:58]  * dholbach hugs y'all :)
[17:58] <dholbach> You all ROCK and I hope you had big fun in the session - because I did
[17:58] <dholbach> The next session is "Ubuntu Mobile Edition - An introduction and Q+A - Adilson Oliveira"
[17:59] <dholbach> please do send me a mail on how your doing regarding packaging and doing development
[17:59] <dholbach> you all rock!
[18:00] <dholbach> LjL, Mez: can you give agoliveira the power to speak? :)
[18:00]  * agoliveira waves all
[18:00] <dholbach> gracias
[18:00] <agoliveira> Thanks. Hello all, thanks for attending and for having me.
[18:01] <agoliveira> My name is Adilson Oliveira and I'm part of the core team developing UME.
[18:01] <agoliveira> My objective here is to explain a bit about the project and try to clear the doubts you may have.
[18:01] <agoliveira> I ask you to be forgiven as English is not my first language, it's my first time in this spot and I must say I'm kind of nervous right now :)
[18:01] <agoliveira> Ok, let's start with: what is UME?
[18:02] <agoliveira> - The Ubuntu Mobile and Embedded project aims to derive an operating system for mobile internet devices using Ubuntu as a base and the Moblin project from Intel as upstream to parts of the project, mostly hardware support.
[18:02] <agoliveira> - It's sponsored by Canonical and Intel.
[18:03] <agoliveira> - It's extending Ubuntu by providing infrastructure for mobile development.
[18:03] <agoliveira> ﻿All of the necessary components are being integrated into the Ubuntu package archive, ready to install and run, or to tailor for custom mobile applications.
[18:03] <agoliveira> - The project is focused on x86 processors, using architectures created by Intel's LPIA platform. http://www.intel.com/technology/systems/lpia/. In the future, different processors may be supported. ARM is one we have in mind.
[18:03] <agoliveira> and what isn't? (for those who never cared to look at the FAQ) :)
[18:04] <agoliveira> - A ready to run, consumer-type platform. UME is more a technology base than a product on itself. It's aimed to help developers and manufacturers to create a product.
[18:05] <agoliveira> - It is not for cellphones or PDAs. UME is created with MID and UMPC platforms. These are about communications (audio, video, IM), rich web experience, full-blown applications. They have more like a very small PC with touchscreen.
[18:05] <agoliveira> So far so good?
[18:05] <agoliveira> Great
[18:06] <agoliveira> Are we there yet?
[18:06] <agoliveira> - We are in the process to deliver the first release in the next few weeks. This is the engineering point of view and there's a lot other considerations so watch for the release announcement! :)
[18:07] <agoliveira> Ok, now that we have the basic bits, let's start the fun part: How can I try/test it?
[18:07] <agoliveira> First, bare in mind that there's very little hardware available that can run UME right now.
[18:07] <agoliveira> The only piece of commercial hardware easily found that you can run UME out of the box is the Samsung Q1 Ultra but as this is a matter of hardware support,
[18:07] <agoliveira> it's not hard to add other platforms.
[18:08] <agoliveira> If you have any questions, dont' for get to ask then in ﻿#ubuntu-classroom-chat making as ﻿QUESTIONS:
[18:09] <agoliveira> Meanwhile I'll keep bombarding you :)
[18:09] <agoliveira> Talking about testing:
[18:09] <agoliveira> There's basically 2 ways to test it: using a supported hardware (which is kind of hard to find as I said) and simulating it.
[18:10] <agoliveira> Using the hardware is a no-brainer, just create the image (we're going to talk about this in a minute) and transfer for it.
[18:10] <agoliveira> To simulate, you can use Xephyr on your desktop. Very pratical but... there's aways a "but":
[18:10] <agoliveira> The advantage of simulation is that you can run tests more quickly and can easily test things like different resolutions but you loose hardware support like touchscreen and some things like DPI can change a lot from one device to another so text appearance, for instance, may not be accurate.
[18:11] <agoliveira> ﻿bugslayr: QUESTION: is it theoretically possible to build UME for a low end intel PC?
[18:11] <agoliveira> bugslayr: Yes, it is. I'll talk about this a bit later
[18:11] <agoliveira> ﻿﻿gnomonic: QUESTION: Other platforms? Such as the Nokia N810?
[18:12] <agoliveira> gnomonic: As I said, the project aims x86/UMPCs only for now. Things like ARM support is possible but Nokia devices carry some aditional problems:
[18:12] <agoliveira> Parts of the hardtawre are proprietary so no open support for them.
[18:13] <agoliveira> ﻿ F30: QUESTION: Why not building a ready-t-run platform such as Ubuntu Desktop or Server edition? Do you think that companies like a technology base more? As Microsoft currently doesn't have a MID OS in my opinion it could be a great chance for Ubutu if users see that "Ubuntu" works fine on their MID they may also give it a chance for their PC too - but that could only work with ONE UME version.
[18:14] <agoliveira> F30: This project is about buildoing a platform, not a ready to run system. As for the reason to do it, I'll have to ask someone upper the food chain, I'm just a humble enginner ;)
[18:14] <agoliveira> ﻿Flyser__: QUESTION: So UME will not run (well) on full blown notebooks?
[18:15] <agoliveira> Flyser__: It can but it's aim is for devices with touchscreen, not very common on notebooks.
[18:15] <agoliveira> Ok, going on...
[18:15] <agoliveira> How to install UME?
[18:15] <agoliveira> There's basically 2 ways:
[18:16] <agoliveira> You can download a ready to run image from here http://cdimage.ubuntu.com/moblin/hardy/ or you can build your own image.
[18:16] <agoliveira> Again: the hardware support for now, specially in those images, is very restricted. I only recommend to try on a Samsung Q1 using the images found in the links with "samsung" on it.
[18:16] <agoliveira> The others are designed to run on development boards but, again, it's more a matter of kernel changes so it's quite hackable.
[18:17] <agoliveira> The preferend method it to use the image creator (more about in a minute) to generate your own image and test it on your desktop or put it into a device. I recommend this method as it's easier to test and hack to adapt to a different platform.
[18:17] <agoliveira> Any questions up to this point?
[18:18] <agoliveira> Well, or I'm doing very well or I'm boring as hell :)
[18:18] <agoliveira> ﻿QUESTION : Could directly take an image from the given link and test it using Xephyr ?
[18:19] <agoliveira> Raseel: No. The image is designed to run directly from the device. In theory one could hack it to do it but it's not pratical.
[18:19] <agoliveira> leftyfb: QUESTION: What other devices are next on the list for compatibility going forward? I'm personally concerned about the EEEpc
[18:20] <agoliveira> leftyfb: There's nothing defined yet but we are sure aware of this kind of device (I have one myself) and as it's easy to hack UME to work on it, I guess you can expect news on this field, from us or from the communit
[18:22] <agoliveira> Ok, so let's talk a bit about how to build an image. The only problem in doing this right now is that due the time it takes, specially the first time, we won't be able to do it in real time but feel free to contact the gang later.
[18:23] <agoliveira> There's this tool used to create the images, the moblin-image-creator. Install it the usual way, sudo apt-get install moblin-image-creator
[18:23] <agoliveira> Run it: sudo image-creator (yes, it has to run sudoed)
[18:24] <agoliveira> You will see a simple interface with 3 basic parts: the platform projects, targets and target images.
[18:24] <agoliveira> There's some (old) visual here: https://wiki.ubuntu.com/MobileAndEmbedded/CreatingAnImageForUMEDevice
[18:25] <agoliveira> ﻿ bugslayr: QUESTION: does "apt-get install moblin-image-creator" install all required packages or is there something else I have to take care of?
[18:25] <agoliveira> bugslayr: the iamge creator will download and install all the necessary packages into a chroot.
[18:26] <agoliveira> image
[18:26] <agoliveira> First, let's create a platform project. Click on Add and you will see a dialog asking for some data, all self-explanatory but the platform selection.
[18:26] <agoliveira> The platform indicates to what hardware the image will be created (currently mccaslin and menlow only) and from where the packages will be retrieved.
[18:27] <agoliveira> Let me explain that the project is the base from your targets will be created (more on this in a minute)
[18:27] <agoliveira> Mccaslin is the platform of the Samsung Q1 and others around and menlow is the current platform provided by intel for the new generation devices.
[18:27] <agoliveira> I'm not aware of any commercial solution using it right now. Let's select as if it would be created for a Q1 so, let's use mccaslin-lpia-ubuntu-hardy-ppa which will assure you get the latest packages.
[18:28] <agoliveira> Be aware that the project is running very fast so things tend to break at this moment so don't be alarmed or frunstrated if your image don't work pronto :)
[18:29] <agoliveira> After you select you platform, press add target and your base system will be created. It can take a long time.
[18:29] <agoliveira> I mean, even hours deppending on your link.
[18:29]  * agoliveira simulates having a coffee...
[18:29] <agoliveira> After it's done, you will now create a target which is what's actually going into the device.
[18:30] <agoliveira> Again, more waiting...
[18:30] <agoliveira> At first, just the bare minimal will be installed and now you can add a bunch of packages called fsets.
[18:30] <agoliveira> Click in Add Funcional Sets and you will see a list of groups you can add to your basic image.
[18:31] <agoliveira> Those fsets are basically a group of packages and dependencies to give you something functional in the end.
[18:31] <agoliveira> Try samsung-full-mobile-stack-with-proprietary for a very complete one. Note that by selecting it several other ones are selected automatically.
[18:31] <agoliveira> After that, wait until the packages are downloaded and installed.
[18:31] <agoliveira> BTW, if you're planing working on this in a regular basis, I strongly recommend to add a squid cache in your network.
[18:32] <agoliveira> Even without it, after the initial setup things tend to go faster.
[18:32] <agoliveira> After that you can create a several different kinds of images that can be transfered to a USB stick and installed on your device or you can test it live using Xephyr.
[18:33] <agoliveira> For testing on the device I recomend the install USB one which will prepare the image to automatically install in your device.
[18:33] <agoliveira> BIG FAT WARNING: this will wipeout your device storage!
[18:33] <agoliveira> ﻿Raseel: QUESTION: How much time would it take , approx, for the base system to be created ?
[18:34] <agoliveira> Raseel: As I said, deppends on how fast you can downlaod stuff. For the first time it can take hours.
[18:34] <agoliveira> Don't tell that I didn't warn you all :)
[18:55] <Amaranth> jcastro: I did it for you this time. :)
[18:57] <jcastro> Ok, Nicolas is next with Merging Packages 101
[18:57] <jcastro> agoliveira had connection problems, so please drop by #ubuntu-mobile if you want to continue the discussion there
[19:00] <jcastro> nxvl: your turn!
[19:00] <nxvl> \o/
[19:01] <nxvl> wooohooo
[19:01] <nxvl> it's merging time!!
[19:01] <nxvl> Hi!
[19:01] <nxvl> We are going to learn how to merge packages
[19:01] <nxvl> But, first of all we need to understand what this merging thing is.
[19:01] <nxvl> On the first stage of our development circle we import packages from debian unstable (sid)
[19:01] <nxvl> and then we start working on them
[19:02] <nxvl> fixing bugs and adding features
[19:02] <nxvl> but if we import all the packages from debian, the work done before will be missing?
[19:02] <nxvl> Well, that's not entirely true.
[19:02] <nxvl> We have 2 ways to import packages from debian: sync and merge
[19:02] <nxvl> To sync a package is to import it from debian as it is, without furter changes.
[19:02] <nxvl> On the other hand we have merging.
[19:03] <nxvl> To merge a package is to take the debian package, and include on it the ubuntu changes
[19:03] <nxvl> but, not all changes, we need to check if the ubuntu changes hasn't been already included on debian.
[19:04] <nxvl> That happends often since in ubuntu we are thankfull with debian and send the patches back to them
[19:04] <nxvl> so they can also take approach of our work.
[19:04] <nxvl> < Raseel> QUESTION: So syncing is usually done for new packages taken       from Debian ?
[19:04] <nxvl> Raseel: good one
[19:04] <nxvl> Raseel: yes, it is
[19:04] <nxvl> Raseel: but not only on this cases
[19:04] <nxvl> Raseel: also we do sync when we haven't change the package in ubuntu
[19:05] <nxvl> Raseel: and when all the ubuntu work has been already included on debian
[19:05] <nxvl>  < rlaager> QUESTION: If I'm interested in getting a new package into
[19:05] <nxvl>                  Ubuntu (by way of Debian), when is the cut-off?
[19:05] <nxvl> rlaager: the Debian import Freeze is the time we don't import anything
[19:06] <nxvl> rlaager: after the DIF we only include special packages
[19:06] <nxvl> rlaager: so you need to ask for an exception to it
[19:07] <nxvl> for Ibex the DIF is going to be on Jube 26
[19:07] <nxvl> June*
[19:07] <nxvl> you can see more of it on https://wiki.ubuntu.com/IntrepidReleaseSchedule
[19:07] <nxvl> Ok have we understand what a merge is?
[19:07] <nxvl> well
[19:07] <nxvl> it seems se did
[19:07] <nxvl> So, now that we have clear the concept of merging i will explain how a merge is done
[19:08] <nxvl> and do a merge with you, so this will be a hands on talk.
[19:08] <nxvl> First of all we need to check what packages need to be merged, since sync is done automatically.
[19:08] <nxvl> and that where MoM goes in.
[19:08] <nxvl> We call MoM our merging tool, which is an acronym of Merge-o-Matic - MoM
[19:09] <nxvl> It can be found on http://merges.ubuntu.com
[19:09] <nxvl> We are going on how to use it later, first we need some tools.
[19:09] <nxvl> First of all we need to create a work directory, i use to use ubuntu/src, but you could use whatever you want to
[19:09] <nxvl> From now on we are calling this $WORK_DIR, so please create a working directory for your own.
[19:10] <nxvl> now store the path on the $WORK_DIR variable writting "export $WORK_DIR=/path/to/work/directory"
[19:10] <nxvl> which in my case will be "export WORK_DIR=~/ubuntu/src"
[19:10] <nxvl> ok, now that we have it we need to download the grab-merge script
[19:11] <nxvl> you can find it in MoM, there is a link on the header text which point to it.
[19:11] <nxvl> For making it easier just download it from here: http://merges.ubuntu.com/grab-merge.sh
[19:11] <nxvl> and save it on $WORK_DIR, just write on your terminal:
[19:11] <nxvl> cd $WORK_DIR ; wget -c http://merges.ubuntu.com/grab-merge.sh; chmod +x grab-merge.sh
[19:12] <nxvl> ok, now we will need some packages, we need devscripts, which are packages for doing our packaging work
[19:12] <nxvl> and most important for merging patchutils, so please run:
[19:12] <nxvl> sudo apt-get install devscripts patchutils
[19:12] <nxvl> i will wait a little so you all can download and install them
[19:13] <nxvl> oh! i have a question in here
[19:13] <nxvl> 13:09 <progfou> QUESTION: so, except during the DIF time, any Debian package will be sync'd ?
[19:13] <nxvl> progfou: yes, all the packages that doesn't need to be merged are automatically synced
[19:14] <nxvl> after DIF we need special cases to sync and merge packages
[19:14] <nxvl> ok!
[19:14] <nxvl> so all of you must have the tools installed
[19:14] <nxvl> < Raseel> QUESTION: Which package are we planning to merge ?
[19:14] <nxvl> Raseel: beagle
[19:14] <nxvl> ok, i think we have all what we need now, so let's start
[19:15] <nxvl> i will do a complete, so a "complex" merge, so you understand everything you can see on a merge
[19:15] <nxvl> and later i will do a simple and easy merge if we have time.
[19:15] <nxvl> What we need?
[19:15] <nxvl> just to pick a package and make an empty directory.
[19:15] <nxvl> to pick a package you need to browse the list of packages on MoM
[19:16] <nxvl> as we are new contributor our main focus will be on universe, so go into the universe list:
[19:16] <nxvl> http://merges.ubuntu.com/universe.html
[19:16] <nxvl> There we find a large list of packages, with their ubuntu, debian and base version
[19:16] <nxvl> also we see the last uploader, which is the last person who work on the package, and in some cases the uploader
[19:17] <nxvl> QUESTION: as a debian maintainer, is it safe to wait that the  package to merge is in testing ?
[19:17] <nxvl> rZr: nop
[19:17] <nxvl> rZr: we merge from debian sid, not from testing
[19:17] <nxvl> why isn't the person who work on a package the one who upload it? well, as contributor we don't have access to the servers
[19:17] <nxvl> < arhimodeg> QUESTION: on apt-get is always the last revision of a  program?
[19:17] <nxvl> arhimodeg: yes
[19:18] <nxvl> < rZr> even when there are know RC bugs ?
[19:18] <nxvl> rZr: yes
[19:18] <nxvl> rZr: we fix them after DIF
[19:18] <nxvl> ok
[19:18] <nxvl> why isn't the person who work on a package the one who upload it? well, as contributor we don't have access to the servers
[19:18] <nxvl> so we need a sponsor who will check our work, send us some feedback if something is wrong and/or upload it when they are happy with our work
[19:19] <nxvl> but more on this later.
[19:19] <nxvl> We are going to work on beagle
[19:19] <nxvl> so we are going to create an empty directory to work on it and get into it:
[19:19] <nxvl> mkdir $WORK_DIR/beagle ; cd $WORK_DIR/beagle
[19:19] <nxvl> now we need to download the packages to work on them, that's easily done with the script we download earlier:
[19:19] <nxvl> ../grab-merge.sh beagle
[19:20] <nxvl> i will give you some minutes so we all have the files we need
[19:20] <nxvl> now we wait until it downloads the debian package and the ubuntu one.
[19:21] <nxvl> most of the work have been already done by MoM, we only need to work on some tunning and the tasks which need human intervension
[19:21] <nxvl> rZr: thnx :D
[19:21] <nxvl> ok, if everything is already downloaded we can see a file called REPORT, this is the first thing we need to look at
[19:22] <nxvl> in this case we see a CONFLICTS title on it where we can find a line saying:
[19:22] <nxvl>   C  debian/patches/00list
[19:22] <nxvl> That means that on this file we have a conflict and we need to decide what to include and what to remove
[19:23] <nxvl> so, open it with your prefered text editor, i prefer vim, so i will use it for the example, feel free to use the one you are more comfortable with
[19:23] <nxvl> cd beagle-0.3.4-1ubuntu1/ ; vim debian/patches/00list
[19:23] <nxvl> there we see:
[19:23] <nxvl> <<<<<<< beagle-0.3.3-2ubuntu1 (ubuntu)
[19:23] <nxvl> glib-sharp-2.0-support.dpatch
[19:23] <nxvl> [19:23] <nxvl> fix_system-scripts.dpatch
[19:23] <nxvl> >>>>>>> beagle-0.3.4-1 (debian)
[19:23] <nxvl> now we need to check what this patches are and what to keep
[19:24] <nxvl> doing 'ls debian/patches/' we find that we have the 2 patches in there
[19:24] <nxvl> we need to check at the changelog to decide if we want to delete one of them, we can use dch command for this:
[19:24] <nxvl> dch -e
[19:24] <nxvl> there we see that Luca Falavigna added glib-sharp-2.0-support.dpatch on 0.3.3-2ubuntu1
[19:25] <nxvl> (if you are using vim put the cursor on 0.3.3-2ubuntu1 and press space bar
[19:25] <nxvl> but we alse see that Jose Carlos Garcia Sogo disable it on 0.3.4-1:
[19:25] <nxvl>     + glib-sharp-2.0-support: disabled. Included upstream.
[19:25] <nxvl> but there is no explicit change adding glib-sharp-2.0-support.dpatch to debian, but we can assume that he include it on 0.3.3-3
[19:25] <nxvl> since the patch has been included to fix FTBFS as well as the change on 0.3.3-3, se we need to check what Debian bug #470328 is
[19:25] <nxvl> we can check it on BTS, the debian bug tacker, at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470328
[19:26] <nxvl> as we see on the report Luca send his patch back to debian, and they include it, so now we are sure that the patch was included on 0.3.3-3 and it's save to remove it
[19:26] <nxvl> so we need to remove:
[19:26] <nxvl> <<<<<<< beagle-0.3.3-2ubuntu1 (ubuntu)
[19:26] <nxvl> glib-sharp-2.0-support.dpatch
[19:26] <nxvl> [19:26] <nxvl> and
[19:26] <nxvl> >>>>>>> beagle-0.3.4-1 (debian)
[19:26] <nxvl> from debian/patches/00list and also is a good idea to remove debian/patches/glib-sharp-2.0-support.dpatch since we don't need it anymore
[19:27] <nxvl> Then we just need to edit the changelog adding the changes we are keeping, so the changelog entry needs to be:
[19:27] <nxvl> beagle (0.3.4-1ubuntu1) hardy; urgency=low
[19:27] <nxvl>   * Merge from debian unstable, remaining changes:
[19:27] <nxvl>     - debian/control:
[19:27] <nxvl>       + Rename ice{weasel,dove}-beagle to {mozilla,thunderbird}-beagle and
[19:27] <nxvl>         and update the dependencies accordingly.
[19:27] <nxvl>       + Change Maintainer to Ubuntu Mono Team.
[19:27] <nxvl>     - debian/rules:
[19:27] <nxvl>       + Install the mozilla-beagle and thunderbird-beagle extensions.
[19:27] <nxvl>     - ice{dove,weasel}.dirs:
[19:27] <nxvl>       + Renamed to {mozilla,thunderbird}-beagle.dirs.
[19:27] <nxvl>       + Fixed paths to point to usr/lib/{firefox,thunderbird}
[19:28] <nxvl>  -- Nicolas Valcárcel <nvalcarcel@ubuntu.com>  Tue, 29 Apr 2008 00:33:30 -0500
[19:28] <nxvl> 13:28 < ScottK> lintian will also kvetch at you if you have a patch system, but  no patches.
[19:28]  * nxvl HUGS ScottK 
[19:28] <nxvl> ok
[19:28] <nxvl> i will slow a little
[19:28] <nxvl> i will wait a bit until everyone is with me again
[19:28] <nxvl> :D
[19:28] <nxvl> if you have questions ask them now
[19:29] <nxvl> i have uploaded my changelog to pastebin
[19:29] <nxvl> http://pastebin.ca/1001989
[19:29] <nxvl> so you can check it clearly
[19:30] <nxvl> are you already with me?
[19:31] <nxvl> raise your hands if you have you changelog already edited: o/
[19:31] <nxvl> < Syntux> QUESTION: do we have to delete the patches files or remove them  from certain file that list all patches?
[19:31] <nxvl> Syntux: both
[19:32] <nxvl> Syntux: we need to remove the line containing "glib-sharp-2.0-support.dpatch" from 00list
[19:32] <nxvl> and remove the patch file from debian/patches
[19:32] <nxvl> no one raise his hand :(
[19:33] <nxvl> ok
[19:33] <nxvl> it seems that everyone is still downloading the packages
[19:34] <nxvl> Syntux: yes, sorry about that :(
[19:35] <nxvl> Syntux: i was expeting better broadband from the audience than mine
[19:37] <nxvl> ok
[19:37] <nxvl> i will continue for now
[19:37] <nxvl> if you have still problems downloading you can check at the logs after the session and ping me, i'm always online
[19:37] <nxvl> :D
[19:38] <nxvl> ok
[19:38] <nxvl> so, why we have this o the changelog?
[19:38] <nxvl> we have included this things
[19:38] <nxvl> since the only changes we are keeping are the ones from the last merge.
[19:38] <nxvl> Then is just a matter of generating the debdiff, reporting the bug asking for merge, upload the debdiff and ask for sponsorship.
[19:39] <nxvl> Sometimes we are not keeping any ubuntu changes since all of them have been already included in debian, then we need to ask for a sync.
[19:39] <nxvl> i have already report the bug and upload the debdiff
[19:39] <nxvl> on Bug #224318
[19:40] <nxvl> https://bugs.edge.launchpad.net/ubuntu/+source/beagle/+bug/224318
[19:40] <nxvl> ScottK: i will apreciate if you sponsor it :D
[19:40] <nxvl> so i was thinking on do another merge
[19:41] <nxvl> but as everyone is still stuck on the first one
[19:41] <nxvl> i will only answer questions
[19:41] <nxvl> :D
[19:41] <nxvl> so, please try to finish the merge
[19:41] <nxvl> and ask questions if you have some
[19:42] <nxvl> < RoAkSoAx> QUESTION: do we have to be on Intrepid Ibex to do the merging?
[19:43] <nxvl> RoAkSoAx: nop
[19:43] <nxvl> RoAkSoAx: but it is helpfull to have a chroot environment
[19:43] <nxvl> RoAkSoAx: i use pbuilder, but you can use whatever you want
[19:44] <nxvl> < Gilou> QUESTION: what is the relationship between ubuntu & deb  developpers? What would happen if debian would take too long to  take your patch into account, would you just roll out your own,  and deal with a merge (or non merge) later once the patch is  committed (or not) in debian?
[19:44] <nxvl> Gilou: we send our packages back to debian, to contribute to them
[19:45] <nxvl> Gilou: also, not all our patches are used by DD, because the bug is only present on ubuntu, or they don't want that feature
[19:45] <nxvl> Gilou: so, if the patch is not included on debian you just need to merge it on the next development circle
[19:47] <nxvl> stani: done :D
[19:47] <nxvl> Gilou: does that answers your question?
[19:47] <nxvl> < Monika|K> Question: You write Change Maintainer to Ubuntu Mono Team ...  should that be MOTU Team?
[19:48] <nxvl> Monika|K: not in this case, the maintainers of beagle are Mono Team
[19:48] <nxvl> Monika|K: since they are the ones in charge of Mono packages
[19:48] <nxvl> Monika|K: but in most cases it will we MOTU or Core Developers
[19:49] <nxvl> Monika|K: but there are also specific cases in which a person is listed as Maintainer
[19:49] <nxvl> < Monika|K> Question: What is beagle and what does it have to do with  Firefox?
[19:49] <nxvl> Monika|K: beagle is a search engine
[19:50] <nxvl> Monika|K: it an app that do files search on our system, it also finds firefox bookmarks
[19:50] <nxvl> Monika|K: but that's a little OT
[19:50] <nxvl> rZr: i have see those logs before, i'm not sure where they keep them
[19:52] <nxvl> < Monika|K> Question: In what cases would a person be listed as  maintainer?
[19:52] <nxvl> on ubuntu we don't use it
[19:52] <nxvl> but there are cases in which the Debian Maintainer is also an Ubuntu Developer and he want's to still be the Maintainer of the package in ubuntu
[19:52] <nxvl> or when the package are just synced
[19:53] <nxvl> s/are/is
[19:53] <nxvl> ScottK: isn't it?
[19:55] <nxvl> did you have any last questions?
[19:55] <nxvl> have you all merge the package?
[19:56] <nxvl> if you merge the package raise your hands: o/
[19:56] <nxvl> ok
[19:57] <nxvl> so as i'm getting out of time
[19:57] <nxvl> just a few last words
[19:57] <nxvl> please if you want to be involved on ubuntu, keep in mind that we depend on debian's work
[19:57] <nxvl> and we need to be thankfull with DD
[19:58] <nxvl> so if you have corrected a bug, try to check if it is also present in debian and send them the patch
[19:58] <nxvl> also
[19:58] <nxvl> you need to keep in mind that if someone helps you
[19:58] <nxvl> you need to make 2 things:
[19:58] <nxvl> 1) say thanks
[19:58] <nxvl> 2) hug hime like this:
[19:58]  * nxvl HUGS ScottK 
[19:58] <nxvl> :D
[19:59] <nxvl> thanks to all for comming here
[19:59] <nxvl> if you have problems you can ask in #ubuntu-motu
[19:59] <nxvl> there is always good people around helping new contributors
[20:00] <nxvl> and i hope to see you around
[20:00] <nxvl> 14:01 < rZr> QUESTION: i would appreciate that LP can list rc  bugs thats are  in ubuntu and debian , is that planned ?
[20:00] <nxvl> rZr: take a look at ubuntuwire
[20:01] <nxvl> http://www.ubuntuwire.com
[20:01] <nxvl> rZr: on qa you can find such things
[20:02] <nxvl> is Celso already around?
[20:03] <nxvl> cprov: it's moderated
[20:03] <nxvl> Amaranth: can you give cprov voice
[20:03] <nxvl> jcastro: or you
[20:03] <nxvl> cprov: try now
[20:03] <cprov> hey
[20:03] <nxvl> ok
[20:03] <nxvl> now here is Celso
[20:03] <cprov> there we go
[20:04] <cprov> nxvl: thanks, very nice session.
[20:04] <cprov> Hi, welcome to the another UbuntuOpenWeek session, during the next hour we will talk about Launchpad PPAs.
[20:05] <cprov> I will paste the initial agenda for this session, feel free to suggest new topics in the -chat channel
[20:05] <cprov> The initial agenda is:
[20:05] <cprov>  * Roll call
[20:05] <cprov>  * Documentation: https://wiki.ubuntu.com/CelsoProvidelo/PPASystemOverview
[20:05] <cprov>  * Q & A : use #ubuntu-classroom-chat
[20:05] <cprov>  * Top 5 bug nomination: https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=ppa
[20:06] <cprov> so, let's start with the call:  who is here for the PPA session ?
[20:06] <cprov> err, I guess you will have to answer in #$this-chat
[20:07] <cprov> 12 and growing ...
[20:08] <cprov> Documentation we already have is summarised in ﻿ https://wiki.ubuntu.com/CelsoProvidelo/PPASystemOverview
[20:09] <cprov> Everyone should go there and have a quick look, I've added new sections about Delete/Copy packages
[20:09] <cprov> also about PPA dependencies.
[20:09] <cprov> I will update that again after the session, if you have any contribution, please add it there.
[20:10] <cprov> Once you've read that document you can star making question.
[20:11] <cprov> Also, anyone interested in starting a PPA right now, be my guest. The publisher will run on :20 and :40 and the builders as faster than ever :)
[20:12] <cprov> ﻿Monika|K: Yeah, can you start with, like, what is it and what is it for?
[20:12] <cprov> of course.
[20:12] <cprov> PPA stads for Personal Package Archives
[20:13] <cprov> After designing Soyuz to manage ubuntu archive (some could say it was dak reverse engineering)
[20:14] <cprov> we decided to encapsulate all the services involved in it, in a way it could be useful for other individual or groups
[20:14] <cprov> ﻿phoenix24: How can I start my PPA ?
[20:15] <cprov> PPA is one of the features provided for Launchpad users, any Launchpad user can activate a PPA for his account or team
[20:15] <cprov> ﻿QUESTION:  I'm not sure if I should use my name, or a project name for a PPA account, advice on selecting?
[20:16] <cprov> it's really up to you, PPA will be attached to a launchpad user or team. You can have both.
[20:16] <cprov> ﻿progfou: I have one: how to build the packages for two distributions (say Gutsy and Hardy) from the same source ? or is-it just not the "Right Way"™ ?
[20:17] <cprov> right, we have recently released Copy-packages feature for beta-testers (edge) it will be available for everyone thursday.
[20:18] <cprov> it allows you to *copy* a source from one series to another (for a rebuild) and if you think the binaries will fit you can copy them too.
[20:18] <cprov> see more information in the wiki page I mentioned above.
[20:19] <cprov> ﻿QUESTION: Do we have PPA for LoCal teams?
[20:20] <cprov> not by default, activating a PPA requires a team admin to accept the PPA Terms of Service, available in http://help.launchpad.net/PPAQuickStart if you wonna check
[20:20] <cprov> ﻿pwnguin: QUESTION: will people ever be able to report bugs against an individual's ppa?
[20:21] <cprov> pwnguin: not until July, this aspect is under discussion right now, many people think that filing bugs on PPA is misleading since the efforts done in PPA are intended to reach ubuntu.
[20:21] <cprov> ﻿claydoh: QUESTION: is it possible to have packages created for more than one distribution without needing to re-upload the same source package?
[20:22] <cprov> claydoh: that is one of the use-cases for copy-ui feature that I've mentioned above.
[20:22] <cprov> ﻿Monika|K: Question: I still don't understand what it is and what it does.
[20:23] <cprov> Monika|K: right, developers create source packages (in debian format)
[20:24] <cprov> Monika|K: PPA (as Soyuz itself) process/verify the sources, publish then in a archive (archive.ubuntu.com), build publish its binaries  also in a.u.c so they can be mirrored and installed by users like us.
[20:25] <cprov> ﻿QUESTION: The Link to the Packaging Guide does not work: http://doc.ubuntu.com/ubuntu/packagingguide/C/
[20:25] <cprov> that's bad ... I will fix it later, sorry.
[20:25] <cprov> ﻿UESTION: Do packages need to be of sufficient quality for potential inclusion in Ubuntu, or could local builds be hosted on a PPA for, say, a corporate rollout?
[20:26] <cprov> t﻿oobuntu: I'm not sure I understood your question.
[20:27] <cprov> toobuntu: anyway, the general answer is yes, ubuntu inclusion will be judge by MOTU. OTOH, you don't necessary have to aim ubuntu you can have your packages hosted in PPA as long as they are GPL (-like)
[20:28] <cprov> ﻿mfm: QUESTIOn Do I have to provide the Source in a special way for my PPA?
[20:29] <cprov> mfm: no, nothing is special about PPA, it works exactly and Soyuz works for ubuntu PRIMARY archive. upload a proper debian source package via ftp using the well known debian/ubuntu dev-tools
[20:29] <cprov> ﻿rZr: QUESTION: when intrepid target will unfreeze, when the toolchains ready I expect ?
[20:30] <cprov> rZr: it's not related to PPAs :)
[20:30] <cprov> ﻿progfou: QUESTION: is there a way to let PPA automaticaly get it's sources from a Launchpad project (say code.launchpad.net) ?
[20:31] <cprov> progfou: there is a feature coming after July that will allow you to build source package straight from bzr branches hosted in Launchpad.
[20:33] <cprov> rZr: oh, I see what you mean, but ubuntu release cycle is tied to PPA and vice versa, you can upload to intrepid PPA right now if want.
[20:34] <cprov> ﻿ScottK: QUESTION: Since Ubuntu derives from Debian Sid, it is often good to know how something works on Sid to enhance inter-distro collaboration.  Are there any plans to support PPA for Debian Unstable or Testing?
[20:35] <cprov> ScottK: yes, there are plans in this area, importing debian archive frequently and maintaining up to date chroots for debian will be great, sync would be done entire inside Soyuz/Launchpad
[20:35] <cprov> we will have news in this area soon.
[20:35] <cprov> ﻿ScottK: QUESTION: Currently it seems that the only place links to build logs can be found is in PPA failed to build mails.  Are there plans to expose build logs in the UI?
[20:36] <cprov> ScottK: they are very well exposed in launchpad.net/people/+me/+archive/+builds
[20:37] <cprov> ScottK: and each build their own page with more details.
[20:40] <cprov> rZr: ﻿QUESTION: I would appreciate that email alerts on failure can be disable ? is this planned too ?
[20:40] <cprov> rZr: there is not bug filed for this, I thought it was fine. Feel free to add one (product soyuz, tag ppa)
[20:41] <cprov> that's important to note, bugs about PPA feature requests, etc always use product 'soyuz' and the tag 'ppa'
[20:41] <cprov> ﻿morten: QUESTION: so after uploading the source, how can people access my package? they have to add a deb entry for it i guess? (in /etc/apt/sources.list)
[20:42] <cprov> morten: sorry for ignoring your question.
[20:42] <cprov> morten: well, 'access' is a very broad term, once it's uploaded the source can be viewed and downloaded from your PPA page.
[20:43] <cprov> morten: in order to install the binaries built from your source they will have to include the deb entries for your PPA
[20:46] <cprov> ﻿rulus: QUESTION: Are there plans on 'merging' PPA and REVU services? I feel like these are kind of similar. One could subscribe in a 'REVU' team and upload a source package to it's PPA to get it reviewed. This would, among others, bring the advantage that PPA/Soyuz checks if the package builds first before valuable MOTU time is used.
[20:48] <cprov> rulus: in the next month we will start storing debdiffs for all uploads, PPAs and primary archive and that will be another large step towards REVU features
[20:48] <cprov> rulus: I'm not sure if PPA will replace REVU, since it has it's own context and have been used successfully for a long time
[20:49] <cprov> surely PPA will incorporate REVU nice aspects and be used by MOTU to review packages in getting in ubuntu
[20:49] <cprov> ﻿progfou: QUESTION: once we have successfully build our packages with PPA, what's the next step to let them enter Universe (or is it just not the right course to ask for this?)
[20:50] <cprov> progfou: entering in the MOTU review procedure, PPA doesn't replace it, just make it easier for all people involved.
[20:53] <cprov> so, last 7 minutes, let's move on.
[20:53] <cprov> Please add other questions at the end of https://wiki.ubuntu.com/CelsoProvidelo/PPASystemOverview
[20:54] <cprov> Finally, Top 5 bug nomination: https://bugs.edge.launchpad.net/soyuz/+bugs?field.tag=ppa
[20:55] <cprov> There you will be able to find all bugs in the PPA system, check them before filling new ones
[20:56] <cprov> Be sure the features you want are listed there
[20:57] <cprov> And if you want and have time, blog about the top 5 features you would like to see released for PPAs, or the top 5 annoying bugs you would like to see fixed ASAP
[20:58] <cprov> ﻿rZr: about debian build ; this is filed  : https://bugs.edge.launchpad.net/soyuz/+bug/188564
[20:58] <cprov> right, that's in my list too, I'd love to see debian PPAs running
[20:59] <cprov> it would enforce the ubuntu/debian collaboration relationship mentioned in the last session.
[21:01] <cprov> Anyway, push your ideas, blog about them, file bugs, come and talk on #launchpad. I will be more than happy to discuss them with you.
[21:01]  * mathiaz waves at cprov 
[21:02] <cprov> mathiaz: hey
[21:02] <cprov> I'm late, sorry.
[21:02] <mathiaz> cprov: np ;)
[21:03] <cprov> thank you, guys
[21:03] <mathiaz> so after the last two rather technical sessions about packaging, we'll step back a little bit and I'll take some time to introduce the Ubuntu Server Team.
[21:03] <cprov> very good set of question :) you are all stars.
[21:04]  * cprov stops stealing mathiaz time :)
[21:04] <mathiaz> so that you can use all your knowledge about merging and PPA to improve server software in Ubuntu :)
[21:05] <mathiaz> I'll talk about who we are, what we're doing, and how you can get involved with the Server Team.
[21:06] <mathiaz> Ask your question in u-c-c and I'll answer them at the end of the session
[21:06] <mathiaz> so who is the Ubuntu Server Team ?
[21:07] <mathiaz> you can find most of the information on our wiki pages : https://wiki.ubuntu.com/ServerTeam
[21:08] <mathiaz> Most of the people involved in the server team share a common interest in server related software, such as http servers, mail servers or other services
[21:09] <mathiaz> As an extension we tend also to deal with setups found in corporate environments, such as directtory services (ldap, AD), web services or network authentication
[21:10] <mathiaz> Some of us are working for Canonical in the Server team, lead by Rick Clark
[21:10] <mathiaz> (dendrobates on IRC). Others have services running on Ubuntu and are interested
[21:10] <mathiaz> in fixing bugs.
[21:10] <mathiaz> Regular contributors takes on important tasks and lead them to completion - som of them include (listed in alphabetical order):
[21:11] <mathiaz> Adam Sommer - sommer - our documentation guru. He's taken the task to review and update the Server Guide. Thus he is in contact with the Documentation team.
[21:11] <mathiaz> Ante Karamatić - ivoks - another long time contributor to the Server Team. Also a member of MOTU, he has looked over the apache package, improved the bacula package and worked on SASL integration during the Hardy release Cycle.
[21:11] <mathiaz> Neal McBurnett - nealmcb - he has multiple interest: documentation, virtualization. He started to contribute to the Ubuntu JeOS project and ubuntu-vm-builder project.
[21:12] <mathiaz> Nicolas Valcárcel - nxvl - lots of work in bug triagging and packaging. He is also involved in the Security team.
[21:12] <mathiaz> Scott Kitterman - ScottK - main interest in mail services - if you're interested in postfix or clamav he is the man to talk to. He is also involved in the MOTU team.
[21:12] <mathiaz> So you can see that we  are a diverse group that have different interests.
[21:12] <mathiaz> We're also involved in other teams from the Ubuntu project. This is one of the caracteristic of the Server team:
[21:13] <mathiaz> we all share a common interest in server technologies, but have differents skills. Thus being part of the team often means representing the Server Team in other areas of the Ubuntu project.
[21:13] <mathiaz> Being a contributor to the server team can be taken under different roles:
[21:13] <mathiaz> The helper answers questions on the ubuntu-server mailing list and the #ubuntu-server irc channel.
[21:14] <mathiaz> Triagers dig into bugs the ubuntu-server LP team is subscribed to.  Our LP team is a bug contact for a list packages, such as samba, openldap, mysql or apache2.
[21:14] <mathiaz> The current list of packages can be found here: https://bugs.launchpad.net/~ubuntu-server/+packagebugs
[21:15] <mathiaz>  A mailing list has been created to gather all the bugs related to the ubuntu-server team: ubuntu-server-bugs@lists.ubuntu.com
[21:15] <mathiaz> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[21:15] <mathiaz> Usually we decide to target our efforts for bug triagging to one or two package for a week and discuss the outcome of our triagging effort during our weekly meeting.
[21:16] <mathiaz> This is a great way to start with the LP bug tracker and doesn't require any knowledge of programming languages.
[21:16] <mathiaz> We're working closely with the BugSquad team - triaggers participate on the bugsquad mailint lists.
[21:16] <mathiaz> And once in a while with have the honor of having our own HugDay where the whole bug triagger community helps us!
[21:17] <mathiaz> The BugSquad Team has its own wiki page: https://wiki.ubuntu.com/BugSquad/
[21:17] <mathiaz> Once bugs have been triagged, it's time to fix them. This is when the packagers come into the game. This role requires an interest in packaging.
[21:17] <mathiaz>  We maintain a list of bugs that are easy too fix:
[21:17] <mathiaz> https://bugs.launchpad.net/~ubuntu-server/+mentoring
[21:18] <mathiaz> These fixes can make their way easily into the ubuntu repositories via the sponsorship process
[21:18] <mathiaz> https://wiki.ubuntu.com/SponsorshipProcess
[21:19] <mathiaz> As we're at the beginning of a release cycle, we're focusing on Merging packages from Debian unstable into ubuntu intrepid repositories.
[21:19] <mathiaz> https://wiki.ubuntu.com/UbuntuDevelopment/Merging for an overview
[21:19] <mathiaz> I think that nxvl covered this process in-depth two sessions ago
[21:20] <mathiaz> Now is probably to best time to get started in packaging.
[21:20] <mathiaz> Doing work on the packaging front leads to a close a collaboration with the MOTU team and is a great way to gain experience to become a MOTU.
[21:20] <mathiaz> https://wiki.ubuntu.com/MOTU
[21:21] <mathiaz> Another role that kicks in on a regular schedule are the testers.
[21:21] <mathiaz> This is what we've been doing most of the last weeks, preparing for the release
[21:21] <mathiaz> New features and new packages needs to be tested before released for wide spread consumption.
[21:21] <mathiaz> So we organize test plans.
[21:22] <mathiaz> For example likewise-open is available in hardy to help AD integration.
[21:23] <mathiaz> however there are multiple AD setups out there. So we'll setup a test plan to keep track of the results.
[21:23] <mathiaz> If you have access to an AD domain, installing ubuntu and testing you can join the domain with likewise-open is an easy way to contribute to the Server Team right now.
[21:23] <mathiaz> All of this work is coordinated with the Ubuntu QA Team - https://wiki.ubuntu.com/QATeam
[21:24] <mathiaz> Testers are taking an important role when we're about to ship a new milestone or release.
[21:24] <mathiaz>  We're responsible for ensuring that the ubuntu-server isos are working correctly, which involves performing a dozen of tests for two isos.
[21:25] <mathiaz> We use the isotesting tracker from the QA team to track the results. The more testers we have, the less tests each of us has to do and results are posted faster.
[21:25] <mathiaz> Server hardware support is another area where testing is welcome.
[21:25] <mathiaz> We're trying to make sure that ubuntu can used on the main server hardware, so if you have access to such hardware, popping a cd into the machine, installing a standard ubuntu server and reporting that whether it has successfully installed or failed is an easy way to contribute to the server team.
[21:26] <mathiaz> Beside testing a new feature, documenting it is also needed.
[21:26] <mathiaz> That's the role of the Documentors.
[21:27] <mathiaz> Browsing the ubuntu-server mailing list archive, lurking in the #ubuntu-server irc channel or going through the forum posts shows patterns in user's questions.
[21:27] <mathiaz> Recurring themes are identified and turned into documentation.
[21:27] <mathiaz> A wiki page in the community section of help.ubuntu.com is first created.
[21:28] <mathiaz>  Once the quality has improved, a new section is added to the server guide.
[21:28] <mathiaz> All this work is undertaken by the Documentors of the Server Team.
[21:28] <mathiaz>  Collaboration with the Documentation team is done on a daily basis to achieve consistency with other help resources.
[21:28] <mathiaz> Adam Sommer leads the update and review of the Ubuntu Server guide.
[21:29] <mathiaz> All of the documentation is maintained in a bzr tree - helping Adam will introduce you to docbook and distributed versioning with bazaar.
[21:29] <mathiaz> There is also the option to go over server related wiki pages on the community help pages. A good starting point is the Server page that has pointers to lots of howtos.
[21:29] <mathiaz> https://help.ubuntu.com/community/Servers
[21:30] <mathiaz> The last role in the Server Team as the Developpers
[21:30] <mathiaz> they develop new features, usually specified during the Ubuntu Developer Summit that takes place at the begining of each release cycle.
[21:30] <mathiaz> Tracked by a blueprint we have around 3 months to get a new feature into Ubuntu.
[21:31] <mathiaz> For hardy, virtualization, iscsi and windows integration have been some of the features integrated.
[21:31] <mathiaz> Now that the release cycle for Intrepid is opened, we've started to gather requirements to develop new features for the next version of Ubuntu released in October this year.
[21:31] <mathiaz> So if you want something integrated or improved in Ubuntu, now is the best time to make your voice heard.
[21:32] <mathiaz> The ServerTeam idea pool is a wiki page where we track what we could work on.
[21:33] <mathiaz> https://wiki.ubuntu.com/ServerTeam/IdeaPool
[21:33] <mathiaz> As you can see, contributing to the Server Team can be undertaken in more than one way. It usually involves a lot of interaction with other teams from the Ubuntu project.
[21:33] <mathiaz> It's also a good way to show your contribution to Ubuntu and helps in getting Ubuntu membership.
[21:34] <mathiaz> The GettingInvolved page gives an overview of the roles I've talked about above
[21:34] <mathiaz> https://wiki.ubuntu.com/ServerTeam/GettingInvolved
[21:34] <mathiaz> So - how do we work ?
[21:34] <mathiaz> We track our progress on the Roadmap and meet once a week to discuss outstanding issues.
[21:35] <mathiaz> https://wiki.ubuntu.com/ServerTeam/Roadmap
[21:35] <mathiaz> We use the ubuntu-server mailing and #ubuntu-server to coordinate our activities, discuss policy change in the team.
[21:35] <mathiaz> How to join the Server Team and start contributing ?
[21:36] <mathiaz> Joining the ubuntu-server team on LP is simple as subscribing to the ubuntu-server mailing list and applying for membership on LP.
[21:36] <mathiaz> The ubuntu-server team is one of the easiest way to start getting involved in Ubuntu development.
[21:36] <mathiaz> If you already know which role you'd like to contribute as, you can find a list of tasks in the Roadmap. Don't hesitate to ask one of the team members involved in your area of interest.
[21:37] <mathiaz> Most of the information related to the ServerTeam can be found in the ServerTeam wiki pages - https://wiki.ubuntu.com/ServerTeam
[21:37] <mathiaz> If you're overwhelmed by all the available information and you're lost, come talk to me. I'll help get out of the mist and we'll find a way you can get involved in the Server Team.
[21:38] <mathiaz> I'll answer the questions from u-c-c now
[21:39] <mathiaz> 16:09 < rZr> QUESTION: can all server's packages be installed on desktop and vice versa ? (i am thinking about virtualisation ones)
[21:40] <mathiaz> Yes - server is a sub set of the desktop packages
[21:40] <mathiaz> the difference between server and desktop is one the isos mainly
[21:40] <mathiaz> the packages are coming from the same archive
[21:40] <mathiaz> -server isos install the ubuntu-standard preseed, and -desktop isos install the ubuntu-desktop preseed
[21:41] <mathiaz> 16:15 < melter> QUESTION: when i'm configuring the network during installation, what hostname do i enter if it's dynamically assigned by the dhcp server?
[21:42] <mathiaz> you can choose whatever you want - it should be overriden at boot time.
[21:42] <mathiaz> I'd add that #ubuntu-server is a great place to ask these kind of questions - you can find valuable people in there.
[21:43] <mathiaz> 16:35 < maanskyn> QUESTION: Do you see certification (of ISV offerings and by ISVs) as critical to enterprise adoption? Red Hat and Novell seem to focus on this a lot/
[21:43] <mathiaz> Canonical offers ways for ISV to certify their application on Ubuntu
[21:44] <mathiaz> Canonical also has a hardware certification program for OEMs.
[21:44] <mathiaz> There is also the Ubuntu Certified Engineer available from LPI.
[21:45] <mathiaz> So certifications are available in a number of forms and are important for businesses.
[21:45] <mathiaz> 16:35 < rlaager> QUESTION: Why is the at package deprecated? Does the cron package provide an at command?
[21:46] <mathiaz> I'm not sure that the at package is deprecated - it may have been replaced by another package.
[21:47] <mathiaz> cron doesn't provide an at command though - these two programs have different purposes.
[21:47] <mathiaz> 16:37 < Syntux> QUESTION: Any plans for Ubuntu Server Admin Cert? something like the UCP
[21:48] <mathiaz> I'm not sure what you refer to Ubuntu Server Admin Cert - if it's a web interface to remotely administer a server, e-box is available in universe
[21:48] <mathiaz> 16:38 < furicle> QUESTION:  Any plans for a 'sucess stories' page - real people showing off real server installs?
[21:49] <mathiaz> the server edition section of ubuntu.com has been revamped during the hardy release cycle - there may be use cases there now.
[21:51] <mathiaz> 16:39 < King_Creole> QUESTION: Any chance we will see Oracle (DB, App server) running on Ubuntu in the near future with official certification from Oracle?
[21:51] <mathiaz> That would be great - but it's more up to Oracle to do it.
[21:52] <mathiaz> 16:40 < KevinS> QUESTION: Any suggested guides on how to best make use of the new install options (Mail, DNS etc.)?
[21:52] <mathiaz> I'd point out the Ubuntu Server Guide
[21:52] <mathiaz> https://help.ubuntu.com/8.04/serverguide/C/index.html
[21:53] <mathiaz> 16:40 < rZr> QUESTION: Any idea on how to get support from software vendors (openor closedsource) who only support one version of linux distro (let say deadrat)
[21:53] <mathiaz> Bug them - and ask them to support ubuntu
[21:54] <mathiaz> 16:40 < rlaager> QUESTION: Regarding RubyOnRails, is there a plan to deal with packaging things that are currently distributed as gems?
[21:54] <mathiaz> There was some discussion during last UDS about ruby and rails - however there wasn't enough knowledge about this area with the attendees
[21:54] <mathiaz> A spec was written up - but it didn't make it in time for hardy
[21:54] <mathiaz> any help in that area is welcome !
[21:56] <mathiaz> A link to case studies: http://www.ubuntu.com/products/casestudies/
[21:57] <mathiaz> the Ruby on Rails specification: https://wiki.ubuntu.com/RubyOnRailsStack
[21:58] <mathiaz> 16:54 < RoAkSoAx> QUESTION: Is there going to be a Ubuntu Server Course (Like the recently launched Desktop course on shop.canonical.com)
[21:59] <mathiaz> Not that I know of. May be worth mentionning on the ubuntu-training mailing list.
[21:59] <mathiaz> So I think I'm running out of time
[21:59] <mathiaz> I haven't answered all the questions posted in u-c-c
[21:59] <mathiaz> Stop by #ubuntu-server and I'm glad to give you answers there
[21:59] <jcastro> thanks mathiaz!
[22:00]  * mathiaz waves at kees 
[22:00] <jcastro> you're up kees!
[22:00] <kees> thanks jcastro :)
[22:00] <kees> Welcome everyone!  This is going to be a quick intro to how the Security Team operates within Ubuntu
[22:01] <kees> the main entry-point for information about the team is here: https://wiki.ubuntu.com/SecurityTeam
[22:01] <kees> our wiki page is still a big young, so pardon the lack of details in the FAQ and KnowledgeBase areas.
[22:02] <kees> I'm hoping we might be able to populate some of the FAQ with today's intro's questions.  :)
[22:02] <kees> The most active subteams within the Security Team is "ubuntu-security" and "motu-swat"
[22:03] <kees> when there are updates that need to happen, these two teams are the ones handling it usually.
[22:03] <kees> in general, our "update procedure" is here: https://wiki.ubuntu.com/SecurityUpdateProcedures
[22:03] <kees> we focus on fixing "CVE"s in published ubuntu releases
[22:04] <kees> a CVE is basically a number identifying a flaw in software that has security implications
[22:04] <kees> the central collection of CVEs here: http://cve.mitre.org/
[22:05] <kees> since CVEs are global identifiers, they cover software (and hardware) from any vendor in the world -- only some CVEs apply to Ubuntu software.
[22:05] <kees> (CVE stands for Common Vulnerabilities and Exposures)
[22:06] <kees> the first step to fixing security problems in Ubuntu is keeping up to date with new CVEs, and checking to see in Ubuntu is affected.
[22:06] <kees> to help coordinate between teams and people, we have an ubuntu-specific reponsitory for tracking CVEs: https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master
[22:07] <kees> this is a bzr branch, with details about every CVE that has been issued (most are flagged "ignore" since they apply to unpackaged software, different vendors like Apple or Microsoft, etc)
[22:07] <kees> 21:06 < firefly2442> QUESTION: On average, how long does it take from a vulnerability being discovered to an updated DEB file being available?  Does
[22:07] <kees>                      this change much if the issue is upstream?
[22:08] <kees> the speed of update depends greatly on the severity of the issue.
[22:08] <kees> once CVEs have been identified, the team will prioritize them, and start either tracking down patches or making our own.
[22:09] <kees> some CVEs are private for a while while upstream (and the vendors) try to figure out solutions.  This is called an "embargoed" issue.
[22:09] <kees> the ubuntu tracker only shows public CVEs, since none of the vendors are allowed to discuss embargoed issues until they reach their "coordinated release date"
[22:11] <kees> but, to answer firefly2442's question, I would say roughly under a few days for high-priority issues (these issues tend to start embargoed, so there is plenty of time to fix them before they're public)
[22:11] <kees> under a month for medium issues, and "low" issues can be pretty different.
[22:12] <kees> some of the URLs for more information that I'm listing here can also be found in our KnowledgeBase: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase
[22:13] <kees> once the teams get issues fixed, then they test them, and finally publish the fixes.
[22:13] <kees> presently, security updates for main/restricted packages (mostly handled by "ubuntu-security") get "Ubuntu Security Notices" (USNs) published
[22:14] <kees> http://www.ubuntu.com/usn/  there is a mailing list for this as well: http://lists.ubuntu.com/archives/ubuntu-security-announce/
[22:15] <kees> besides the two teams handling security updates, we also have a team dedicated to providing better security globally to Ubuntu.  this is the "ubuntu-hardened" team.  It started very SELinux-centric, but has grown to include people interested in AppArmor and other hardening techniques
[22:16] <kees> we also have a "white hat" team ("ubuntu-whitehat") that is dedicated to hunting down new security issues.  it is young, but growing up nicely.
[22:16] <kees> since all of the teams are rather small, we still use a single IRC channel (#ubuntu-hardened) and a single mailing list (ubuntu-hardened)
[22:17] <kees> 21:15 < pschulz01> QUESTION: What proportion of CVE's get fixed prior to the embargo date?
[22:17] <kees> I don't have specific numbers, but in general, if a CVE is embargoed, and high priority, it is fixed before the embargo.  The embargo dates are chosen to help all the vendors get their fixes ready.
[22:18] <kees> so, I would say it is close to 100%.
[22:18] <kees> 21:13 < ubuntu_demon> Question : Is Ubuntu using salted md5 passwords or something else ?
[22:19] <kees> yes, the current default for /etc/shadow is salted md5.  (see "man shadow")
[22:19] <kees> Should sha-512 be used or something stronger ?
[22:19] <kees> I wouldn't be against it, but it would take a certain amount of coordination.
[22:20] <kees> salted md5 is still out of reach for even well organized collaborative cracking efforts.
[22:20] <kees> 21:13 < RzR> QUESTION: what kind of tools do you recommend to developpers to achieve better quality ? i am think about valgrind etc
[22:20] <kees> valgrind is an excellent tool for locating memory corruption.
[22:21] <kees> for compiled programs, I tend to believe in: -Wall -Werror -Wformat -Wformat-security -D_FORTIFY_SOURCE=2 -O2
[22:21] <kees> hm, and -Wl,-z,relro
[22:21] <kees> these kinds of hardening details can be found here: https://wiki.ubuntu.com/Security/HardeningWrapper
[22:22] <kees> beyond that, avoiding common pit-falls (named files in /tmp, etc) is a good idea.  I will add a "best practices" checklist to the KnowledgeBase
[22:23] <kees> 21:19 < ubuntu_demon> Question : Are you aware of https://help.ubuntu.com/community/UnsafeDefaults ? Should any of these things be changed by
[22:23] <kees>                       default ?
[22:23] <kees> I wasn't personally aware of that page, but I was hoping to review a bunch of the defaults in Ubuntu now that the LTS is out the door.
[22:24] <kees> can someone link to that page from the roadmap: https://wiki.ubuntu.com/SecurityTeam/Roadmap ?
[22:24] <kees> 21:20 < ubuntu_demon> Question : What kind of coordination would be needed to use SHA-512 ?
[22:25] <kees> I'm not 100% sure, but generally making sure there is clean backward compatibility when moving to it, discussing it with upstream glibc, etc.
[22:25] <kees> 21:20 < ubuntu_demon> Question : What about cold boot attacks against Ubuntu's disk encryption ? Can they be prevented somehow ?
[22:26] <kees> The cold-boot stuff is pretty extreme.  Since there tend to be more pressing matters to investigate, this hasn't really been addressed very much yet.
[22:26] <kees> 21:21 < ubuntu_demon> Question : What about memory protection ? Are ASLR and similar techniques completely implemented or are there still some parts
[22:26] <kees>                       missing ?
[22:26] <kees> 8.04 has full memory protection available in the kernel (\o/).
[22:27] <kees> the "last piece" of ASLR is to get programs compiled to take advantage of the executable-image-ASLR
[22:27] <kees> stack and libs (and mmap) happen automatically.
[22:28] <kees> 8.10 will have heap (brk) ASLR separate from the exec ASLR, which will be nice too.
[22:28] <kees> 21:21 < ubuntu_demon> Question : What about wrapping web-browsers in apparmor ?
[22:28] <kees> I think this is a good idea, but it's not very trivial.
[22:29] <kees> I am (and the rest of the ubuntu-hardened team is) very interested in getting more AppArmor profiles (and SELinux policies) written to cover more of our common use-cases
[22:30] <kees> we've been slowly adding them, and there was a strong push to get "by-default" profiles active for a number of common server services, done by the server team.  We're hoping to help the desktop team do the same for various network-facing tools like the browsers.
[22:31] <kees> 21:27 < toobuntu> QUESTION: SAK implementation currently closes everything that has /dev/console open, including entire tty7 (X), while Windows has
[22:31] <kees>                   the option to require Ctrl-Alt-Del prior to entering a log on password.  What would be involved to implement something like this
[22:31] <kees>                   for Ubuntu?
[22:32] <kees> This is a good idea -- adding it to the Roadmap would be appreciated.
[22:33] <kees> SAK: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=Documentation/SAK.txt;hb=HEAD
[22:34] <kees> as a quick aside to the "best practices" question earlier, Debian and Ubuntu have been coordinating to create a "hardening-wrapper" tool that is used as a Build-Dep for packages.
[22:34] <kees> (full disclosure: I wrote it)
[22:34] <kees> some details are here: http://wiki.debian.org/Hardening and http://lists.debian.org/debian-devel-announce/2008/01/msg00006.html
[22:35] <kees> (both related to the earlier URL https://wiki.ubuntu.com/Security/HardeningWrapper)
[22:35] <kees> so that's the quick over-view -- I've clearly started answering questions already.  :)
[22:35] <kees> for people interested in getting involved, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved
[22:36] <kees> that covers the various subteams, and what each does.  We're low on people, so we'd love to have people join to help get things fixed and help test.  :)
[22:36] <kees> 21:36 < Azag> I am saying that, why a encrypted password can't be stolen
[22:37] <kees> presently, encrypted passwords are handled by specially-privileges processes.  As such, regular users do not have access to the process or the files they interact with
[22:38] <kees> for example /etc/shadow is not world-readable, and the various PAM helpers need to be run with elevated privileges to read it
[22:39] <kees> we've got a lot of time left, but I appear to be the last session for today.  :)
[22:39] <kees> If anyone has other questions, please feel free to join #ubuntu-hardened or to ask on the ubuntu-hardened mailing list.
[22:41] <kees> 21:40 < nealmcb> QUESTION: What good options are there (now or planned) for better authentication and authorization in Ubuntu?
[22:41] <kees> 21:40 < nealmcb> (than passwords)
[22:42] <kees> there have been discussions about fingerprint readers, and other "something you have" style authentications.  at present, passwords seem to remain the standard
[22:42] <kees> 21:41 < Rudd-O> QUESTION: addressing rootkits and the like, what kinds of tools are there available to aid in detection and cleanup, and how are
[22:42] <kees>                 they being integrated into ubuntu?
[22:43] <kees> kernel-level things have been added in 8.04 to make rootkits harder to get installed (kernel memory protections)
[22:44] <kees> as for detection and cleanup, most of the tools I know of are in the universe repository (chkrootkit, rkhunter, unhide)
[22:44] <kees> luckily, rootkits are becoming more and more rare.
[22:49] <kees> 21:48 < ubuntu_demon> QUESTION : You are saying that md5 salted passwords are adequate for now but do you think this will stay be the case for the next five years ? (because Hardy will be supported for five years)
[22:50] <kees> barring extreme breaks in the hashing function, md5 will probably be okay.  it tends to be less of an issue since only root has access to the file to begin with.  leaving salted md5 in the clear certainly makes me nervous.
[22:51] <kees> but, since we will likely have experience converting to the next cool hashing function, we'll be able to apply that to LTS as well, if it's needed.
[22:53] <kees> any missed questions?
[22:54] <kees> 21:53 < ZehRique> QUESTION: Concerning the nealmcb question, what about creating an authentication process like Brazilian banks, where the password is typed with mouse clicks on a java applet which shows the numbers and letters randomly positioned on the screen, to difficult some kind of password steal?
[22:54] <kees> there is no reason it can't be done for the gdm/kdm login screen -- it just requires someone to write it.  :)
[22:55] <kees> okay, thanks for listening to the session!  feel free to catch me on IRC if you think of anything else to ask.  :)  thanks!
[22:55] <jcastro> ok
[22:55] <jcastro> thanks everyone for coming!
[22:55] <jcastro> The sessions begin again at 1500UTC tomorrow