=== Moot2 is now known as MootBot === Mamarok_ is now known as Mamarok === persia_ is now known as persia [16:23] * persia will be giving a special packaging lesson on how to package scripts, webapps, and firmware installers in #ubuntu-classroom starting at 15:30 UTC today. [16:30] Welcome to the special session on packaging scripts, webapps, firmware installers, and other things without code. [16:31] First off, let's take a quick attendance. Please indicate your presence. [16:31] * sebner hugs persia =) [16:31] * Iulian waves [16:31] here [16:31] +1 [16:31] here [16:32] * ssweeny coughs [16:32] Great. We've passed the quorum of 5 active students :) [16:33] persia: what if there would be less? [16:33] >_> [16:33] So, this is about packaging those special types of package that don't have any source. [16:33] sebner: I'd reschedule. [16:33] persia: kk [16:33] The important thing to consider is how the typical meanings of "source package" and "binary package" apply in these cases. [16:34] Hello. I will be away, but logging. [16:34] There typically isn't anything to compile, and you just want to put the files on the target system. [16:34] So, at a high level, a "source" package is the set of files that is used to edit and maintain a package. [16:34] A "binary" package is the set of files that get installed on a user system. [16:35] Even where most of the files are the same, it is useful to maintain this distinction, because there may be some files (README, COPYING, etc.) that don't need to be installed on a user system. [16:35] Also, there may be special configuration changes that need to be applied to a user system, but which are not required for development. [16:36] By keeping separate source and binary packages, it becomes very easy to separate these files into the appropriate places, and improves the experience for both users and developers. [16:36] This is true even though the binary package may not have any actual binaries. [16:38] As an example, we're going to package the very simple script from http://paste.ubuntu.com/16605/ [16:38] Now, the first thing to notice is that upstream didn't license this script properly, so we need to ask upstream for a license. [16:39] so, see you next week? [16:40] lol [16:40] (three months pass) [16:40] So upstream finally provides http://paste.ubuntu.com/16607/ [16:40] This, we can package. [16:40] as upstream just sent us the script in a pastebin, we'll need to create an orig.tar.gz ourselves. [16:41] So we create a directory hello-host-0.1 [16:41] And we copy the script into the directory, and call it hello-host. [16:41] We then tar and compress the directory, and get hello-host-0.1.tar.gz [16:42] This needs to be renamed to hello-host_0.1.orig.tar.gz. [16:42] After we have the orig.tar.gz, we can start the packaging. [16:42] First, we'll create a debian/ directory. [16:42] Our first target will be copyright. [16:43] This needs to include information about the package license. [16:43] As this package doesn't have a homepage, we can get away with something simple. [16:46] http://paste.ubuntu.com/16608/ [16:46] (Note that those preferring machine-readable debian/copyright are welcome to do it that way) [16:46] (in fact, if someone wants to draft that, and post for the rest of the class, it would be appreciated) [16:47] Next, we'll need a debian/control. This is again fairly simple. Just use the minimum information. [16:47] I recommend using CDBS for this type of package, only because it means less typing, although those familiar with debhelper 7 may find that as easy a choice. [16:48] aie [16:49] http://paste.ubuntu.com/16609/ is a quick debian/control for our package. [16:49] Note that because it's just scripts, and we're not using any special handlers, we have to set all the Dependencies manually. [16:49] In this case, it's a bash script, so we depend on bash. [16:50] persia: is that necessary? [16:51] bash is in the minimal installation [16:51] sebner: I'm actually not sure. I know bash is no longer the default /bin/sh, but I don't know if it is still Priority: Essential. [16:51] ok [16:51] For something like a PHP script, it is much more important. [16:51] ok [16:52] we can convert it php later :-) [16:52] to php [16:52] mok0: Right :) [16:52] So, for this example, I'm using CDBS, so debian/rules looks like http://paste.ubuntu.com/16610/ [16:53] I use this mostly because I don't want to think about it, and will use the implied debhelper calls for most things. [16:53] Now comes the important part: this needs to be installed somewhere. [16:53] This is handled by the implied call to dh_install. [16:54] We create a debian/install file that specifies where the files go. Our example is http://paste.ubuntu.com/16611/ [16:54] Now this directory doesn't exist yet, so we need a debian/dirs to create it (http://paste.ubuntu.com/16612/) [16:55] OOps. I made a mistake with debian/install. It should really have been http://paste.ubuntu.com/16613/ [16:55] It is important not to have the leading / to make sure that it installs in the package, instead of the developer's system. [16:56] Now we have a package that installs the scripts into the right places, and has all the necessary bits to make a good package. [16:57] There are still a couple pieces missing: we probably want to create a manual page, as otherwise lintian will complain, and we'll never get it past REVU. [16:58] If we're packaging a firmware installer, or something that needs to initialise a database, we might want to do something with debconf or maintainer scripts. [16:58] And so on. [16:58] Now, any questions? [16:59] not yet =) [17:01] *silence* [17:01] OK. If there are no questions, I presume that you all are prepared to package random bash scripts, quick python bits, and so on. [17:02] persia: that was it? [17:02] If you get as far as trying to package an entire Ruby-on-Rails application, don't forget to install the necessary integration hooks for the webservers, and handle the DB startup and cleanup in the maintainer scripts. [17:02] sebner: Yep. Packaging scripts is pretty easy. Once the files are installed in the right place, the user is typically happy. [17:03] great [17:03] * sebner hugs persia :) [17:03] so but how do i know what i have to write in the certain scripts [17:03] The really tricky bit is understanding the difference between a "source" package and a "binary" package when the "binary" package looks like it contains source. [17:03] schmiedc: Which scripts? [17:04] for example the debian/control [17:04] schmiedc: OK. We created debian/copyright, debian/control, debian/rules, debian/changelog, and debian/install. [17:05] debian/rules can almost always be just the two lines for script packages. [17:05] debian/install is set up based on where the files need to end up. This is usually available in the upstream documentation. [17:05] Oh, and I forgot about debian/dirs. [17:06] debian/dirs needs to include all the directories used in debian/install. [17:06] debian/changelog is best created with dch --create [17:07] debian/copyright is often just a quick summary of: who packaged it and when, the authors, the copyright holders, the upstream license, and the packaging license. [17:07] debian/control is a bit trickier. Let's look at http://paste.ubuntu.com/16609/ carefully. [17:07] There are two stanzas, the source stanza and the binary stanza [17:08] The source stanza describes the source package, and the binary stanza the binary package. [17:08] For the source stanza, you need to set the Source: header to be the name of the package. [17:08] The Section header should match one of the package sections [17:08] * persia digs for the URL [17:09] http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections [17:09] Priority is almost always "optional" for new packages, although it can be "extra" if it breaks something (try not to do this) [17:09] The Maintainer is the person responsible for the package. [17:10] Build-Depends should be "cdbs": you shouldn't need anything else for a simple scripts package. [17:10] should debhelper be added? [17:10] Standards-Version: should match whatever the current standards are when you package it. [17:11] albert23: It's not required, as cdbs depends on debhelper. [17:11] lintian complained [17:11] If you use a feature from a newer debhelper than the version depended upon by CDBS, you can add a versioned depends. [17:12] albert23: You remind me, it's a good idea to add a debian/compat file containing any of "5", "6", or "7". [17:12] that was the other lintian complaint indeed [17:12] In which case, you want to add "debhelper (>= 5)" (or 6 or 7) to your Build-Depends. [17:12] albert23: Thanks for checking :) [17:13] Now, for the binary stanza, we again have the package name [17:13] scripts are always Architecture: all [17:14] As mentioned previously, you need to manually set the Depends: depending on what the scripts require. I tend to always include ${misc:Depends} just in case some of the CDBS magic requires something. [17:14] And the Description is as normal. [17:14] more information about writing control files is available from http://www.debian.org/doc/debian-policy/ch-controlfields.html [17:14] ok thxc [17:14] schmiedc: Does that answer it? [17:15] but architecture would be i368 and so on or? [17:15] yes [17:15] the thing is that i concider about getting involved [17:15] and haven't done any work yet [17:15] schmiedc: No point. As these are just scripts, it ought be architecture: all. That way they can work for anyone, regardless of their architecture (as long as they meet the Depends) [17:16] Any other questions? [17:16] yes but for other packages [17:16] schmiedc: #ubuntu-motu ;) [17:16] schmiedc: Oh, sure, for non-script packages, you might need to set architectures. "any" is a good choice. [17:16] am there .. [17:17] ok [17:18] Any other questions? Iulian? [17:18] not yet .. [17:18] ssweeny:? [17:18] I think, for consistency, it is better to name install and dirs -> .install and .dirs [17:18] when should the next lesson take place? [17:19] mok0: It works either way, but sure. [17:19] or to mention in the beginning to replace debian/ with the packages name [17:19] schmiedc: I tend to do ad-hoc lessons. You might check the MOTU School schedule on the wiki. [17:19] ok [17:20] schmiedc: No, you use debian/$(pacakgename).install and debian/$(packagename).dirs, etc. [17:20] ok [17:20] schmiedc: debian/ is sacred [17:22] where is a good place to look for simple upstreams to play with? [17:23] schmiedc: http://bashscripts.org/ has heaps of samples, although many are not suitable for packaging [17:23] ok [17:24] http://www.scripts.com/ has some python and perl (but be careful, some of these may be more than scripts) [17:25] ok thx [17:25] should be enought for today [17:25] On the other hand, aside from experimentation (for which variations on hello-host work just fine), you'd do best to wait until you found something so useful you didn't know how you worked without it before packaging it for general release. [17:25] have to do something for school [17:25] * persia rings the 300 second bell [17:26] Any last questions? [17:27] so you mean i should beginn straight with packaging for releases? [17:27] schmiedc: you can create a PPA on launchpad [17:27] schmiedc: If you have something worthwhile to package, why not? [17:27] PPAA? [17:28] PPA* === gordon is now known as Guest71188 [17:29] Thanks to everyone for attending, even with the short notice. Good luck with your script packaging, and don't hesitate to ask in #ubuntu-motu if you have any further questions. [17:29] whats PPA? [17:29] thanks persia [17:29] thanks [17:29] schmiedc: personal package archive [17:30] where do i create one? [17:30] schmiedc: on Launchpad.net [17:30] have an account .. [17:30] oh here [17:30] found it :) [17:30] schmiedc: :-) [17:30] schmiedc: you upload a "source package" [17:31] schmiedc: it compiles and publishes it for you [17:31] nice [17:31] schmiedc: yes, really cool [17:31] (or if it's a script, it organises it for user-release and publishes it for you) [17:31] schmiedc: so you can distribute apt-get'able software [17:32] persia: overtime ^^ [17:33] sebner: Yeah, well. Give me an apple! [17:33] gg [17:34] sebner: give persia a Mac [17:34] rofl rofl rofl [17:39] Ahh === schmiedc1 is now known as schmiedc [21:36] d