14:40:30 <herlo> #startmeeting
14:40:30 <zodbot> Meeting started Sun Jan 30 14:40:30 2011 UTC.  The chair is herlo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:40:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:48 <zodbot> tflink: Error: Can't start another meeting, one is in progress.
16:06:52 <stickster> Need transcription here!
16:06:59 <tflink> A lot of people like to grep the output of yum
16:07:23 <tflink> but you can use 'yum -repoquery' which is a lot easier and can give you a lot more information
16:08:43 <tflink> if you are looking to apply just security updates, you can use: 'yum update-minimal', 'yum --security upgrade' (not sure about the last one, typing a little behind
16:09:47 <tflink> you can also log versions with 'yum versionlock'
16:09:59 <tflink> for sys admins, there is a veriable database
16:10:35 <tflink> by putting files in /etc/yum/vars, you can control variables in the repo definitions
16:11:07 <tflink> * the example is setting variables in a file in /etc/yum/vars for chromium
16:11:17 <tflink> you can also have a uuid fo the machine
16:11:39 <herlo> #chair tflink
16:11:39 <zodbot> Current chairs: herlo tflink
16:12:21 <tflink> yum also has a DB that stores stuff like uid of person doing the update, version, time of last install, checksums etc.
16:12:42 <tflink> for more information, you can go to http://yum.baseurl.org/wiki/YumDB
16:13:04 <tflink> you can use yumdb to keep ony a version of a kernel (let you upgrade anything else)
16:13:16 <tflink> Install is not just for package names
16:13:39 <tflink> Files, specify versions, groups, groups minus a specific package
16:13:50 <tflink> yum install 'config(postfix) >= 2.7.0'
16:13:59 <tflink> yum -- install @books -javanotes
16:14:19 <tflink> recently added options so that it is easier to change stuff
16:15:04 <tflink> 'yum --setopt=keepcacke=1' or commands like that allow changing options once or twice without having to mess with global conf
16:15:31 <tflink> you can also do stuff like change releasever, enable/disable repos etc.
16:16:01 <tflink> now we have yum-config.manager which does some interesting stuff but one of the most useful is the ability to enable or disable repos
16:16:24 <tflink> yum history can be used to look through the history of installed packages
16:16:37 <tflink> 'yum history list yum' => finds the history of yum on this system
16:16:54 <tflink> you can also do 'yum history undo last' to undo the last yum transaction
16:17:15 <tflink> you can keep doing that until your machine explodes
16:17:43 <tflink> the transaction history stores not only the pacakges installed, but the coniguration and plugins used in yum at the time of the transaction
16:18:08 <tflink> rpmDB version -> a version and checksum of the entire RPM db from the system
16:18:28 <tflink> which allows you to just compare the rpmDB instead of comparing all of the packages
16:18:48 <tflink> rpmdb is also stored in history, and the changes in rpmdb
16:18:59 <tflink> *q does packagekit use this stuff?
16:19:22 <tflink> no, packagekit is a little more arch agnostic since it has to work on debian, gentoo, etc.
16:19:50 <tflink> *c but since most people use package kit, how useful is this to most users
16:20:07 <tflink> well, they could use yumex or the cli but they might eventually fix packagekit ...
16:20:25 <tflink> *c well there is some new stuff coming down the pipeline ...
16:20:29 <tflink> I just hope that audit works
16:20:51 <tflink> you can also use yum to sync machines -> "are the machines the same?"
16:20:55 <tflink> yum version nogroups
16:21:17 <tflink> you can also use yum to save/restore by using yum-debug-dump <something else I missed>
16:21:57 <tflink> yum saves transactions in /tmp and you can load the transaction files on however many machines to get them all the same
16:22:10 <tflink> assuming that the rpmdb was the same to start with
16:22:13 <tflink> yum is on irc
16:22:15 <tflink> $yum
16:22:17 <tflink> or
16:22:28 <tflink> http://yum.baseurl.org/wiki/whatsnew
16:22:37 <tflink> *q - you said that some of this is in rawhide?
16:22:48 <tflink> yeah, some is in rawhide
16:23:04 <tflink> *q - is there significant performance penalty by installing these yum plugins
16:23:37 <tflink> sometimes, there can be - depending on how you;re using it. we try really hard to make sure that there aren't any significant penalties in them
16:23:59 <tflink> we have tended, historically, to use plugins so taht we can thrown them away if needed but eventually get them into core
16:24:15 <tflink> the yum info command is a prime candidate at the time
16:24:33 <tflink> there are a bunch of plugins right now and some of them are used but others aren't so much
16:24:43 <tflink> *q - do you think that this will make it into RHEL at some point
16:24:53 <tflink> these features in rawhide will make it into RHEL 6.1
16:24:59 <tflink> ==> end of yum presentation
16:25:06 <tflink> ==> starting the AppStream prenentation
16:25:37 <tflink> So, there was a meeting where people from debian, SuSE, RedHat etc. met to tak about packages
16:25:51 <tflink> they talked about solving the issues of finding and installing applications
16:26:13 <tflink> it is difficult since there are so many packages, the UIs are lacking, there needs to be additional metadata
16:26:36 <tflink> and there was a desire to work together since most distros have something but nobody really has a solutions
16:27:01 <tflink> my bakckground is a red hat employee for 5 years, is a RPM dev, yum dev in former life
16:27:28 <tflink> I know mostparts of the package stack but I'm not a UI person, not really a fedora person and have no clue about Fedora infrastructure
16:27:34 <tflink> so, parts and pieces of this
16:28:07 <tflink> after a lot of hours of talking, it was interesting to see that people from the different distros have similar ideas about what they're looking for and what they don't want to force on other distors
16:28:43 <tflink> we all know how difficult this would be, so we wanted to have some similarities between the different distros
16:29:12 <tflink> it was clear that it has to be different from what we had done in the past
16:29:27 <tflink> one part on the server, but the ability to runit from a CD as well
16:30:02 <tflink> ideally, we would be able to share screenshots for these packages
16:30:13 <tflink> * Slide with a graphic of architecture
16:30:57 <tflink> where the client would pull from a screenshot server, OCS server (ratings, comments), existing metadata (which could also pull from a remote server)
16:31:49 <tflink> * another graphic on implementation plan
16:32:22 <tflink> there is a partial implementation already in ubuntu with software center (written in python and GTK)
16:32:31 <tflink> * another graphic about setup example
16:32:54 <tflink> with this setup, you can have sharing of stuff like comments and ratings
16:33:27 <tflink> where we obviously want the ratings from our repo, but we might want the repo for comments and ratings from the OpenSuSE repo as well
16:34:11 <tflink> the application data would be generated from menu files, using an XML format that is independant from distributions
16:34:25 <tflink> to allow sharing without politics (coordinated through opendesktop_
16:35:02 <tflink> we're trying to get a couple of things added to opendesktop.org standard to make sure that this all works for ALL distros
16:35:20 <tflink> on the client side, we want to get the ubuntu GUI working on a ll distros and put into packagekit
16:35:46 <tflink> at the moment, there is some license and copyright assignment issues right now but they're currently working on it
16:35:58 <tflink> the legal issues are aparrantly with ubuntu/canonical
16:36:21 <tflink> there is a guy from Magaia is supposedly working on web front
16:36:40 <tflink> MeeGo people are working on a different app installer based on Qt
16:36:54 <tflink> it is very similar but we'll see where everything goes
16:37:02 <tflink> * screenshot of the ubuntu software center
16:37:35 <tflink> the cerver will be called Open Collaboration Server/Service
16:37:47 <tflink> the software already exists, only a small list of changes are needed
16:37:57 <tflink> the API is similar to XML-RPC
16:38:22 <tflink> it would be nice to integrate this into the packagedb part, but each distro will need to run one OCS on its onwn
16:38:36 <tflink> this will keep politics and religion from being an issue
16:39:12 <tflink> we don't want to use the same server for everyone --> avoid the political issues with who is going to write what
16:39:23 <tflink> we are still looking for people within Fedora to run this system
16:39:53 <tflink> we could also just try to do the metadata thing and ignore the rest if there is no interest in the community
16:40:07 <tflink> for the screenshot server, debian already have one
16:40:26 <tflink> we could probably use it if we put a proxy in front of it but we probably want one of our own
16:40:40 <tflink> OCS data points to screenshots - used in the app installer
16:40:48 <tflink> GUI integration for upgrading could get fancy
16:41:10 <tflink> a couple of other things missing from the overall plan so far
16:41:34 <tflink> mataching packages between distributions and debtags
16:41:56 <tflink> the idea (rough right now) is to get that started (Enrico Zini is workin on this)
16:42:14 <tflink> it needs to match source to binary package list, know files per package and there may be more in the furture
16:42:31 <tflink> and get information like "this package is 99% similar to this other package"
16:42:43 <tflink> there wasn't a whole lot of package during the meeting, but it is kind of working
16:43:10 <tflink> it probably makes sense to have something within packagedb to see what the suse, debian, ubuntu guys are doing
16:43:42 <tflink> for binary packages, you can use others descriptions of translations and fall back on this data for OCS data
16:44:06 <tflink> abut there are issues with different packaging and naming conventions between the distros
16:44:22 <tflink> the debian people have set up a fance and complicated tagging method for packages
16:44:32 <tflink> I think they have something like 75k packages or somethiong like that
16:44:52 <tflink> these tags can keep track of the language it is written in, and attache multiple tags to each packages
16:45:04 <tflink> about 50% of all debian is tagged at the moment
16:45:19 <tflink> you need a bit of brainpower to wrap your head around all of the tagging stuff
16:45:42 <tflink> its done by a few people because packagers tend to have problems tagging properly
16:46:05 <tflink> since there is usually a couple of distro-wide tags
16:46:15 <tflink> they even use a world writable UI for now
16:46:44 <tflink> since most people probably want nothing to do with tagging
16:46:55 <tflink> you can use the tags to subdivide search results or categories
16:47:14 <tflink> probably not used for browsing since you would have to understand how the tags were created and the conventions first
16:47:32 <tflink> but with searching, you can narrow down subsets
16:48:00 <tflink> kind of searching on ebay - you make a search and then narrow down results by attributes of the items in the search results
16:48:42 <tflink> there are good tools, but you still want to have human control over the tags
16:48:54 <tflink> some examples of searches (not going to type them all)
16:49:04 <tflink> Admin: Accounting, Automation, Backup, ...
16:49:14 <tflink> Made-of: Audion, Dictionalry, Font, HTML, XML
16:49:35 <tflink> *q - how is this going to be different from the current package database - we currently have tags on packages and libraries
16:49:45 <tflink> how many tags do we have right now?
16:49:50 <tflink> maybe about 20k
16:49:54 <tflink> who entered that?
16:50:08 <tflink> packagedb? <missed the answer>
16:50:14 <tflink> we need to have multiple sources
16:50:35 <tflink> *c - we can always add more tags
16:50:45 <tflink> *q - do they have any tools that actually use the tags right now
16:50:54 <tflink> I know that the screenshot server uses them
16:51:08 <tflink> there is a prroblem of a lot of people doing the work but it isn't finished
16:51:19 <tflink> something that is cool and fancy but isn't working everywhere
16:51:23 <tflink> any questions?
16:51:41 <tflink> I'm going to talk a bit more about what people in other distros seem to think about us
16:52:05 <tflink> they are also subdivided with different interests
16:52:13 <tflink> they might be better with infrastructure
16:52:24 <tflink> but I'm not a fedora person, might not be correct on that one
16:52:37 <tflink> it is a difficult problem but everyone wants to include and package even more software
16:52:57 <tflink> it looks like we are growing 3k - 4k binary packages per year
16:53:21 <tflink> we were able to save a little bit of space by changing compression algorithm
16:53:28 <tflink> *q - which did you switch to?
16:53:30 <tflink> xset
16:53:38 <tflink> switched about 2 years ago
16:53:59 <tflink> people are aware that it is hard to do even within the same distro
16:54:14 <tflink> my impresion is that this is a good idea to allow for better communication
16:54:25 <tflink> there are so many cool things going on, but people don't always know about
16:54:46 <tflink> one of the motiviations for all this is that there are so many cool packages but people can't use them if they can't find them
16:55:13 <tflink> *q - its clearly orthoganal since the distro's install method are different
16:55:29 <tflink> something about zeroinstall
16:55:52 <tflink> the thoughts are that someone could do that but "not on our packages"
16:56:05 <tflink> you could get your own server and OCS etc. to do that
16:56:23 <tflink> it isn't excluded by the way that the arch is set up, but not planned
16:56:52 <tflink> *q - i'm a fedora user but if I want a package that isn't in fedora, maybe I could find a package in debian or zeroinstall
16:57:13 <tflink> we're trying to avoid things taht could break your system - installing deb package on fedora
16:57:29 <tflink> you get people complaining that "you broke my system" when it isn't something that was a good idea in the first place
16:57:45 <tflink> if someone goes for that, it is possible but we won't be working on it
16:57:50 <tflink> ==> end of meeting
16:57:55 <tflink> #meetingend
16:57:59 <tflink> #endmeeting