=== Nafai` is now known as Nafai [00:59] Hola, disculpen, alguien habla español? [01:00] quiero saber si en español habrán charlas relacionadas al Ubuntu developer week [01:04] Hola, disculpen, alguien habla español? [01:04] quiero saber si en español habrán charlas relacionadas al Ubuntu developer week [01:12] oi pessoal [01:12] to aqui no Campus Party [01:13] e vou ta participando do ubuntu-class [01:14] já fiz todas configs. que se pede no site do ubuntu-sp [01:14] espero que de certo... === Buster is now known as Guest7294 [03:03] creo que fue mala idea instalarme ubuntu 10.04 [03:05] how to ubuntu 10.04 to 9.10 ??? [03:06] Necesita instalar Ubuntu 9.10 nuevo. [03:10] nos vemos luego ubunteros [03:20] nhaines, hey [03:30] mhall119: heya. :) === \vish is now known as vish === squish is now known as Guest21770 [06:42] Hello, can someone upload yesterday's sessions please ? [06:43] yes please :) [06:51] oh silly me, it can be found on the irclogs site anyways ! [06:52] Severity1: http://irclogs.ubuntu.com/2010/01/25/#ubuntu-classroom.html [06:53] thanks AnAnt :D [06:54] lol which one is it? [06:55] it is the whole log of yesterday [06:55] better than nothing [06:55] oh === gnu is now known as Guest52316 [06:55] kay i guess i'll just have to skim through them :D === Thomas is now known as Guest828 [12:35] date -u [12:45] @now [12:45] Current time in Etc/UTC: January 26 2010, 12:45:17 [12:45] date -u is something you can type into a command terminal running on your machine === Guest58931 is now known as Hutley === the is now known as Guest75390 [15:14] dpm, soren: just so you can talk in here later on :) [15:14] Did the sessions start? [15:15] dholbach, ok, thanks! [15:15] Omar87: not yet, 45 minutes === dholbach changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Support in #ubuntu || https://wiki.ubuntu.com/Classroom || https://wiki.ubuntu.com/Packaging/Training || Upcoming: Mon 25 Jan - Fri 29 Jan 2010: https://wiki.ubuntu.com/UbuntuDeveloperWeek || Run 'date -u' in a terminal to find out the UTC time [15:19] (just added the link to ubuntu developer week) [15:20] Mornin all [15:23] dholbach: ta [15:23] de rien [15:23] dholbach: thans :) [15:23] thanks* === carlos is now known as Guest16855 === squishy is now known as Guest51759 [15:59] HELLO EVERYBODY! WELCOME TO DAY 2 of UBUNTU DEVELOPER WEEK! [15:59] yay [16:00] we'll kick off day two with a fantastic Frenchman, it's Thierry Carrez who will talk about Java libraries Packaging [16:00] one organisational note: [16:00] if you want to ask questions, please head to #ubuntu-classroom-chat - if you want to ask questions in any other language head into one of the irc channels listed at the bottom of https://wiki.ubuntu.com/UbuntuDeveloperWeek/ [16:00] THANKS [16:00] and enjoy day 2! [16:00] Let's get started ! [16:00] My name is Thierry Carrez, and I'm a member of the Ubuntu Server team. [16:01] This session will be about the packaging of Java libraries. [16:01] It assumes you already know the basics of Debian packaging and want to learn the specificities of Java library packaging. [16:01] We'll first see some basics about Java libraries and how they fit in Debian packaging [16:01] Then the java-specific issues we need to solve in our packaging work [16:01] Then we'll see the rules of java library packaging... [16:02] And we'll look at a few examples, in increasing order of complexity. [16:02] At the end of each section we'll do a quick Q&A... [16:02] Questions should be asked in #ubuntu-classroom-chat and will be relayed here. [16:02] OK, let's start ! [16:03] == Java libraries basics == [16:03] Java is an object-oriented language, so it makes use of object classes. [16:03] Those classes can be grouped inside class libraries, and shipped in a .jar file. [16:03] A JVM runs with a classpath that defines where classes can be found, and a classpath can point to JAR files. [16:03] Those JAR files are usually shipped together with the program that uses them. [16:04] But that results in code duplication, i.e. the same JAR file can be found in several packages. [16:04] That's bad, because bug fixes (and security fixes) cannot be applied once and for all. [16:04] In Linux distributions, we want to share the common code across applications, so we want to package Java libraries separately. [16:04] We follow a few rules, defined in Debian Java policy [16:04] http://www.debian.org/doc/packaging-manuals/java-policy/x105.html [16:05] Binary library packages are named libXXX-java. A fictional library called "hello" would be provided by a libhello-java package. [16:05] They install versioned JAR files in /usr/share/java (hello-1.0.jar) and a unversioned link should point to it [16:05] /usr/share/java/hello.jar -> /usr/share/java/hello-1.0.jar [16:06] Note that without installing a package and unzipping the JAR file, it can be difficult to tell exactly which classes it provides [16:06] So finding where a given class might be shipped would involve installing all the Java library packages and unzipping all the JARs that the distribution contains... [16:06] Fortunately I did that for you and published java-Contents.gz files that contain all classes in all jars in all packages ! [16:06] https://wiki.ubuntu.com/JavaTeam/JavaContents [16:07] So finding a given class in karmic is just a matter of downloading the karmic-java-Contents.gz file... [16:07] and do a "zgrep the.class.name karmic-java-Contents.gz" [16:07] OK, questions so far ? [16:08] < LumpyCustard> *QN: how often is this file updated? [16:08] I usually release it after each release [16:08] but you can regenerate it at will [16:09] the code is provided in the page I linked to. [16:09] Takes several hours, btw :) [16:09] < mscahill> QUESTION: this contains all java classes contained in which repository? main? universe and main? [16:09] main universe, multiverse [16:09] < luckyduck> QUESTION: how are the classes/jars added to the classpath? is that done by the ubuntu java env. or the startup scripts of packages? [16:09] the component is listed on each line [16:09] so you can filter output to only main packages if you want [16:10] startup scripts and packages usually take care of setting up the classpath for a given app [16:10] luckyduck: ^ [16:11] Let's move on :) [16:11] == Java-specific packaging issues == [16:11] The main issue with Java packaging is that in Debian packaging we need to build everything from source... [16:11] while most Java programs just build from already-built libraries shipped directly with their source [16:12] So we need to first make sure all those build-time libraries are already properly packaged. [16:12] And we also often need to patch the build system so that it uses the shared libraries in /usr/share/java instead of what it is used to. [16:12] Another issue is that Java "compiling" (which really is bytecode generation) generally requires the presence of a lot of Java libraries [16:13] And not all of them are already packaged. A given library might need 5 missing libraries, which in turn would require 10 others... [16:13] So packaging a seemingly simple Java stack can quickly turn into an exponential packaging game. [16:13] The last issue is that we provide a shared library set, with given version numbers. However, the library APIs can change even in minor releases... [16:14] And since Java software usually conveniently ships with its own version of the library, it doesn't care so much about staying compatible with the latest version. [16:14] Software A can require libhello-java>=2.1.14, while library B won't compile with libhello-java>=2.1... [16:14] We usually patch one to be compatible with the others, but that can quickly become a complicated game. [16:14] Questions, before we really start packaging ? [16:15] < LumpyCustard> QUESTION: Does building with Maven make this difficult? <-- this can be answered later if you like! [16:15] LumpyCustard: yes, maven makes it even more difficult [16:15] LumpyCustard: we'll come back to that later, but maven actually helps software to pick a very specific JAR version [16:16] rather than encouraging the use of the latest [16:17] OK, let's start packaging. [16:17] == Packaging libraries == [16:17] Here are a few debian/control rules that apply to Java libraries: [16:17] - Section should be "java" [16:17] - You should "Build-depends" on default-jdk [16:18] - The library binary package should "Depends" on default-jre-headless | javaN-runtime-headless [16:18] (replace N by the minimum level of Java needed) [16:18] Anticipating the question, how do I figure that out ? Looking at the level of the target Java code in the build system usually gives a clue: [16:18] target=1.6 means you should use "default-jre-headless | java6-runtime-headless" -- that's the default for code generated using default-jdk [16:19] target=1.5 -> "default-jre-headless | java5-runtime-headless" [16:19] target=1.4 -> "default-jre-headless | java2-runtime-headless" [16:19] When starting to package a library, you must investigate what build system it uses. [16:20] If there is a "build.xml" file, then it probably uses "ant", which is like a Java-oriented "make". [16:20] The Makefile is called build.xml and contains targets (in XML) that you can call with ant . [16:20] Sometimes there is no build system. [16:20] Sometimes, it uses maven, which is a complex build/integration system that handles both build rules and dependency management [16:21] Next step is to look at build dependencies. It's not always obvious which libraries are required for compilation. [16:21] You can look into the README, look into the build.xml, see if any .jar files are shipped withing the source... [16:21] Otherwise just try to compile it, it will fail with ClassNotFound errors... and use java-Contents.gz to find where those classes live. [16:22] Questions, before we move on to practical examples ? [16:23] OK, moving on, then [16:23] == Example 1: Simple library == [16:23] < LumpyCustard> QUESTION: Does building with Maven make this difficult? <-- this can be answered later if you like! [16:23] sorry [16:24] < mscahill> QUESTION: so you're referring to creating a deb of an existing application? [16:24] mscahill: creating a deb of a java library, to be more exact [16:24] mscahill: but applications aren't so different [16:24] mscahill: they just add a launcher, basically [16:25] < luckyduck> QUESTION: in gentoo it was very complicated to work with maven in ebuilds, since there was no automated way to pull in jars an app needed to compile (atleast during the time i was part of [16:25] gentoo java). how is that handled in ubuntu? [16:25] I'll come back to maven, but yes, it's a pain. [16:25] < dig> QUESTION: jar to deb? [16:26] dig: not sure I get the question, but yes, the idea is to make a deb that contains jars. [16:26] back to example 1 [16:27] < dig> QUESTION:i meant if i make a jar which has all the deps in it, it can be made to a deb easily right? [16:27] dig: no. We want to rebuild the jar from source. [16:27] dig: all packages in Ubuntu must be built from source [16:27] making a deb from a JAr file would be "from binary" [16:28] ok, really moving on now :) [16:28] Suppose we want to package a library called "easy", that uses "ant" to build and has no build dependencies [16:28] It uses a build.xml, and simply running "ant" builds build/easy-1.0.jar [16:28] We'll use the CDBS "ant" class to do all the work for us. [16:29] The debian/control file would be like: [16:29] http://pastebin.ubuntu.com/362512/ [16:29] And the debian/rules file is then as simple as: [16:29] http://pastebin.ubuntu.com/362514/ [16:29] We include the ant CDBS class on line 3 [16:29] JAVA_HOME on line 5 matches our "default-jdk" build-depend [16:30] Lines 8 to 10 take care of installing the JAR and the unversioned link to it. [16:30] Easy enough, if you already know a bit of debian packaging [16:30] The issue is, I couldn't find a single library as simple as that one. Let's look into real world examples now :) [16:30] This is the debian/rules file for "trove": [16:30] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/trove/lucid/annotate/head%3A/debian/rules [16:31] It's mostly identical to our easy one, except we had to specify a DEB_ANT_BUILD_TARGET, since just calling "ant" without argument wouldn't build anything [16:31] It also builds the Java documentation, so there are special rules to take care of the produced javadoc. [16:31] Questions ! [16:33] QUESTION does it just use javadoc? [16:33] well, it uses ant, which calls javadoc [16:33] see DEB_ANT_BUILD_TARGET := jar javadoc [16:33] that means it will call "ant jar javadoc" [16:33] if you look into the build.xml you'll find a "javadoc" target [16:34] that does ant magic to build the doc, by calling javadoc [16:34] we are just calling ant here. [16:34] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/trove/lucid/annotate/head%3A/build.xml#L167 [16:35] ^that's where the build.xml file specifies it. But that is part of upstream distribution, not written by us [16:35] OK, complexity level 2 now... [16:36] == Example 2: Build dependencies == [16:36] When you have build dependencies, you'll need to add the required libraries to the build classpath. [16:36] The CDBS ant class has a nifty mechanism for that, just add the required JAR names on a DEB_JARS line. [16:36] You can put JAR names (without path or extension, it will look in /usr/share/java) or complete paths. [16:37] See that example with the "jug" library: [16:37] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/jug/lucid/annotate/head%3A/debian/rules [16:37] line 11 [16:37] Also note that DEB_ANT_CHECK_TARGET lets you specify a build.xml target to be called for post-compilation tests. [16:38] The other thing you might need to do at that point is to patch the build.xml file to make it use the system classpath instead of a build.xml-specific one. [16:38] See line 16 of the build.xml patch needed for jug: [16:38] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/jug/lucid/annotate/head%3A/debian/patches/build-xml.diff [16:39] Quick tip, you can also pass "DEB_ANT_ARGS := -Dbuild.sysclasspath=last", that will make sure the system classpath is appended to any build.xml local classpath. [16:39] Questions ? [16:39] I don't know if this is too easy or too complex :) [16:41] ok, let's move on [16:41] QUESTION: I am completely new to this kind of stuff, but I sill want to learn. So, is this some kind of a markup language or something? [16:42] Omar87: depend on what you mean by "stuff". Is is the debian/control or the build.xml that looks like stuff to you ? [16:42] It's impossible to cover both debian packaging *and* java libraries packaging in a single hour, sorry :) [16:43] On to complexity level 3 ! [16:43] == Example 3: Write a build.xml == [16:43] Sometimes there will be no build.xml, or the provided build.xml will be so funny rewriting it is better than trying to use it. [16:43] Then you should provide your own debian/build.xml and point the CDBS ant class to it. [16:43] See that minimal debian/build.xml example for "mvel": [16:44] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mvel/lucid/annotate/head%3A/debian/build.xml [16:44] just takes classes, compiles them and makes a jar out of them [16:44] And here is the rules file that makes use of it (see DEB_ANT_BUILDFILE at line 10): [16:44] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/mvel/lucid/annotate/head%3A/debian/rules [16:44] Also note the passing of parameters to the build.xml file, using DEB_ANT_ARGS on lines 11-12. [16:45] Questions on this example ? [16:46] * ttx lets some time for students to catch up [16:46] Time for level 4, I guess [16:47] == Example 4: Shipping POM / maven-repo-helper == [16:47] That's starting to be interesting to LumpyCustard [16:47] Like I already said, maven is a build/integration system that handles both build rules and dependency management [16:47] It relies on a specific repository layout and dependency description files called .pom files. [16:48] Usually it just downloads dependencies from the Internet directly [16:48] We want it to use the system-installed libraries and not use internet for anything [16:48] because we want reproduceable builds, not depending on the state of internet at any given time [16:49] In order to support building packages using maven, we need to start shipping our libraries in a maven-compatible form. [16:49] Debian Java developers worked on a spec, it requires installing JARs and POM files in /usr/share/maven-repo [16:49] To ease that they created a maven-repo-helper package that provides convenient helpers: [16:50] mh_installjar will install a JAR in /usr/share/java and create all the necessary links, including the classic unversioned one [16:50] mh_installpoms will install POM files [16:50] See this debian/rules example for commons-beanutils, in particular lines 15-16: [16:50] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/commons-beanutils/lucid/annotate/head%3A/debian/rules [16:51] (this library isn't using maven to build, it's just installing itself in a maven-friendly way) [16:51] Those maven-friendly libraries allow "maven" to make use of the system installed libraries [16:52] Questions ? [16:52] that was the last example, we'll move now to more general Q&A about any subject you want... [16:52] < luckyduck> QUESTION: what is installed by the mh_installjar tools? [16:52] I'll talk a little about packaging stuff that uses maven, for LumpyCustard [16:53] mh_installjar makes sure that the jar is installed at the right place with links. For example: [16:54] easy.jar 1.0 gets installed in /usr/share/java/easy-1.0.jar [16:54] + the following symlinks: [16:54] /usr/share/java/easy.jar -> /usr/share/java/easy-1.0.jar [16:54] < luckyduck> QUESTION: a link from an debian/ubuntu package? [16:54] /usr/share/maven-repo/com/easycorp/easy/easy-1.0.jar -> /usr/share/java/easy-1.0.jar [16:54] /usr/share/maven-repo/com/easycorp/easy/easy-debian.jar -> /usr/share/java/easy-1.0.jar [16:55] yes, the jar and the links get installed by dpkg when installing the libeasy-java package [16:55] < SevenMachines> [QUESTION] I've seen packages that carry the actual source files inside a jar, is there any reasonable way to use patches in the packaging in that sort of case? [16:56] SevenMachines: the source should be repackaged as an orig.tar.gz [16:56] About maven, having more and more libraries maven-compatible finally allows to use maven in debian packaging [16:56] < LumpyCustard> QUESTION: Would there need to be a new in the application pom to use the jars already found on the system? [16:57] http://wiki.debian.org/Java/MavenBuilder [16:57] LumpyCustard: that's a good question [16:58] LumpyCustard: I'm far from being a maven expert. All I can say is that pom files are patched at install [16:58] and our maven is also patched to use /usr/share/maven-repo [16:59] The MavenBuilder link above points to the work in Debian to further support maven [16:59] it's still very much work in progress, since maven is so distribution-unfriendly (it's basically another packaging system) [16:59] ok, time is up [17:00] thanks everyone ! [17:00] next up is... [17:00] me. :-) [17:00] "Adding Ubuntu One support to your applications" :) [17:01] Led by the incredible Stuart Langridge [17:01] [SLIDE 1] [17:02] hm, that didn't work, that's kees's talk. never mind :) [17:02] Hi! I'm Stuart Langridge, from the Ubuntu One team, and this talk is called "Adding Ubuntu One support to your applications". [17:02] You can ask questions at any time in #ubuntu-classroom-chat. Please write QUESTION at the beginning of your question so I can see it more easily. I'll stop at the end of a section and answer some questions. [17:02] During this talk I'm going to explain the different ways your applications can take advantage of Ubuntu One... [17:03] ...talk about why you'd want to do that... [17:03] ...and give a couple of sneak previews of things that you can't *quite* do yet but will be able to do for Lucid 10.04, so you can be ready! [17:03] Firstly, though, remember that "integrating with Ubuntu One" isn't really the point; the point is to give features to your users that make their lives easier. [17:03] Now, obviously, using Ubuntu One will make you taller, it'll make you more attractive to the appropriate sex, and it'll make the sun shine more brightly, but remember that it's all about providing things that your users want... [17:04] ...and Ubuntu One gives you the infrastructure you need to do that. If it doesn't, come talk to us! [17:04] OK, so, the first thing is: files. [17:04] As you know, Ubuntu One automatically synchronises files in your Ubuntu One folder to Ubuntu One itself in the cloud and to all your other machines. [17:04] This means that you can take advantage of automatic file backup just by having your application save things to the filesystem! [17:05] Imagine that you want attachments that you receive by email to be stored online and backed up so you can get at them later. [17:05] [SLIDE 2] [17:05] (bah. ignore the slides. they're not my slides) [17:05] Most mail clients will already let you do this in some way. So, change the folder that these attachments are saved in to be an Ubuntu One folder and suddenly all your attachments are backed up online and available on every machine! [17:06] For example, there is a Thunderbird attachment called "Attachment Extractor" (https://addons.mozilla.org/en-US/thunderbird/addon/556) [17:06] Install it, select "Automatically extract attachments on email receipt" in Tools > AttachmentExtractor settings > Auto-Extract, and set the "Save Path for Attachments" to /home/YOU/Ubuntu One/Mail Attachments, and that's all you need! [17:07] Similarly, if you want off-site backups of your computer, then you can install one of the many simple backup programs, like backintime (http://backintime.le-web.org/) and choose the backup folder to be inside your Ubuntu One folder. [17:07] With no extra effort you've got off-site online backups which you can get at from any of your machines or from the web. [17:07] As another example, imagine you've built yourself a digital picture frame out of an old laptop, which is a pretty cool project for your weekends. How do you get the photos on it? [17:08] [SLIDE 3] [17:08] Well, when I did this, I created a new Ubuntu One user for the picture frame, and then I shared a folder with that picture frame user through Ubuntu One. [17:08] The picture frame just did this: eog --slideshow "/home/pictureframe/Ubuntu One/Shared With Me/pictures from Stuart Langridge" [17:09] and then to add new pictures to the frame, I just copy them into the folder that I shared. [17:09] I could share that folder with anyone else, too, and allow them to write to it, and then they'd be able to add pictures to the frame too! [17:11] The way I'll do this from 10.04 Lucid onwards is to use the new User Defined Folders feature, where any folder, anywhere, can be designated as an Ubuntu One synced folder [17:11] and you can elect to have some folders but not others synced to particular machines [17:11] So I'd create my "digital picture frame" folder in my home folder (or wherever), and then mark it as a UDF. [17:11] Then on the picture frame itself, I'd sign into Ubuntu One, and say that I only want to subscribe to that particular UDF and not any of the others. [17:12] so then files that I put into "digital picture frame" on my laptop will be synced to the picture frame [17:12] and the picture frame just displays all the files in that folder [17:12] ta daaah, it Just Works. [17:12] QUESTION: Is there a full GObject U1 API for storing data, settings etc. or do we have to make use of ~/Ubuntu One/ for now? [17:13] A much-requested feature which will be available in Lucid is "public files", the ability to publish an Ubuntu One-synchronised file to a public URL so anyone can get at it. [17:14] This is useful for the user directly; they can easily make a file available to the world. [17:14] It's also really useful for applications, because you can now build one-click publish-to-the-world directly into your apps. [17:14] Imagine that your app is Shutter, which is like the standard Gnome Screenshot tool on steroids. [17:14] If you install Shutter and then hit the Print Screen button, it'll take a picture of your screen. [17:15] One of the main reasons people take screenshots of their screen is to show them to other people, which makes this a perfect case for publishing the screenshot to a URL so anyone can see it. [17:15] So, in Shutter (or your similar app), provide a "Publish with Ubuntu One" button. [17:15] [SLIDE 4] [17:15] That button should do the following: [17:15] 1. Save the file into the user's Ubuntu One folder (just save, as normal) [17:15] 2. Call the publishing API [17:15] The publishing API will be D-Bus; I can't confirm exactly how it will work, yet, because the team are still constructing it, but keep your eyes open for more details! [17:15] This shows a basic principle of Ubuntu One's design; pretty much anything you can do explicitly, like publish a file, or share a file, can also be done using the D-Bus API from applications. [17:16] I'll answer some questions here about using Ubuntu One file sync in your apps. [17:16] kklimonda|lernid> QUESTION: Is there a full GObject U1 API for storing data, settings etc. or do we have to make use of ~/Ubuntu One/ for now? [17:17] Data and settings are best stored in desktopcouch if you want to take advantage of all that lovely synchronization goodness; there are benefits to doing it that way, and I'll talk about desktopcouch in a bit. [17:17] But you can certainly store settings files in ~/Ubuntu One if you want to [17:17] and obviously actual data *content* that your apps work on, your documents and so on, are stored in ~/Ubuntu One [17:18] mhall119|work> QUESTION: in 10.04 you will be allowed to have multiple sync folders outside of ~/Ubuntu One/ ? [17:18] mhall119|work, yep, you sure will. UDFs (user defined folders) are a big feature that'll land in 10.04. [17:18] strycore89> QUESTION : will we be able to share single files and not whole directories ? [17:19] No. Sharing is done folder-by-folder, and we're not planning on changing that. [17:19] mhall119|work> QUESTION: right now the local folder names match the online folder names. With the ability to have multiple sync folders, how are naming conflicts resolved? [17:19] I'm not sure what you mean here by "naming conflicts"; maybe we can pick that point up after the session, or later on? [17:19] foobob> QUESTION: are you thinking of giving some GB more to the free plan? [17:20] I don't believe we are at the moment, no. [17:20] yltsrc> QUESTION: will be ready symlincs in U1? === zen is now known as Guest25466 [17:21] yltsrc, UDFs, being able to mark any folder as Ubuntu One synchronized, takes the place of symlinks. If you use, er, some alternative to Ubuntu One and you're used to putting a symlink in, say, ~/SyncedFolder which points at ~/SomeOtherFolder to get SomeOtherFolder synced, you don't need to do that in Ubuntu One; you just mark SomeOtherFolder as a UDF and it will be synced for you. [17:22] lantash49> QUESTION: Will there be more detailed specification w.r.t storing settings in ~/Ubuntu\ One? Storing them there directly seems to conflict with the XDG directory specs. [17:22] lantash49, one obvious approach to this is to mark XDG_CONFIG_DIR and XDG_DATA_DIR as UDFs, so they're synchronized across your computers. [17:23] yltsrc> QUESTION: i want participate in testing U1, how can I do it? [17:23] Drop into #ubuntuone and talk to the team about what's going on and how you can help; we've had some really helpful community members already, like rtgz, who's done tons of stuff [17:23] taj> QUESTION: Are there any plans to make U1 cross-platform? [17:24] There's a sprint at PyCon US to port Ubuntu One file sharing to Windows: http://us.pycon.org/2010/sprints/projects/ubuntuone/ [17:24] and mandel, another incredible community member, is currently porting desktopcouch to Windows: http://www.themacaque.com/?p=372 [17:25] both of those projects are great, and if you can help that'd be wonderful [17:25] mhall119|work> QUESTION: If I put a symlink inside of a UDF, that points elsewhere, does U1 sync that as a link, or as a copy of what is linked to? [17:25] it's synced as a symlink. [17:26] right, let's carry on :) [17:26] The second leg of Ubuntu One for developers is desktopcouch, the CouchDB on your desktop. [17:26] If you missed my last Ubuntu Developer Week talk about the basics of desktopcouch and what it's for, you can read it at http://www.kryogenix.org/days/2009/09/03/desktop-couch-irc-talk [17:26] In fact, you can read all the desktopcouch documentation at http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/, and you should do so :-) [17:27] The bit that's most likely to be relevant here is the "I am a developer, and I want the applications I write to store data in and work with desktopcouch" section. It contains much that is relevant to this talk! [17:27] http://arstechnica.com/open-source/guides/2009/12/code-tutorial-make-your-application-sync-with-ubuntu-one.ars/1 is a really great guide, written by segphault, of how to support cloud synchronization of data in your applications. [17:27] Essentially, if you use desktopcouch to store your application's data, instead of using sqlite or flat files, then the data will be synchronised between all your machines *without you having to do anything*. [17:27] [SLIDE 5] [17:28] So your app will work the same on all your machines with no effort. [17:28] To store a record in desktopcouch, simply do: [17:28] >>> from desktopcouch.records.server import CouchDatabase [17:28] >>> from desktopcouch.records.record import Record [17:28] >>> db = CouchDatabase('testing', create=True) [17:28] >>> r = Record({'key':'value'}, record_type='http://example.com/testrecord') [17:28] >>> record_id = db.put_record(r) [17:28] and to get it back, by record ID: [17:28] >>> fetched = db.get_record(record_id) [17:28] >>> print fetched['key'] [17:28] 'value' [17:28] The Quickly project, for writing Ubuntu apps, have created "widgets" that use desktopcouch without you having to think about it. CouchGrid, for example: [17:29] >>> from desktopcouch.records.couchgrid import CouchGrid [17:29] >>> keys=["key","another key"] # to label the columns [17:29] >>> couchgrid = CouchGrid(db_name, record_type=record_type, keys=keys) [17:29] >>> mywindow.pack_start(couchgrid) [17:29] and then you have a CouchGrid, which is a data table where all the data is automatically retrieved from desktopcouch and stored back into desktopcouch when changed [17:30] http://www.youtube.com/user/calorielookup#p/a/u/0/Vwr5Xw5ZrIE has a video demonstrating couchgrids [17:30] You don't have to know anything about desktopcouch at all for this! Just use the widget and your data will be saved to the database and synced to your different machines with no effort or code on your part at all. [17:31] https://wiki.ubuntu.com/Quickly/Snippets has a few more examples of using desktopcouch from Python and from Quickly apps. [17:31] So, cloud-enable your apps! Let's see my song ratings in Rhythmbox or Banshee or Amarok or Exaile or Quod Libet appear on all of my machines. Let's see my Chrome bookmarks appear everywhere, like my Firefox bookmarks already do. [17:31] Remember, too, that apps can share data. If you want to store song ratings for Amarok in desktopcouch, don't make that storage Amarok-specific; that way, if I decide to switch to Quod Libet I don't have to re-rate all my songs! [17:31] I'm happy to answer questions about sharing of data between apps if you have them. [17:31] Also, I'll stop now to take some questions about desktopcouch generally. [17:32] andypiper> QUESTION: what is Quickly....?! [17:32] Quickly is an app that helps you make Ubuntu apps really...quickly [17:33] it takes care of putting together the framework of an application for you, and it makes a deb package for you and uploads the code to launchpad, etc. All the boring stuff that you don't care about when you just want to get your app done [17:33] the next session, by didrocks, is about quickly, so I'd stick around for that :-) [17:34] https://wiki.ubuntu.com/Quickly has more [17:34] yltsrc> QUESTION: is available any standard for database name? And how resolve conflicts with different application? [17:34] yltsrc, there isn't a standard, as such, for database names, because what the desktopcouch project is trying to avoid is laying down lots of standards that you Must Comply With [17:34] we're a "rough consensus and running code" sort of group :-) [17:35] the best place to have discussions about that sort of thing is at http://groups.google.com/group/desktop-couchdb which is the desktopcouch mailing list [17:35] dekstopcouch records are deliberately set up to have two sections, a "main section" and an "application specific" section [17:36] so the idea is that apps co-operate on the main section and store app-specific data in the app-specific section [17:36] for example, Evolution contacts sync in Ubuntu One is done by Evolution storing your contact data in desktopcouch [17:36] but the format for a contact has been defined [17:37] and the contacts are stored in a database in desktopcouch called "contacts" [17:37] so Thunderbird, for example, could *also* sync its contacts to that same database, in the same format [17:37] and Evolution stores Evo-specific data (like, say, an internal ID) for a contact record in the app-specific part of the contact record [17:37] and Thunderbird would do the same [17:38] what this means is that if you decide to switch from Evolution to Thunderbird, you've still got your addressbook! You don't have to export it and re-import it every time you move between applications [17:38] yltsrc> QUESTION: U1 require python (2.6). Is any plans to run it on python3? [17:38] I don't believe there is, at the moment, no. [17:38] b1ackcr0w> QUESTION: SpiderOak is said to be going Open Source soon, are there oppertunities to integrate their services with U1? [17:39] There could be, certainly. I haven't looked into that in detail myself, but I'll be sure and bring it up! [17:39] mhall119|work> QUESTION: I want to hack on the server-part of U1, short of becoming a Canonical employee, what can I do? [17:39] At the moment, you can't, I'm afraid. The source code for the server part of file synchronization is closed. [17:40] The source code for the server part of desktopcouch is CouchDB, though, and work on that is perfectly doable. [17:40] We worked closely with the CouchDB upstream project to make sure that all the changes we needed to use CouchDB in Ubuntu One were part of the main CouchDB trunk. [17:40] yltsrc> Is avalably any FEATURE ROADMAP for U1? [17:41] that's...sorta what this talk is :) I can see how it might be useful to have a more formal statement of "what's coming up", though. I'll bring that up with the team. [17:42] yltsrc> QUESTION: is U1 uses dbus? and how i can extend my application to use it? [17:43] Yes. The syncdaemon, which is the bit that handles file synchronization, exposes D-Bus commands for almost everything it does. [17:43] OK, I'll carry on. [17:43] Since desktopcouch is a CouchDB, and since your data is synchronised not only to your other machines but up to the cloud as well, this opens up the intriguing possibility that you can build a web app that can share data with your desktop app. [17:43] Ubuntu One's CouchDB uses OAuth for authentication. [17:43] This means that your web app can ask permission from the user to read your desktop app's CouchDB data directly from Ubuntu One. [17:44] So the data that appears in your desktop app can also be available to that user on the web. [17:44] This is a pretty new area, so nobody's using it yet, but it's possible. [17:44] You use OpenID to log the user in to your web app using Ubuntu One -- you may have seen "log in with Twitter" buttons, or "Facebook Connect", which work on the same principle. [17:44] Once that's done, your web app can then request permission to read the user's CouchDB database to get at the data that your *desktop* app stored there. [17:44] So, if we think about the song ratings example above, you can build a web application that can show all the song ratings that the user has entered and allow them to be edited. [17:45] Your users can then manage their song ratings or playlists or whatever else you've stored directly from a web interface if they're not at their actual computer. [17:45] Sharing data between web apps and desktop apps is quite hard, and not many people are doing it, so this is a chance to offer a feature that no-one else has! [17:46] DesktopCouch plus web apps give you the ability to share that data without you having to do any extra work. [17:46] This also gives you the ability to offer mobile apps as a web interface, so people can work with their data from their smartphone and see their work reflected on their desktop when they get back to it. [17:47] Are there any questions about how linking up desktop apps and web apps would work? [17:48]