02:04:22 <mether> #startmeeting Fedora Classroom - Introduction to Koji Build system and Bodhi Updates system
02:05:20 <mether> #topic Basic Ideas
02:05:41 <mether> #link http://koji.fedoraproject.org
02:05:53 <mether> #link http://admin.fedoraproject.org/updates
02:06:51 <mether> I will get started now but feel free to ask questions in between if you like
02:07:36 <mether> Koji is the Fedora build system used by Fedora Project
02:08:38 <mether> Essentially it is what converts upstream source archives into RPM packages with the help of spec files as input from the package maintainers
02:08:49 <mether> In the first link, you can see a web interface to it
02:09:49 <mether> In the good old days when Fedora got started, the build system was run inside Red Hat and you could only see updates being pushed out in a bulk (via the daily rawhide report) for instance
02:10:19 <mether> With the merge of Fedora Core and Extras back before Fedora 7 release, a new build system was introduced
02:10:31 <mether> that made it possible for developers and users to see builds as they happen
02:10:46 <mether> of course, as with all things Fedora, it is free and open source
02:10:51 <mether> and available in the repository itself
02:11:31 <mether> Bodhi is the updates system used by Fedora. The web interface is available at http://admin.fedoraproject.org/updates
02:12:18 <mether> These are tools that are used primarily by Fedora package maintainers but provide a number of useful features for end users as well
02:13:28 <mether> So let me explain the basic workflow that ties these tools together
02:13:43 <mether> A Fedora package maintainer initiates a new build via Koji
02:14:09 <mether> let's say when there is a new upstream release of a project
02:14:38 <mether> The build is accessible via the web interface as soon as it is initiated
02:14:46 <mether> When the build is complete
02:15:07 <mether> the package maintainer can choose to either push it to updates or updates-testing repository
02:15:43 <mether> The recommended practice is to push it to updates testing repository first so that the people interested in testing it can have the opportunity to provide some feedback
02:16:08 <mether> There are occasions where the package maintainer has reasons to push it to updates repository directly as well
02:16:32 <mether> For example, a high risk security fix that is small enough will fall into the latter
02:17:18 <mether> The updates system is essentially what pushes the packages from the build system out in the mirrors in either repository
02:17:27 <mether> Any questions so far?
02:17:53 <BounceCat> I'm curious about tasks vs builds on the koji page
02:18:42 <mether> ok. I will come to that in a bit
02:20:14 <mether> the simple explanation from my understanding is that tasks are how you initiate or manipulate a build
02:20:44 <mether> the updates system web interface
02:20:55 <mether> allows you to provide easy feedback to the maintainers
02:21:04 <mether> for example
02:21:13 <mether> If you are running Fedora 11
02:21:23 <mether> and you want to test the packages in the updates testing repository
02:21:25 <mether> you can do
02:21:34 <mether> yum --enablerepo=updates-testing update
02:21:54 <mether> you can see all the packages in the repo
02:21:55 <mether> via https://admin.fedoraproject.org/updates/F11/testing
02:22:09 <mether> and if you want to provide feedback on one of them
02:22:25 <mether> let's say
02:22:26 <mether> https://admin.fedoraproject.org/updates/F11/FEDORA-2009-8296
02:22:32 <mether> That particular update
02:22:37 <mether> has a single bug fix
02:22:41 <mether> if you were affected by it
02:23:01 <mether> and confirmed via the testing that it does indeed fix the bug
02:23:06 <mether> you can add a comment
02:23:23 <mether> just provide your email address
02:23:28 <mether> and select
02:23:37 <mether> works for me or does not work as depending on the case
02:23:41 <mether> and add your comment
02:24:05 <mether> The updates system by default pushes the package into updates repository once it gets three positive confirmations
02:24:08 * nirik notes this sort of testing is very very very valuable to maintainers. Please provide this feedback as much as you can.
02:24:16 <mether> these are called karma points
02:24:51 <mether> The maintainer of course can decide before the push whether he or she wants to take advantage of karma points and if so how many does it require
02:25:01 <mether> or choose to push it manually
02:25:12 <mether> it is a quicker alternative to providing feedback via bugzilla
02:25:25 <mether> the email address is useful because it is sometimes a conversation
02:25:32 <mether> if you say that it doesnt work
02:25:40 <mether> the maintainers would usually want more information from you
02:26:04 <mether> There is a common confusion with the updates system
02:26:11 <mether> that is the status called "pending"
02:26:27 <mether> when a update is pushed into either updates or updates testing repository by the maintainers
02:26:39 <mether> Someone from release engineering team
02:26:44 <mether> has to sign the package first
02:26:49 <mether> this is a manual process
02:26:54 <mether> and sometimes there is a delay
02:27:06 <mether> all the packages that have been pushed but not signed
02:27:09 <mether> is in the pending status
02:27:29 <mether> You can still access the package via Koji web interface
02:27:35 <mether> but it wont be available in the repository yet
02:27:42 <mether> Another common confusion
02:27:51 <mether> is that update notices are send out via mailing list
02:28:03 <mether> but the update is not in the mirror used by yum
02:28:36 <mether> this can happen because mirrors are not in the same schedule and yum picks a mirror that has yet to sync the update
02:29:01 <mether> Like nirik said the feedback that we get from users is very useful
02:29:11 <mether> for us as package maintainers
02:29:24 <mether> so provide more of it whenever you want
02:29:35 <mether> even a simple "works for me" is good to know
02:29:53 <mether> especially because we are in Fedora maintaining multiple releases and pushing updates across branches
02:30:05 <mether> and it is not always feasible to test every update extensively
02:30:42 <mether> After a package stays in updates testing repository for sometime (normally a week or so)
02:30:49 <mether> it is pushed into the updates repository
02:31:11 <mether> You can get notifications from many places
02:31:15 <mether> one is the mailing list
02:31:16 <mether> http://www.redhat.com/mailman/listinfo/fedora-package-announce
02:31:35 <mether> Another is rss feeds at http://planet.fedoraproject.org/infofeed/
02:32:24 <mether> #topic Koji
02:32:43 <mether> Koji web interface like I said is accessible from http://koji.fedoraproject.org
02:32:52 <mether> One of the features used often by users
02:32:59 <mether> is early access to updates
02:33:04 <mether> before it hits the repository
02:33:15 <mether> or just to know what is the status of an update
02:33:40 <mether> let's say there is a Firefox update in http://firefox.com
02:33:48 <mether> and you want to know whether it is being built in Fedora
02:33:56 <mether> you can use the Koji interface to search for it
02:34:08 <mether> There is a pitfall here however
02:34:28 <mether> sometimes a feature update is only available in the development branch called Rawhide
02:34:41 <mether> and users try to get the update from there and end up breaking their system
02:35:14 <mether> so make sure you get the update intended for the release you wanted
02:35:31 <mether> and if you do this, be aware that it has not gone through the usual QA via updates testing repository
02:35:46 <mether> and you can end up with regressions
02:35:48 * nirik notes that they are also not signed.
02:36:18 <sijis> can i ask a question? or wait till the end?
02:36:25 <mether> If you are just using the interface to keep track of updates, that is fine
02:36:29 <mether> sijis, feel free to ask
02:36:59 <sijis> so looking at koji interface, how can i tell its for rawhide or not?
02:37:15 <sijis> i assume i'm suppose to be looking at the 'recent builds' section.
02:37:17 <mether> that is a good question
02:37:29 <mether> let me give you some specific example
02:38:12 <mether> Let's say you are running Fedora 11 and want to know whats the latest version of Gnote built for your release
02:38:22 <mether> and you go to http://koji.fedoraproject.org/koji/
02:38:27 <mether> use the search interface
02:38:41 <mether> You get the results
02:38:42 <mether> http://koji.fedoraproject.org/koji/packageinfo?packageID=8132
02:39:04 <mether> Most of the packages in Fedora use what is called the dist tag
02:39:08 <mether> fc12 of fc11 and so on
02:39:16 <mether> so a quick way to check
02:39:24 <mether> is look at the end of the package name
02:39:31 <mether> in this case
02:39:34 <mether> you will notice
02:39:50 <mether> that 0.6.1 is only available for Fedora 12 (Which is the development version)
02:40:00 <mether> and 0.5.3 is what is available for Fedora 11
02:40:16 <mether> If you click on
02:40:20 <mether> 0.6.1
02:40:27 <mether> http://koji.fedoraproject.org/koji/buildinfo?buildID=125125
02:40:35 <mether> you see the tags?
02:40:44 <mether> that shows
02:40:49 <mether> dist-f12
02:40:52 <sijis> yup. dist-f12, f12-alpha
02:40:56 <mether> that is a clear indicator
02:40:58 <mether> of which release
02:41:00 <mether> it is built for
02:41:05 <mether> that is set by the build system
02:41:27 <mether> dist-f11 for Fedora 11
02:41:32 <mether> it should be fairly obvious
02:41:40 <mether> what release it is being tagged
02:42:01 <mether> if you get a Fedora 12 tagged package and try to install it on a previous release
02:42:06 <mether> you will often end up breaking it
02:42:18 <BounceCat> which tag is "rawhide"?
02:42:43 <mether> If Fedora 11 is the latest general release
02:42:49 <mether> dist-f12
02:42:51 <mether> is rawhide
02:43:09 <BounceCat> ok
02:43:21 <mether> we dont tag anything as rawhide because then you would have to retag it before release
02:43:40 <sijis> so rawhide is essentially the next Fedora release.
02:43:44 <mj0vy> ! so gnote-0.6.1-1.fc12 is a rawhide release
02:43:47 <mether> correct
02:43:52 <mether> mj0vy, correct
02:43:57 <zer0c00l> mether, how to find whether gnote is in update-testing or rawhide or updates repository with koji?
02:44:13 <mether> if you go to
02:44:19 <mether> http://admin.fedoraproject.org/updates
02:44:22 <mether> and search for gnote
02:44:32 <mether> it would show you the status
02:44:37 <mether> the three statuses are
02:44:49 <mether> pending - release engineering needs to sign the packages manually
02:45:01 <mether> testing - it is in updates-testing repository
02:45:10 <mether> updates - It is in updates repository
02:45:30 <mether> there is actually
02:45:59 <mether> a bodhi and koji command line clients
02:46:23 <mether> yum install bodhi
02:46:25 <mether> and do
02:46:32 <mether> bodhi -L gnote
02:46:50 <mether> and you can find out the status of gnote across all the current branches
02:47:14 <mether> http://fpaste.org/bJiV/
02:47:21 <mether> thats the same output
02:47:49 <mether> zer0c00l, does that answer your question?
02:48:02 <zer0c00l> mether, yes
02:48:08 <mether> excellent
02:48:39 <sijis> i'm not sure if you've gone through this.. but how does bodhi and koji differ?
02:48:54 <mether> koji is the build system
02:49:02 <mether> and bodhi is the updates system
02:49:10 <mether> koji builds the packages
02:49:21 <mether> and bodhi is used to push the packages into the repositories
02:49:41 <mether> both of them have web interfaces and command line clients as well
02:50:03 <mether> Bodhi has also a metrics page which I find pretty interesting
02:50:14 <mether> These are available for every release
02:50:16 <mether> https://admin.fedoraproject.org/updates/metrics/?release=F11
02:50:20 <mether> is for Fedora 11
02:50:37 <mether> As you can see, we tend to push a large number of updates
02:51:18 <sijis> interesting stuff.
02:51:22 <mether> Folks from the release engineering and infrastructure team have done a bunch of work to speed up the process of getting the updates to users whenever the package maintainers does a push
02:51:42 <BounceCat> question ..
02:51:46 <mether> Josh Boyer from rel eng team explained some of the recent improvements in his blog post
02:51:47 <mether> http://jwboyer.livejournal.com/35243.html
02:51:50 <mether> BounceCat, ask
02:51:57 <BounceCat> status:pending = "release engineering needs to sign the packages" .. do they check the package somehow before signing it?
02:52:25 <mether> no. they merely sign the rpm package so that you know it is from Fedora
02:52:37 <BounceCat> ok
02:52:54 <mether> the testing is actually done by volunteers in the QA team or other users
02:53:09 <mether> so everyone can participate and help out
02:53:23 <mj0vy> ! mether, for viewing, we should install only bodhi-client package, no?
02:53:49 <zer0c00l> yes there is no package named bodhi
02:54:01 <mether> mj0vy, yes. only the client is required for end users
02:54:09 <mether> i was wrong about the package name
02:54:13 <mether> it is called bodhi-client
02:54:16 <mether> instead of bodhi
02:54:57 <mether> I as a package maintainer get all the tools I need with the fedora-packager meta package
02:55:11 <mether> # yum install fedora-packager
02:55:15 <mether> if you want them all
02:55:36 <mether> As I was explaining
02:55:44 <mether> there is ongoing work
02:55:51 <mether> to improve the infrastructure
02:55:59 <mether> I will briefly explain them
02:56:01 <mether> https://fedorahosted.org/sigul/
02:56:14 <mether> Sigul is a automated signing system
02:56:23 <mether> that basically is going speed up the process
02:56:28 <mether> of moving the packages
02:56:31 <mether> into the repository
02:56:45 <mether> currently someone from rel eng team has to manually sign
02:56:49 <mether> every single package
02:56:55 <mether> and sometimes it gets delayed
02:57:14 <mether> while the blog post I pointed out a bit earlier talked about the improvements they have done
02:57:24 <mether> Sigul should help it more
02:57:33 <mether> and it will be transparent to you as end users
02:57:36 <mether> Another thing
02:57:43 <mether> is what BounceCat what was asking about
02:57:58 <mether> release engineering doesnt actually do any checking on the package
02:58:02 <mether> because it is a small team
02:58:07 <mether> and there are a large number of updates
02:58:20 <mether> we get some feedback from the testers
02:58:26 <mether> and that is often not enough
02:58:39 <mether> so there has been some work
02:58:45 <mether> done on automating some of the common checks
02:58:52 <mether> https://fedorahosted.org/autoqa/
02:59:02 <mether> you should be seeing it in action soon
02:59:32 <mether> common packaging mistakes can be caught and reported automatically
02:59:35 <mether> by this system
02:59:49 <mether> so testers can use their time to check for things
02:59:53 <mether> that cannot be easily automated
02:59:57 <mether> instead of grunt work
03:00:30 <mether> That's all I wanted to cover in this session but I will do others as followups related to this one
03:00:41 <mether> If you have more questions please ask
03:01:09 <mether> #topic Final Q&A
03:01:46 <mether> No more?
03:01:47 <mj0vy> mether: It was very informative. Thanks.
03:01:56 <mether> Thank you all for attending then
03:02:00 <nirik> thanks mether!
03:02:03 <rexbinary> thank you
03:02:12 <BounceCat> dumb question: how to speak the word "bodhi" ? eg sounds like?
03:02:13 <sijis> mether: thanks!
03:02:29 <mether> BounceCat, Luke Macken who wrote the build system
03:02:37 <mether> is a bit of not so closet
03:02:50 <mether> fan of Buddhism
03:02:54 <mether> karma
03:02:56 <mether> bodhi
03:03:04 <mether> and some of his other projects
03:03:11 <mether> are named after the core ideals
03:03:12 <zer0c00l> buddha got wisdom under bodhi tree :)
03:03:28 <mether> http://en.wikipedia.org/wiki/Bodhi
03:03:30 <zer0c00l> thanks mether
03:03:42 <BounceCat> mether, ahh ok. thanks for a great class btw !!!
03:03:47 <mether> Bodhi and Karma are Sanskrit words
03:04:02 <mether> Hint: Koji also has a interesting reason behind its name
03:04:04 <mether> check it up
03:04:12 <mether> BounceCat, zer0c00l welcome
03:04:35 <mether> like wrote the updates system
03:04:39 <mether> not the build system
03:04:54 <mether> I misspoke
03:05:07 <mether> Luke Macken wrote the updates system - Bodhi
03:05:13 <mether> alright
03:05:17 <mether> #end
03:05:30 <mether> #endmeeting