15:03:24 <sdziallas> #startmeeting
15:03:24 <zodbot> Meeting started Wed Jan  6 15:03:24 2010 UTC.  The chair is sdziallas. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:32 <sdziallas> #chair mchua sdziallas
15:03:32 <zodbot> Current chairs: mchua sdziallas
15:03:50 * mchua is your friendly neighborhood archivist today
15:03:58 <sdziallas> #topic Fedora Sugar Packaging Session
15:04:25 <sdziallas> I guess we don't necessarily need a roll call, so we should probably just get started.
15:04:41 <cmpahar> although, hello :)
15:04:54 * sdziallas waves
15:05:16 <aeperezt> hello
15:05:17 * walterbender waves
15:06:04 <sdziallas> cool! that's already some folks. should we wait for anybody or start now?
15:06:21 <cmpahar> i think we should w8 for a couple of minutes
15:06:28 * jdob waves
15:06:52 * Boe08 waves
15:06:54 <sdziallas> okay, let's give people another two or three minutes to drop by.
15:07:04 <sdziallas> now that's what I call a crowd :)
15:07:13 <mchua> should we do some setup or intro in the meantime?
15:07:40 <tpwnz> yea i think that sounds good, I'd like to know if I'm all setup properly for what we are doing today
15:07:45 <sdziallas> mchua: sounds good
15:07:53 <sdziallas> setup first, then intros.
15:08:17 <sdziallas> what we'll need is gobby (which you can get here: http://gobby.0x539.de/trac/)
15:08:41 <Boe08> dont use the 0.4.93 version
15:08:54 <Boe08> use a pre 0.4.90 version
15:09:03 <sdziallas> if you're on Windows, grab the stable one. if you're on Fedora, just yum install gobby.
15:09:35 <mchua> Boe08: why is that?
15:10:13 <sdziallas> Fedora users could profit from doing yum groupinstall fedora-packager, too. but that's not required and will just allow you to test things on your own machine.
15:10:24 <sdziallas> mchua: we figured that the server on sunjammer only works with the stable version.
15:10:35 <Boe08> mchua: i had troubles yesterday when running the 0.4.93 version on windows so i hopped on the irc channel listed on their site and someone there said that sunjammer.sugarlabs.org runs a pre 0.4.90 version and theres a compatability break between them
15:11:01 <mchua> Boe08: Ah, okay, gotcha. thanks!
15:11:08 <Boe08> mchua: np
15:11:35 <sdziallas> Okay, that's already it for required setup - if you've gobby running, make sure to connect to our server, which is: sunjammer.sugarlabs.org
15:11:49 <sdziallas> (more details will follow in-session)
15:12:05 * mchua notes that yum groupinstall fedora-packager takes a little while depending on your connection speed (on my machine, it's 20 packages and 20mb total) so if you want it you might want to do it now.
15:12:23 <sdziallas> mchua: thanks for the heads-up! :)
15:12:40 <mchua> whoops, s/20mb/13mb but still.
15:12:46 <sdziallas> aside from that, I guess a quick intro can't hurt, before we dive into the topic.
15:13:18 <sdziallas> mchua is... awesome, because she has kindly agreed to take snapshots of what we'll be doing in gobby.
15:13:53 <mchua> It'll all be available in a git repo you can check out and flip through revisions of when we're done with the class.
15:14:07 <tpwnz> cool, ty
15:14:23 <mchua> We'll note in this channel when we save a revision, so you can sync the conversation here with what's happening in the spec file.
15:14:34 <mchua> (Will be using line numbers to refer to things, etc.)
15:15:10 <sdziallas> and I'm... well a German high school senior (so far the official stuff) who's wrangling Sugar on a Stick - which might have crossed your way at some point already. I've started this Fedora Sugar effort with a few folks, and we're trying to get more of Sugar into Fedora to reach more people, but also to make it easier to use Sugar.
15:15:54 <sdziallas> so yes. that's it for the intro. one last thing before we start: make sure to ask questions at any time!
15:16:27 <sdziallas> whenever there's something that you want explained more, just shout here.
15:16:38 * mchua wonders if people here know what packaging is (not sure what background folks come in with)
15:16:56 <cmpahar> mchua, good thought :P
15:17:03 <Boe08> sdziallas: 1st question! whats packaging?
15:17:17 <sdziallas> Boe08: awesome, all questions to me :)
15:17:35 <sdziallas> Packaging means basically the process of preparing an application to make it ready for inclusion in Fedora.
15:18:01 <sdziallas> So the overall goal of packaging is that the user will be able to select the application *you* packaged in the end directly through the Add/Remove Packages interface.
15:18:24 <sdziallas> Technically speaking, it means the process of creating an .rpm file from the application's source.
15:18:33 <sdziallas> Does this make sense?
15:18:42 <sdziallas> Oh, wait.
15:18:50 <sdziallas> Actually, I'll tell you why it's required.
15:19:04 <sdziallas> The cool thing about packaged applications is that they follow dependencies.
15:19:10 <jdob> sdziallas: isnt sugar already a package in fedora?
15:19:31 * mchua notes that packaging also happens for things other than Fedora - for Fedora (and several other distros) you make .rpms, there are also other formats like .deb that other distros use.
15:19:37 <sdziallas> So if you install Firefox on your Fedora system, it'll pull all kinds of packages that Firefox requires - you don't need to install them manually.
15:20:17 <sdziallas> jdob: that is correct! however, we can always use more help :) and this session will be especially about the activities, so the applications for sugar, which are packaged seperately (each itself)
15:20:46 <jdob> ok, one more question and i'll be quiet... how is this related to sugar on a stick?
15:20:56 <jdob> is that running fedora currently?
15:21:13 <mchua> Sugar also has a lot of dependencies that need to be packaged (which they already are) and maintained (which maintainers are typically always looking for help with).
15:21:21 <sdziallas> jdob: (great question!) exactly. Sugar on a Stick is based on Fedora and makes some slight modifications.
15:21:41 <sdziallas> So by packaging activities for Fedora, Sugar on a Stick directly profits.
15:21:42 <jdob> is there a non-stick version? or is the stick one just a Live CD?
15:22:08 <sdziallas> jdob: it's an image you can burn onto a CD or put onto your USB key, so both works.
15:22:10 <jdob> i ask because I went to download it yesterday and didnt see just a link to a live cd/installation ISO
15:22:14 <jdob> ok, cool, thanks  :D
15:22:17 * jdob shuts up now
15:22:31 * sdziallas grins
15:22:50 <sdziallas> so we'll start with getting your system ready.
15:23:12 <sdziallas> once you've installed the fedora-packager group, you've already the required tools for packaging installed.
15:23:48 <sdziallas> now packaging basically means taking the source of an application and writing an appropriate .spec file.
15:24:08 <sdziallas> A .spec file is the file that tells the tools you just installed what to do with the source.
15:24:30 <sdziallas> In a way, it's a recipe.
15:24:50 <mchua> #link https://fedoraproject.org/wiki/PackageMaintainers has a lot (actually, possibly an overwhelming amount) of resources about packaging if you want to explore around on the side.
15:25:06 <sdziallas> To keep everything in some structured way, you'll want to run the following command in your home directory: rpmdev-setuptree
15:25:24 <mchua> #info yum groupinstall fedora-packager
15:25:35 <sdziallas> #info rpmdev-setuptree
15:25:41 <sdziallas> that will create a directory called rpmbuild in your home folder, as well as sub-folders for .spec and source files.
15:25:54 <sdziallas> (if anybody wants to do that now, we'll hang on for a sec.)
15:26:15 <mchua> sdziallas: do you need to be a programmer in order to package? you mentioned working with source.
15:26:23 <sdziallas> mchua: nope, not at all!
15:26:43 <sdziallas> mchua: you might need to get in contact with the programmers, but they don't bite (trust me!).
15:27:00 <sdziallas> packaging an application doesn't require any programming knowledge.
15:27:24 <mchua> what kind of knowledge does it require?
15:27:58 <sdziallas> mchua: it follows a certain process which you'll learn today. so it means that you can't randomly throw stuff together, but need to follow some guidelines - which isn't really hard, though.
15:28:06 <Cheezmeister> How similar are different packaging systems (apt, rpm, ???)
15:28:11 <jdob> its a good skill to have, a lot of people are scared of packaging
15:28:33 <adimania> jdob: +1
15:28:59 <sdziallas> Cheezmeister: I haven't worked with apt before. From their goal, they're all somewhat similar. However, each distribution might have different "guidelines" (though you'll need to write .spec files for all .rpm based distros).
15:29:11 <sdziallas> jdob: I'll do my best to take fear away today ;)
15:29:14 <mchua> Off the top of my head, things I've found useful to know for packaging: knowing what a version control system is (you'll be using CVS), knowing what a bugtracking/ticketing system is (you'll be using bugzilla), and the habit of searching for the text of error messages. ;)
15:29:27 <mchua> Oh, and IRC. IRC is always helpful for asking questions.
15:29:34 <mchua> but if you're here you know that already. ;)
15:30:02 <jdob> Cheezmeister: i used to be a pretty heavy ubuntu guy, different syntax for apt, but feels very similar
15:30:23 <jdob> biggest different is that apt will sometimes prompt you with installation questions, RPM doesnt like that
15:30:35 <jdob> i *think* technically RPM can, but they frown on it
15:30:42 <Cheezmeister> jdob: Oh, OK.
15:31:20 <tpwnz> I apologize if is a dumb question but if we're using windows where do we get the rpmdev-setuptree
15:31:40 <sdziallas> tpwnz: no dumb question ;) well, you'll need a Fedora machine (sorry!)
15:32:05 <Boe08> tpwnz: you could develop using sugar on a stick, or using a VM
15:32:24 <sdziallas> (or a Fedora Live CD) - but it doesn't hurt if you don't do it know, you can always later.
15:32:49 <tpwnz> yea i'll boot up my vm fedora i just wasn't sure if there was a way to do it on windows
15:32:55 <tpwnz> ty
15:33:33 <sdziallas> okay, so have we taken care of the pre-action questions?
15:33:49 <sdziallas> (if not, shout now!)
15:34:14 <sdziallas> looks good.
15:34:32 <sdziallas> we'll work today on packaging walterbender's VisualMatch activity.
15:34:35 <aeperezt> gobby what server will we connect
15:34:44 <sdziallas> aeperezt: it's sunjammer.sugarlabs.org
15:34:56 <mchua> #info today's gobby server is sunjammer.sugarlabs.org
15:35:08 <aeperezt> thanks
15:35:21 <sdziallas> #info goal is to package the visualmatch activity
15:35:37 <sdziallas> #link http://wiki.sugarlabs.org/go/Activities/VisualMatch
15:35:47 <sdziallas> (this is if you want to have a quick look at it)
15:36:04 <sdziallas> so for packaging an activity, you'll obviously need the source code.
15:36:10 * walterbender is working on a new version :)
15:36:32 * sdziallas notes that walterbender is awesome at releasing new versions :)
15:36:51 <sdziallas> if you've done rpmdev-setuptree, you'll notice in your rpmbuild folder the following directories:
15:37:09 <sdziallas> BUILD RPMS SOURCES SPECS SRPMS
15:37:45 <sdziallas> activity source code can usually be found either on activities.sugarlabs.org or download.sugarlabs.org
15:37:57 <sdziallas> we're going to use the tarballs from download.sugarlabs.org for starters.
15:38:05 <sdziallas> #link http://download.sugarlabs.org/sources/honey/Visualmatch/
15:38:30 <sdziallas> you'll want to download the latest tarball from there and throw it in the SOURCES directory
15:38:46 <sdziallas> (if you don't have a Fedora machine present, just imagine you'd do it now) ;)
15:39:00 * Boe08 closes eyes and pretends really hard
15:39:17 <coolestdude1> X_X
15:39:21 <sdziallas> so I said we'd need the source code and a .spec file to get an .rpm package.
15:39:44 <sdziallas> now comes what takes the most time. the creation of the .spec file. I'm going to jump over into gobby.
15:39:49 * mchua does "cd rpmbuild/SOURCES; wget
15:39:57 <mchua> whoops
15:39:59 <mchua> cd rpmbuild/SOURCES
15:40:01 <mchua> wget
15:40:06 * mchua fails at copypaste today
15:40:11 <sdziallas> #info cd rpmbuild/SOURCES; wget
15:40:15 <mchua> wget http://download.sugarlabs.org/sources/honey/Visualmatch/VisualMatch-15.tar.bz2
15:40:20 <mchua> THERE WE GO
15:40:37 <sdziallas> please don't use the gobby chat, as it won't get logged (you can close the gobby chat using the window tab)
15:40:42 <mchua> (which is the most recent as of right now; if you're reading these logs later you'll want to check for the most recent source at the time.)
15:40:53 <sdziallas> (we'll use IRC for communication and gobby for collaboration)
15:41:20 <mchua> So right now, I have VisualMatch-15.tar.bzt sitting in my rpmbuild/SOURCES directory.
15:41:28 <mchua> erp. VisualMatch-15-tar.bz2.
15:41:40 <sdziallas> I've created an empty document called sugar-visualmatch.spec which you can join by enabling the document list in the window tab.
15:42:11 <sdziallas> (all sugar activities need to be named sugar-* in Fedora)
15:42:14 <mchua> sdziallas: where should we save this file?
15:42:28 <mchua> sdziallas: is the name of the spec going to be the name of the package?
15:42:36 <sdziallas> mchua: you can save the file from time to time. it should get into the SPECS folder.
15:42:40 <sdziallas> mchua: indeed!
15:42:48 <mchua> Ok, lemme get the spec file in and versioned.
15:43:02 <sdziallas> so if your spec is named sugar-visualmatch, what you'll get as a user later is the sugar-visualmatch package.
15:43:17 * sdziallas crosses fingers and hopes everything makes sense so far.
15:43:47 <sdziallas> (if you've any issues with gobby, please shout)
15:44:28 <sdziallas> allright-y.
15:44:41 <tpwnz> i'm connected to the server, but how do i open ur document
15:44:43 <tpwnz> or can i
15:45:01 <mchua> #info COMMIT 01
15:45:07 <Boe08> tpwnz: at the top select window and make sure document list is checked
15:45:22 <Boe08> tpwnz: then select the only document on the list and click subscribe
15:45:27 <tpwnz> ty
15:45:29 * jdob can see the document
15:45:41 <mchua> (that's an indication I've made a commit to the git repo we're using to archive our progress on the spec - right now it is an empty spec.)
15:45:50 <delhage> it's still empty right?
15:45:55 <Boe08> yes
15:46:11 <sdziallas> awesome!
15:46:17 * Boe08 notes that everyone on gobby is subscribed to the document (except walter :P)
15:46:48 <sdziallas> now I'll tell you a command that gives you already a basic skeleton of a .spec file.
15:47:17 <sdziallas> if you execute rpmdev-newspec sugar-visualmatch, that'll throw a .spec file with the right name into your current directory.
15:47:52 <sdziallas> #info rpmdev-newspec sugar-visualmatch
15:47:59 <sdziallas> I've copied the contents into gobby.
15:48:10 <delhage> cool (I use to use emacs for that)
15:48:36 <sdziallas> #link https://fedoraproject.org/wiki/How_to_create_an_RPM_package has more detailed instructions about creating packages - you might want to read that after the session in case you're interested.
15:48:50 <mchua> #info COMMIT 02 - output of rpmdev-newspec sugar-visualmatc
15:48:52 <sdziallas> delhage: emcas, vim, gedit... should all work for creating .spec files :)
15:48:58 <mchua> argh. visualmatch. I can't type today.
15:49:19 <sdziallas> so what we'll do is we'll start at the top and work through each of the fields listed in the file.
15:49:29 <delhage> sdziallas: emacs will create such a tempate if you give it a *.spec filename
15:50:01 <sdziallas> delhage: that's nice, indeed!
15:50:04 <delhage> ( was what I meant )
15:50:17 <sdziallas> (though it won't pull me away from using... you know)
15:50:24 <delhage> hehe
15:50:35 <delhage> rpmdev-newspec is indeed easier
15:50:56 * sdziallas starts at the top:
15:51:04 <sdziallas> the name is already pretty clear, it filled that in automatically.
15:51:13 <sdziallas> so the next one is the version.
15:51:17 <coolestdude1> room: i have a general question that i was waiting for all the info in the document to pop up for what makes these "spec" files individual to each project and why cant they be individualized like done automatically
15:52:11 <mxd> good question
15:52:13 <sdziallas> coolestdude1: sugar activities are pretty simple to package. so you can fill most of the stuff in easily. if you look at firefox's .spec file, you'll notice that it requires quite some handwork.
15:52:44 <mchua> coolestdude1: A spec is sort of like an install script - there's a lot that can be the same from package to package, but things like "what other pieces of software does this depend on? which directory should these files go in?" can vary from program to program.
15:52:56 <coolestdude1> so the extra packages that the source needs will be included in there some how...
15:53:33 <sdziallas> coolestdude1: well, they'll be specified (or even automatically detected, so that they get directly pulled as .rpms, once the user attempts to install the package)
15:53:39 <mchua> coolestdude1: "what scripts and commands do I need to install and configure this? is the licensing of this program and all its dependencies OK? what is the download link for the source code?" and that sort of thing, too.
15:54:03 <mchua> coolestdude1: that does imply that all the dependencies for a package need to be packaged before a package will work.
15:55:26 <sdziallas> does this answer your question?
15:55:32 <coolestdude1> yes
15:55:36 <sdziallas> okay, cool!
15:55:47 <sdziallas> so I'll talk a bit about the various sections there.
15:55:52 <sdziallas> there's the version.
15:56:09 <sdziallas> you've just downloaded the VisualMatch tarball which says it's... version 15.
15:56:15 <mchua> coolestdude1: another way of thinking about it is that making a spec file is doing all the stuff that *can't* be automated the first time so that it is entirely automated for everybody else forever after. ;)
15:56:17 <sdziallas> so let's put a 15 in there.
15:57:02 <sdziallas> an important thing to distinguish is the Release tag and the Version one.
15:57:31 <sdziallas> the Version one contains the version the developer has released - in this case, it was walterbender releasing version 15.
15:57:43 <sdziallas> the Release one gets incremented each time you make a change to a package.
15:58:08 <mchua> #INFO COMMIT - added version field
15:58:16 <sdziallas> for example if you need to change the URL (about which we'll talk in a second), you'll need to increase the release number.
15:58:29 <mchua> sdziallas: what is the 1${?dist} thing in the Release field?
15:59:01 <sdziallas> %{dist} is a macro. that means for each system the package gets built on, it adds something like .fc12 or .fc13 behind there.
15:59:37 <coolestdude1> is this some kind of variable some where?
15:59:37 <sdziallas> we do this because we need to make sure that unstable packages built for Fedora 13 (which is in development) stay in Fedora 13 and don't get inherited into Fedora 12.
15:59:59 <coolestdude1> oh never mind i got it
16:00:20 <sdziallas> coolestdude1: basically, yes. the macro is specified by some tool that you installed through fedora-packager and depending on your system, the fitting tag will be assigned.
16:00:36 <sdziallas> so since this is our first build, keeping Release: 1 makes sense.
16:00:58 <sdziallas> let's see what's next.
16:01:00 <coolestdude1> yeah i figured it was the current operating system that you used to build a stable working copy
16:01:01 <sdziallas> Summary.
16:01:27 * sdziallas nods (if you build it for a Fedora 9 system, it'll become fc9)
16:01:41 <sdziallas> for the summary, I'm creative today, so let's put: A visual matching game
16:02:09 <sdziallas> (you can basically put whatever you want, as long as it doesn't exceeds 80 letters in that one line)
16:02:21 <mchua> #info COMMIT - description
16:02:32 <sdziallas> next one? (tell me if I'm rushing too much)
16:02:45 <mxd> nope good pace
16:02:49 <sdziallas> cool! :)
16:03:22 <sdziallas> there are several groups - you'll need to select one for your package. the link I posted earlier (the packaging HowTo) shows the other groups, too.
16:03:30 <sdziallas> for a sugar activities, it's dead easy:
16:03:34 <sdziallas> Sugar/Activities
16:03:38 * sdziallas puts it there.
16:04:00 <sdziallas> right.
16:04:12 <sdziallas> License sounds easier than it sometimes is.
16:04:24 <mchua> #info COMMIT Group
16:04:38 <sdziallas> there's a certain catalog of approved licenses.
16:04:56 <sdziallas> and you'll need to figure out which of those the application is licensed under.
16:05:20 <sdziallas> there's usually a COPYING file in the tarball which tells you that. (most of the other source files should also contain a notice)
16:05:32 <sdziallas> if nothing helps, you'll just need to ask the author, so walterbender in this case.
16:06:09 <sdziallas> I'll tell you that it's an MIT license here.
16:06:20 <mchua> #link http://fedoraproject.org/wiki/Licensing#Good_Licenses
16:06:25 <mchua> has a list of acceptable licenses for Fedora.
16:06:27 <sdziallas> mchua: you're quicker than I'm :)
16:06:45 <mchua> sdziallas: how would we look around and find out that it's an MIT license ourselves?
16:06:58 <sdziallas> what is of interest for you in this list is the short name - because that's what gets into the License tag.
16:07:23 <mchua> I will note - as a shortcut - that Sugar Labs just adopted a licensing policy for all activities on http://activities.sugarlabs.org
16:07:29 <mchua> #link http://wiki.sugarlabs.org/go/Licensing
16:07:46 <sdziallas> mchua: as I said, it'll either be stated in a COPYING file in the tarball. if not, a hint is usually in the other source files. and if nothing helps, you can just ping the auther and ask - he should know and tell you where to look.
16:07:55 <mchua> The implications of that policy are that "if it's approved for ASLO, it uses a license that fits the Fedora guidelines too" (in almost every case)
16:08:13 <sdziallas> (so it's an MIT license, we'll put MIT there)
16:08:33 <sdziallas> anybody questions about the legal land here?
16:08:44 <mchua> now, this isn't foolproof *right now* because the guidelines were *just* adopted and I don't think every single Activity in ASLO has been checked for it yet (walterbender?) but it does mean you should probably not have to worry about licensing issues
16:08:46 <mchua> once you find out what license it /is/ under, it's probably OK.
16:09:36 <sdziallas> and if nothing helps, we've an awesome guy doing Fedora Legal work, too :) (spot, that one is for you)
16:09:36 <walterbender> mchua: I try to keep tabs on activities as they get added... but there may be some I missed
16:09:55 <mchua> sdziallas: ok, so you would unzip the .tar.bz2 file and dig around for a COPYING (or LICENSE) file of some sort, or look for something that looks like a license at the beginning of something that looks like the main code file.
16:10:08 <mchua> in an Activity, I believe that usually it's called <programname>.py or main.py
16:10:38 <mchua> #info COMMIT License
16:10:43 * sdziallas nods
16:10:53 <sdziallas> so, the URL then.
16:11:12 <sdziallas> this is just a link to the application's home page.
16:11:18 <sdziallas> in our case, we'll just link to the wiki.
16:11:58 <sdziallas> http://wiki.sugarlabs.org/go/Activities/VisualMatch goes into the spec file
16:12:07 <sdziallas> Next one.
16:12:11 <sdziallas> Source0.
16:12:30 <sdziallas> that's a link to the tarball you downloaded.
16:12:37 <mchua> #info COMMIT URL
16:12:41 <sdziallas> so we'll put down that link and I'll tell you about macros then.
16:13:06 <sdziallas> so we've that URL there now.
16:13:10 <mchua> #info COMMIT Source0
16:13:23 <sdziallas> but you might not want to adjust the URL each time the author releases a new version.
16:13:24 <mchua> That's the link you (or anyone) can wget the source from.
16:13:41 <mchua> It should be a stable link.
16:13:44 <sdziallas> what that means is that we'll use macros. so once you change the Version tag from earlier, the URL will change, too.
16:13:46 * sdziallas nods
16:14:00 <sdziallas> I'll go and implement the macro in gobby so that everybody can watch.
16:14:34 <sdziallas> there we go.
16:14:53 <sdziallas> it reads the version tag out and puts it into the URL.
16:14:59 <sdziallas> sounds reasonable?
16:15:10 <cmpahar> yeap
16:15:23 <sdziallas> awesome :)
16:15:26 <mchua> #info COMMIT Source0 macro
16:15:35 <sdziallas> the buildroot shouldn't concern you much.
16:15:44 <sdziallas> it's basically... some spurious argument where the package gets build.
16:15:58 <sdziallas> again, the HowTo I linked earlier has details. but you almost never need to adjust it.
16:16:03 <mchua> Good, because it looks like "%{blah}/%{random}-%{stuff}" to me right now.
16:16:08 <sdziallas> (I haven't needed either)
16:16:19 <sdziallas> Just Don't Worry, I'd say :)
16:16:26 <sdziallas> okay, now some important stuff.
16:16:34 <sdziallas> BuildRequires is what a package needs to build.
16:17:05 <sdziallas> So when you submit what you created to our build system, it'll take whatever you tell it there and install those packages before building.
16:17:15 <sdziallas> Since activities are python based, you'll obviously need python.
16:17:18 <sdziallas> let's put it there.
16:17:42 * mchua waits for BuildRequires section to finish before saving
16:17:46 <sdziallas> in addition, you'll need sugar-toolkit, which is some sort of package that contains all kinds of system stuff for sugar.
16:18:03 <sdziallas> you'll know that either from me telling you or from the sugar packaging guidelines, which are...
16:18:13 <sdziallas> ...
16:18:16 <sdziallas> #link http://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines
16:18:18 <sdziallas> ...here.
16:18:23 <cmpahar> you mean that you write there the tools you need for creating your program. Not the dependecies
16:18:36 <sdziallas> cmpahar: right!
16:19:11 <cmpahar> i have a question
16:19:15 <dgrift> i came in late and was wondering why BuidArch and BuildRoot werent mentioned?
16:19:36 <sdziallas> cmpahar: shoot!
16:20:07 <mchua> dgrift: BuildRoot was mentioned as a "you don't need to worry about it" section
16:20:12 <dgrift> ok
16:20:39 <cmpahar> what is the difference between BuildRequires and Requires? I mean when you will try to install your program
16:20:39 <sdziallas> dgrift: we'll return to BuildArch afterwards, as I want people to know rpmlint, too :)
16:20:47 <sdziallas> cmpahar: good question!
16:20:49 <cmpahar> it will try to search for these
16:21:00 <sdziallas> BuildRequires: is only for the build system, when your rpm gets created.
16:21:11 <sdziallas> Requires is important when it comes to resolving dependencies.
16:21:31 <sdziallas> so when you put sugar into Requires, the sugar package will get installed when you attempt to install sugar-visualmatch.
16:21:45 <sdziallas> actually, this makes some sense - because without sugar, an activity is rather useless.
16:21:50 <sdziallas> (does this answer the question?)
16:21:56 <sdziallas> let's put sugar in the requires section.
16:22:25 <sdziallas> (for non python applications, the requires will be determined automatically. however, for python stuff, you'll need to put it there yourself)
16:22:53 <cmpahar> yes, thank you :)
16:23:12 <sdziallas> cool!
16:23:19 <sdziallas> so let's move on to the description.
16:23:29 <mchua> sdziallas: hang on, lemme save
16:23:32 <mchua> sdziallas: go ahead
16:23:33 <sdziallas> basically you can take anything that describes the application.
16:23:39 <sdziallas> mchua: okey dokey!
16:23:49 <sdziallas> I'll steal something from the author's wiki page.
16:23:52 <mchua> #info COMMIT BuildRequires and Requires
16:24:02 <sdziallas> the only the to keep in mind is not to exceed 80 letters per line.
16:24:08 <sdziallas> several lines are allowed, though.
16:24:13 <sdziallas> so let's paste some stuff there.
16:24:50 <sdziallas> alright.
16:25:16 <sdziallas> now let's talk about what rpmbuild actually does - rpmbuild is the tool that executes everything based on what you tell it in the spec file.
16:25:22 <mchua> #info COMMIT description
16:25:22 <sdziallas> %setup is its first action.
16:25:39 <sdziallas> %setup will basically extract the tarball and throw it into the BUILD folder.
16:25:41 <mchua> how about %prep?
16:25:57 <mchua> is that like a... header for the %setup section, or something?
16:26:01 <sdziallas> %prep is just the overall section...
16:26:02 <sdziallas> exactly.
16:26:06 <mchua> oh, okay.
16:26:09 <mchua> (line 23, for reference)
16:26:26 <sdziallas> you can do more stuff in %prep (like removing things from the source code), but won't necessarily need to
16:26:46 <sdziallas> %setup will also cd into the directory it just extracted in the BUILD folder
16:26:56 <sdziallas> usually, it'll try to cd into a folder name as your package.
16:27:08 <sdziallas> but the activity tarball contains a folder called VisualMatch-15
16:27:17 <sdziallas> so we'll tell it to cd into this folder instead.
16:27:25 * sdziallas goes modifying the argument.
16:27:48 <sdziallas> ...everybody looking in gobby: makes sense?
16:28:09 <cmpahar> what -q and -n parameters mean?
16:28:24 <sdziallas> cmpahar: :)
16:28:35 <sdziallas> cmpahar: -q means... quiet
16:28:37 <mchua> would we do the same thing for every other Activity we package, except for changing VisualMatch to the name of our Activity?
16:29:03 <coolestdude1> its magic!
16:29:05 <sdziallas> mchua: yes - you'll need to fit your activities name (the name of the folder in the tarball)
16:29:18 <sdziallas> cmpahar: and -n means that %setup will need to cd into this different folder.
16:29:25 <sdziallas> cmpahar: (which we specified directly afterwards)
16:29:33 <cmpahar> where i can find more parameters?
16:29:44 <sdziallas> #link https://fedoraproject.org/wiki/How_to_create_an_RPM_package#.25prep_section:_.25setup_command
16:30:00 <cmpahar> sdziallas, thanks
16:30:03 <sdziallas> this HowTo is generally very helpful and has quite some hints and tricks
16:30:07 <mchua> sdziallas: ping when you're done with %prep and I'll save
16:30:15 <sdziallas> mchua: done!
16:30:40 <sdziallas> okay, now let's take on the %build section.
16:31:02 <sdziallas> this is a python program, so doing anything like ./configure or make won't let you get any further.
16:31:06 <sdziallas> so away with this!
16:31:11 <sdziallas> mchua: did you commit?
16:31:23 <mchua> #info COMMIT %prep
16:31:29 <sdziallas> awesome!
16:31:43 <sdziallas> instead, python applications contain a setup.py file.
16:32:00 <sdziallas> this takes care of building and installing the application.
16:32:08 <sdziallas> (given that it's provided with the proper arguments)
16:32:28 <sdziallas> so we want to build it (cause we're in the %build section). that gives you: python ./setup.py build
16:32:43 * sdziallas goes adding that, looks around  - fair enough?
16:33:25 * sdziallas hurries a bit.
16:33:40 <sdziallas> mchua: can you commit that?
16:33:50 <mchua> #info COMMIT %build
16:33:52 <sdziallas> next one is the %install section
16:34:03 <sdziallas> that's basically where the contents get... installed, heh.
16:34:14 <sdziallas> we don't want to have it on your local system, though.
16:34:29 <sdziallas> rather, rpm creates what it calls a build root.
16:35:04 <sdziallas> so in the directory (BUILDROOT) you'll find folders like /usr/lib/python...
16:35:19 <sdziallas> that's basically how it would look like on your system - just in an isolated form.
16:35:38 <sdziallas> so the rm -rf command cleans an existing build root first...
16:35:43 <sdziallas> ...and then we'll want to install.
16:36:04 <sdziallas> but wait, the command as is would try to install in your local system.
16:36:13 <sdziallas> we want a different destination directory, the buildroot.
16:36:15 * sdziallas goes adding that.
16:36:43 <sdziallas> the different directory is specificied through --prefix
16:36:55 <sdziallas> $RPM_BUILD_ROOT should be pretty obvious ;)
16:37:24 <sdziallas> and %{_prefix} is just another macro which takes care of getting packages installed under /usr and not /usr/local (the former is where everything's supposed to go)
16:37:38 <cmpahar> can you give me one second to get it clean before you continue?
16:37:43 <sdziallas> sure!
16:38:46 <cmpahar> allright BUT
16:39:00 <cmpahar> where is the $RPM_BUILD_ROOT?
16:39:09 <cmpahar> i mean , is a random direcotyr?
16:39:13 <cmpahar> *directory
16:39:38 <sdziallas> cmpahar: the $RPM_BUILD_ROOT links to a directory in the rpmbuild directory you created at the beginning
16:39:53 <sdziallas> cmpahar: after your first build, you'll see a folder called BUILDROOT in there.
16:40:19 <cmpahar> indeed
16:40:36 <sdziallas> cool :)
16:40:39 <cmpahar> ok you can move on and i will understand it later... I'll ask you at the end :)
16:41:08 <sdziallas> oh, okay... sounds good.
16:41:21 <sdziallas> %clean is another easy one, we don't need to adjust that.
16:41:37 <mchua> #info COMMIT %install
16:41:39 <sdziallas> it is just another thing that takes care of making sure that your buildroot is clean at the end.
16:41:53 <sdziallas> what remains are %files and the %changelog.
16:42:00 <sdziallas> we'll start with the changelog this time.
16:42:12 <sdziallas> it has to be in a certain order - I'll just put myself down there.
16:43:02 <mchua> So when we revise the spec later, what happens?
16:43:05 <sdziallas> so the date, your name and e-mail address (as specified in your Fedora account) - and the version you packaged, together with the release.
16:43:05 <mchua> (or will we get to that?)
16:43:18 <sdziallas> mchua: you just put another entry on top of that.
16:43:32 <sdziallas> mchua: for which you'd change the release / version of course.
16:43:53 <sdziallas> it's also helpful to provide a better changelog than "update" or "initial packaging" once you do more concrete changes.
16:44:27 <sdziallas> (things like "turned compiling on $arch off to prevent issues" or whatever)
16:44:41 * sdziallas done with %changelog section, moves to %files
16:45:08 <mchua> #info COMMIT %changelog
16:45:22 <sdziallas> %doc is obvious - it's where you put the documentation of the tarball.
16:45:31 <sdziallas> so if there's a COPYING file, you must include it there.
16:45:38 <sdziallas> a NEWS file can't hurt, either, if that's present.
16:45:48 <sdziallas> (both is the case for visualmatch)
16:46:01 * Cheezmeister has to run now
16:46:09 <Cheezmeister> Vielen Dank, sdziallas and co.
16:46:12 * sdziallas is sorry for being overtime
16:46:19 * sdziallas grins :)
16:46:28 <sdziallas> okay, so let's get this done.
16:46:49 <sdziallas> if you attempted to build your activity with the command rpmbuild -ba sugar-visualmatch.spec now, it'd fail.
16:47:04 <sdziallas> because you'll need to specify where the package installs its stuff.
16:47:18 <sdziallas> by specifying it there, it'll get included in the final .rpm file.
16:47:31 <sdziallas> looking at the sugar guidelines, there's another macro: %{sugaractivitydir}
16:47:43 <sdziallas> behind that, you'll just need to place the name of your activities folder.
16:47:51 <sdziallas> (you'll see that in the BUILD directory)
16:47:57 <sdziallas> so it'll be: %{sugaractivitydir}/VisualMatch.activity/
16:48:00 * sdziallas puts that down
16:48:36 <sdziallas> alright. now we're almost done.
16:48:43 <sdziallas> #info rpmbuild -ba sugar-visualmatch.spec
16:48:53 <sdziallas> (-ba means that it builds a source rpm, as well as the real rpm)
16:49:05 <sdziallas> (a source rpm contains the spec file and the source tarball)
16:49:17 <sdziallas> (so if you've a source rpm, you can always recreate an rpm from that)
16:50:14 <sdziallas> it should say that it created the rpm.
16:50:16 <sdziallas> congrats!
16:50:23 <sdziallas> you just built your first .rpm.
16:50:46 <mchua> #info COMMIT finishing the .spec for the first rpmbuild run
16:50:52 <sdziallas> let me start nit-picking now.
16:50:59 <sdziallas> there's a tool called rpmlint.
16:51:20 <sdziallas> you can run it on the final rpm to verify that the resulting rpm comlies with the guidelines.
16:51:51 <mchua> #info COMMIT check in resulting rpm
16:52:02 <sdziallas> let's do this. I'll execute something like this:
16:52:10 <sdziallas> #info [sebastian@localhost SPECS]$ rpmlint -vi ../RPMS/i686/sugar-visualmatch-*
16:52:33 <sdziallas> that'll actually return a bunch of errors - sorry, we're not yet done :)
16:52:46 <sdziallas> first thing it says is: sugar-visualmatch.i686: W: non-standard-group Sugar/Activities
16:52:59 <sdziallas> that's fine and okay, since activities have to be in that group. let's ignore it!
16:53:17 <sdziallas> next one is more important: sugar-visualmatch.i686: E: no-binary
16:53:27 <sdziallas> because of the -vi parameter, rpmlint tells us already what needs to be done.
16:53:50 <sdziallas> we need to build the package as noarch because it doesn't contain binaries (right, it's written in python)
16:54:01 <sdziallas> I'll add that in gobby.
16:54:13 <sdziallas> mchua: (added.)
16:54:34 <sdziallas> let's see what else is there: sugar-visualmatch.i686: E: script-without-shebang /usr/share/sugar/activities/VisualMatch.activity/gencards.py
16:54:57 <sdziallas> rpmlint gives another explanation for it.
16:55:14 <mchua> #info COMMIT build package as noarch
16:55:18 <sdziallas> turns out that this file shouldn't be executable - it doesn't contain a main() part (if you open it, you'll notice)
16:55:26 <sdziallas> so let's just remove the executable bits.
16:55:40 <sdziallas> (this is what needs to be done by hand and doesn't apply for all packages for example)
16:55:47 * sdziallas goes adding to gobby
16:56:09 * sdziallas hopes the command in the %install section makes sense.
16:56:40 <sdziallas> finally, rpmbuild's last message will go away because we've made the package noarch (sugar-visualmatch-debuginfo.i686: E: empty-debuginfo-package)
16:57:05 <sdziallas> so let's rebuild it and run rpmlint again!
16:57:12 <mchua> #info COMMIT removing executable bits
16:57:31 <sdziallas> (this time, your package will end in ../RPMS/noarch)
16:57:44 * sdziallas runs: [sebastian@localhost SPECS]$ rpmlint ../RPMS/noarch/sugar-visualmatch-15-1.fc12.noarch.rpm
16:57:46 <mchua> #info COMMIT rebuilt new rpm in noarch
16:58:04 <sdziallas> aaaaand this will only give you the message about the group - which we decided to ignore!
16:58:16 <cmpahar> sdziallas, thank you for the class! You were great! I am so sorry but i have to leave! I will read the logs for the rest! Excellent work!!! bb folks! Thank you again :)
16:58:23 <mchua> sdziallas: wait, are we done?
16:58:29 <sdziallas> cmpahar: thank you for attending :)
16:58:55 <sdziallas> mchua: you've an .rpm package now, yes. - in fact, an entirely guideline-compliant package.
16:59:03 <sdziallas> mchua: you still need to submit it for Fedora, though.
16:59:19 <iogburu> Will a transcript be available
16:59:24 <sdziallas> iogburu: sure thing!
16:59:39 <sdziallas> iogburu: we'll post everything to the fedora-olpc-list (and possibly others, too)
17:00:19 <sdziallas> submitting it for Fedora works through a review, where another packager goes through the guidelines and makes sure that the package complies with them.
17:00:24 <sdziallas> #link http://fedoraproject.org/wiki/Package_Review_Process
17:00:36 <sdziallas> the detailed process is outlines here, as I guess it'd lead too far now...
17:02:51 <dgrift> is there a list with all options for all sections, some are mentioned in the url that was provided previously, other arent it seems
17:03:15 <dgrift> example: %files -f %{name}.lang
17:03:21 <sdziallas> dgrift: yes, the howto covers that (https://fedoraproject.org/wiki/How_to_create_an_RPM_package)
17:03:36 <sdziallas> dgrift: exactly. in some cases, you'll need to include the translations that way.
17:03:39 <sdziallas> (good point!)
17:03:39 <dgrift> i cannot find that particular options
17:04:36 <sdziallas> you're indeed right. in this case, the guidelines contain more information.
17:04:40 * sdziallas looks for the link
17:04:54 <dgrift> also a list with all macros and their meaning. in the url alot are explained. i could not get sysconfigdir to work for my file in /etc
17:05:05 <sdziallas> dgrift: http://fedoraproject.org/wiki/Packaging/Guidelines#Handling_Locale_Files
17:05:15 <dgrift> thanks, noted
17:05:38 <sdziallas> (and the macros as you've probably found are here: https://fedoraproject.org/wiki/How_to_create_an_RPM_package#Macros)
17:05:47 <dgrift> yes indeed
17:06:04 <dgrift> i will try sysconfigdir again, see if i can reproduce it
17:06:05 <sdziallas> that's strange. %{_sysconfigdir} should work.
17:06:25 <sdziallas> if it still doesn't work, I'd be happy to look into it.
17:06:46 <dgrift> also is there a detailed guide how to deal with config files (rpmnew/rpmsave)
17:08:04 <sdziallas> I think the %files prefixes contain some information: https://fedoraproject.org/wiki/How_to_create_an_RPM_package#.25files_prefixes
17:08:11 <sdziallas> (otherwise, it's up to the guidelines again)
17:08:15 <dgrift> what do you (personally) think makes a decent packager and a good packages?
17:08:22 <dgrift> packager?
17:08:48 <sdziallas> well, I guess it's practice.
17:09:01 <sdziallas> when I started packaging - about two years ago - it was certainly hard.
17:09:14 <sdziallas> I had to look up quite a lot of things and was happy to have somebody I could ask, too.
17:09:36 <sdziallas> I know that not everybody can do this, so that's also one reason to give such a session: to make it easier.
17:09:57 <sdziallas> I maintain now probably around 30 packages, which is quite... sufficient for now, heh. ;)
17:10:02 <sdziallas> what I'm saying is:
17:10:03 <dgrift> yes its quite hard to get help
17:10:24 <dgrift> i usually look at other specs
17:10:36 <sdziallas> once you figured it out, updating a sugar activity doesn't take more than five minutes.
17:10:53 <sdziallas> that's also a good point, yes (though the firefox one would probably scare people away)
17:11:16 <mchua> I wouldn't mind hanging out and working on Sugar packages in a channel I knew could get help in.
17:11:31 <mchua> Whether that's #sugar or #fedora-<something>, I don't know.
17:11:45 <sdziallas> (I don't know how many people are still here, but I'd suggest dropping the "how do I become a packager" part for now)
17:12:00 <dgrift> ok, thanks
17:12:02 <sdziallas> mchua: that'd be an interesting possibility, agreed!
17:12:16 <sdziallas> mchua: maybe it's time for #fedora-sugar?
17:12:22 <sdziallas> so for everybody who's still here:
17:12:37 <sdziallas> If you're really interested in this: we'll meet tomorrow, at the same time in #fedora-olpc!
17:13:03 <sdziallas> our weekly meetings happen there - so just drop by.
17:13:18 <sdziallas> if you want, you can also sign up for starting with an activitiy there.
17:15:08 <sdziallas> I'll close the meeting for now. Feel free to ping me or others in #fedora-olpc or #sugar whenever we can help.
17:15:45 <sdziallas> (as you've noticed in gobby, I also *do* have an e-mail address... heh.)
17:15:51 <sdziallas> #endmeeting