== Summary ==
Present from FESCo: thl, warren, jeremy, scop, skvidal, mschwendt, ensc,
thomasvs
Important topics:
* Kernel module standardization
* xen naming problems should be solved soon
* scop will fire some test builds (site note: there was a problem; for
details see on the lists)
* Mass rebuild of Extras for FC5
* poke thias again -- he still has a lot of packages that are not yet
rebuild (site note: poked, no response yet)
* orphans that can be removed without breaking other stuff will be
deleted from the repo and disabled in cvs (site note: was done already
by mschwendt).
* gst08 -- we need this in FE5 because some packages depend on it.
Plan: Get it into extras until next Thursday. even if it's not perfect.
* EOL Policy for FE
* No process. thl has it on his todo-list.
* Encourage Extras reviews
* better documentation. warren will do that after FC5 is out the door
* Broken deps report
* problems when running on rawhide. mschwendt and skvidal will look
into this.
* Weekly sponsorship nomination
* Nobody.
* separate lists for bugzilla-spam
* warren is working on it
* separate extras-ml-list for bugzilla spam
* We'll probably open fedora-extras-bugzilla-list and
fedora-extras-review-list. All contributors should subscribe to
-reviews.
* FE-NEEDSPONSOR tracker bug
* Will be removed from the schedule. Warren will document it in the
updated documentation. We can put it back if there is anything remaining
regarding it.
* Free discussion; Highlights: Script that automatically checks things
during review, Multilib in extras (seems some people don't like the
idea)
{{{
19:55 < jwb> | are we still waiting for plague 0.5 before discussing scratch builds again?
19:56 < thl> | jwb, yes, I think so
---
19:56 < ignacio> | I was talking to jbj, and he was saying that a number of things that we currently check for in the review can easily be automated.
19:57 < spot> | the difficulty with automating the review tasks is that there are far too many special case scenarios that have to be dealt with
19:58 < spot> | where an intelligent human can adapt, an automated process can not.
19:58 < ignacio> | Not automating the review tasks, but automating the things the review checks for.
19:58 < spot> | thats what i mean.
19:58 < ignacio> | Such as calling ldconfig, and so on.
19:59 < spot> | given enough time, i'm sure people will find exception cases
19:59 < spot> | like packages that include so files, but dont want to call ldconfig
19:59 < thl> | ignacio, is writting a script or app that checks this stuff really worth the effort?
19:59 * | bpepple thinks the fedora-qa script does a lot of that.
20:00 < ignacio> | Maybe.
20:00 < spot> | it might be helpful for reviewers, but not as a replacement
20:00 < ignacio> | There does need to be some looking into it done.
20:00 < ignacio> | Or maybe just should, but still.
20:00 < jwb> | there's a fedora-qa script?
20:00 < nirik> | http://fedoraproject.org/wiki/AurelienBompard
20:00 < nirik> | for the fedora-qa script. ;)
20:01 < ignacio> | Why isn't that in UsefulScripts?
20:01 < ensc> | I would think about a system which checks submitted packages (e.g. with rpmlint, various installation tests, ...), tells the results into the review system and human reviewer can decide whether the package can be accepted
20:01 < jwb> | why isn't there a package for it!?
20:01 < bpepple> | jwb: Yup, it checks a lot of the items (dup BR's, etc.)/
20:01 < ensc> | but that's nothing which can be done with some scripts
20:01 < spot> | ensc: +1
20:01 < ensc> | I wrote (resp. tarted to wrote) such a system for me diploma thesis
20:02 < ensc> | but it's far away from being ready
20:02 < thl> | ensc, yeah, might be a good idea
20:02 < thl> | ensc, how about asking hte list for coments?
20:02 < ensc> | thl: http://enrico-scholz.de/diplom
20:03 < ensc> | afair, I was at 15000 LOC :(
20:03 < thl> | we'll let's look at this idea after FC5 is out
---
19:56 < thl> | I would like multilib for extras
19:56 < thl> | wine.i386 in the x86_64 tree for example
19:56 < thomasvs> | thl: ew
20:03 < thl> | thomasvs, don't like the multilib idea?
20:04 < thomasvs> | thl: I think people who want multilib in that way, should get from both trees explicitly
20:04 < thomasvs> | thl: the only way to improve true 64 bit is to make sure you can get 64-bit only systems installed
20:04 < thl> | thomasvs, wine is a exception
20:05 < thomasvs> | thl: right - so it should be installed by hand, but that's just MO
20:05 < thl> | because a wine.x86_64 would only be able to execute win x64 apps
20:05 < thl> | okay, let's stop this at this point
}}}
== Full Log ==
{{{
18:59 --> | scop (Ville Skytta) has joined #fedora-extras
18:59 * | jeremy will be in and out for fesco today
18:59 * | skvidal is here
19:00 < skvidal> | right on time, for once
19:00 * | scop is partially here
19:00 < skvidal> | scop: which part?
19:00 < scop> | skvidal, you don't want to know :)
19:00 < skvidal> | heh
19:00 * | jeremy refrains from asking if scop is wearing pants ;-)
19:00 --- | thl has changed the topic to: FESCo Meeting in progress
19:00 < skvidal> | jeremy: he could be our own jdub
19:01 < thl> | hi everybody; who's around?
19:01 --> | mschwendt (Michael Schwendt) has joined #fedora-extras
19:02 * | nman64 lurks in the shadows.
19:02 --- | thl has changed the topic to: FESCo Meeting in progress --
19:02 --- | thl has changed the topic to: FESCo Meeting in progress -- Kernel module standardization
19:02 < skvidal> | hi thl
19:02 < skvidal> | I'm around
19:02 * | skvidal runs away from the topc
19:02 < thl> | jeremy, any sign regarding xen changes?
19:03 < jeremy> | thl: they will happen. but xen has to be building again first
19:03 < thl> | :-)
19:03 < thl> | scop, anything else that needs to be discussed regarding kmods
19:04 < scop> | nothing new, I guess
19:04 < scop> | I'll fire some test builds tonight
19:04 < thl> | k, great
19:04 < thl> | then let's proceed
19:04 --- | thl has changed the topic to: FESCo Meeting in progress -- Mass rebuild of Extras for FC5
19:04 < thl> | well, what about orphans?
19:05 * | spot has most of his giant pile of packages rebuilt
19:05 < thl> | some people want to remove those that can be removed safely
19:05 < thl> | thx spot -- better late than never ;-)
19:05 < thl> | but thias didn't rebuild his packages yet
19:05 < ignacio> | It has been discovered that about a dozen or so packages still need the old OpenSSL.
19:05 < thl> | does anybody know why thias did not?
19:06 < skvidal> | thl: is he responding?
19:06 < thl> | skvidal, no, I did not here anything from him
19:06 < thl> | but he was online
19:06 < skvidal> | okay
19:06 < thl> | he fixed xmms
19:06 < thl> | or xmms-foo
19:06 < skvidal> | email him again
19:06 < thl> | k
19:06 < thl> | ignacio, do we have a compat package for it?
19:06 < thl> | ignacio, or do we need one?
19:07 < ignacio> | It's only Extras packages so I would just rebuild those.
19:07 < nirik> | thl: I just replied to that thread with the 3 extras orphans that have dependent packages.
19:07 < nirik> | if we can get someone to maintain those, we can not worry about removing the rest of the orphans.
19:08 < ignacio> | cyrus-imapd-nntp cyrus-imapd-murder up-imapproxy perl-Cyrus pam_mount logjam up-imapproxy tripwire cyrus-imapd proftpd erlang valknut pgadmin3 d4x cyrus-imapd-utils
19:08 < thl> | ignacio, sorry, I can't follow you here...
19:08 --> | jpo (Unknown) has joined #fedora-extras
19:08 < thl> | ignacio, those just need a rebuild? those are orphans?
19:09 <-- | ensc has quit (Remote closed the connection)
19:09 < ignacio> | Sorry, those are the packages that need to be rebuilt. Let me find the owners.
19:09 < ignacio> | For OpenSSL, that is.
19:09 --> | ensc (Enrico Scholz) has joined #fedora-extras
19:09 < nirik> | lua, ots and python-numeric are the 3 orphans I see that have non orphans depending on them.
19:10 < ignacio> | python-numeric is in Core.
19:10 < thl> | nirik, I'm fine with removing the others
19:10 < thl> | mschwendt, you didn't like the idea to much iirc. Still the case?
19:10 < nirik> | ignacio: odd. it's also listed as a orphan in the extras owners.list
19:11 < mschwendt> | should have happened sooner, I think -- I'm not so fond of last-minute removals
19:11 --> | thomasvs (Thomas Vander Stichele) has joined #fedora-extras
19:11 < thl> | mschwendt, how about moving them aside
19:12 < thl> | mschwendt, and if anything breaks we copy them back into the repo
19:12 < mschwendt> | if anything breaks, there are maintainers who don't test their stuff
19:12 < mschwendt> | I think we should remove the orphans at beginning of FE6 devel cycle
19:12 < thl> | well, other opinions?
19:13 < ignacio> | None of the OpenSSL-dependent packages are orphans.
19:13 < thl> | or how about a small vote:
19:13 < nirik> | my problem with orphans is that users will report bugs and they will go into the bit bucket and will get no answer... thats pretty lousy. Better to not provide them at all.
19:13 < mschwendt> | nirik: orphan-owner is monitored
19:14 < thl> | people that want to remove them now paste a "a" here, people that thinke we should remove the orphans later past a "b" into the channel
19:14 < nirik> | oh? cool... by whom?
19:14 < mschwendt> | thl: there are packaged in the repo which do have an owner, but which don't work well - we don't remove them either, but orphan them occasionally (see "elmo", for instance)
19:14 < mschwendt> | nirik: a few, Bill Nottingham, me, ...
19:15 < thl> | I'm still for "putting them aside"
19:16 < spot> | i think we should wait for FC-6
19:16 < spot> | and make some more noise about them being orphaned
19:16 < nirik> | I think moving forward we should do something like: if orphan for more than a month, remove from repo and disable in cvs.
19:16 < thl> | scop, what's your opinion?
19:17 < nirik> | I vote for 'a' (remove them now), but thats just my 2cents... :)
19:17 * | scop awakens
19:17 < thl> | skvidal, jeremy, jpo, ensc ?
19:17 * | ensc tends to 'a'
19:18 < skvidal> | so we have a double edge
19:18 < skvidal> | 1. new people installing fc5 will be confused by broken pkgs in extras
19:18 < skvidal> | 2. old people upgrading from fc4 will get hung up if the packages stop the upgrade from happening b/c of the new ones being non-existent or broken
19:19 < skvidal> | in general I'd say remove them, warn people and maybe allow any of the sponsors to take over the pkg for the maintainer
19:19 < spot> | how many packages are orphaned right now?
19:19 < mschwendt> | skvidal: case 2 would be caught by repoclosure thingy
19:19 < jeremy> | spot: yeah, I think that's a key question
19:19 < scop> | I'm undecided but maybe slightly inclined towards "b"
19:19 < skvidal> | mschwendt: true
19:19 < nman64> | Based upon personal experiences elsewhere, I would recommend 'a', but I don't have a vote here. ;-)
19:19 < ensc> | an FC4 -> FC5 upgrade is a major break; nobody really expects that things work without reconfiguration
19:19 * | warren here now
19:19 < mschwendt> | spot: unknown -- except for http://fedoraproject.org/wiki/Extras/OrphanedPackages
19:20 < mschwendt> | spot: there are some packages marked as orpaned in owners.list which should not be orphans (e.g. Hula)
19:20 < thl> | mschwendt, spot, I'm checking, just wait a minute
19:20 < nirik> | grep extras-orphan owners/owners.list| wc -l 11:15:24
19:20 < nirik> | 51
19:20 < nirik> | yeah, thats approx...
19:20 < thl> | nirik, not all of them are in extras/devel
19:20 < nirik> | ah, true.
19:21 < thl> | spot, look at http://www.fedoraproject.org/wiki/Extras/FC5Status and search for extras-orphan_AT_fedoraproject.org
19:22 < thl> | repoquery says we have 34 orphans in extras/devel/
19:22 < thl> | 23 are arch packages
19:22 < thl> | only those are in the wiki-list
19:22 < jwb> | if it were up to me, i'd say 'a'. i "fixed" an orphaned package for FE4 release and it's sat there since. in retrospect, deleting it would have been better
19:23 < thl> | the problem with orphans imho is:
19:23 < thl> | if we allow them in fc5 we have to deal with them a long time
19:23 < thl> | e.g until fe5 is EOL
19:23 < jwb> | right
19:24 < jwb> | and breakage if they are removed is often a motivator for someone who cares to step up and maintain the package
19:24 < warren> | In my opinion, orphans should be deleted sooner instead of later.
19:24 < warren> | *removed, not deleted
19:24 < thl> | any other arguments? Then let's vote again "remove now" or "remove later" please
19:24 < warren> | remove now
19:24 < nirik> | remove now
19:25 < mschwendt> | warren: do you know what is up with jrb@xxxxxxxxxx and at-poke in Extras?
19:25 < ensc> | now
19:25 * | jeremy is convinced to "remove now"
19:25 < jwb> | nirik, we don't count ;)
19:25 < thomasvs> | remove now
19:25 < jeremy> | mschwendt: I can throw a rock at him later
19:25 < warren> | mschwendt, I talked with jrb today about Extras
19:25 < nirik> | oh yeah, sorry. ;) remove my remove now. ;)
19:25 < spot> | remove now is ok by me.
19:25 < mschwendt> | jeremy, warren: thanks
19:25 <-- | Foolish has quit ("mbop..")
19:25 < warren> | I did "training" of Extras for their team today.
19:25 < thl> | so I take that as "remove now"
19:26 < mschwendt> | thl: including the "potentially orphaned" packages??
19:26 * | scop conveniently changes his opinion: remove now
19:26 < thl> | mschwendt, just to be sure: define potentially orphaned?
19:26 < warren> | Removal doesn't mean lost forever
19:26 < warren> | we still have CVS
19:27 < warren> | and we could keep the removed packages somewhere
19:27 < mschwendt> | like "wesnoth"? it's in good shape, because I updated it for several months, but it still needs a new maintainer
19:27 < thl> | warren, yeah, we should keep them for some month
19:27 < warren> | Removal is meant as 1) responsibility 2) motivator
19:27 < mschwendt> | thl: "potentially" here means somebody is still the owner, but would like to drop the package
19:27 < mdomsch> | mock group
19:27 < bpepple> | mschwendt: Wasn't wesnoth picked up recently? If not, I'd be willing to take it.
19:27 < thl> | mschwendt, I'm fine if those stay
19:28 < thl> | or maybe
19:28 < jwb> | they have to
19:28 < thl> | no, let's remove them
19:28 < mschwendt> | bpepple: it's still listed on the Wiki page -> http://fedoraproject.org/wiki/Extras/OrphanedPackages
19:28 < warren> | Or give it all to bpepple =)
19:28 < thl> | okay, let's move on
19:28 < thl> | gst08 in FE5
19:28 < thl> | gnome-baker is a problem afaics
19:28 < thl> | It needs it
19:29 < warren> | owner?
19:29 < bpepple> | me
19:29 < thomasvs> | thl: as said before, I don't mind offering my packages for it
19:29 * | skvidal makes a note: thomasvs offers his package to people
19:29 < skvidal> | la la la
19:29 < bpepple> | I've got a gstreamer08 package for review, but it's got an error about the rpath still.
19:29 < jwb> | ew
19:29 < thl> | thomasvs, fixing the bug |Jef| has on x86_64 would be a start ;-)
19:29 < mschwendt> | I've had a look at the gst08 review request. issues: where is gstreamer08-plugins-devel? where are the packagers who need gst08?
19:29 < skvidal> | jwb: :)
19:29 < |Jef|> | thl: he cant
19:30 < mschwendt> | bpepple: I cannot reproduce the rpath problems here, but I don't use mock or root.
19:30 < |Jef|> | thl: until the gst08 stuff is in Extras again
19:30 < thomasvs> | thl: yeah, but I have a hard time reproducing the build failure
19:30 < mschwendt> | bpepple: but I've had to add BR libtool automake bison flex
19:30 < thomasvs> | thl: I'm going to work on it again tomorrow on my 20% day
19:30 < thl> | thomasvs, k
19:30 < warren> | 20% day?
19:30 < |Jef|> | thl: gstreamer08-python can not be rebuilt until the gst08 and gst08-plugins are back in tree
19:30 < ensc> | mschwendt: afaik, mock/plague adds these BR implicitly
19:30 < thl> | |Jef|, ohh, yes, that's true :)
19:31 < bpepple> | mschwendt: I was going to put up a gstreamer08-plugins package, also. Just haven't added it yet to bugzilla.
19:31 < thl> | so how do we get gst08 into FE5 fast?
19:31 < |Jef|> | thl: i have..deep issues
19:31 < thomasvs> | thl: well --- what's wrong with putting in the actual specs right before they were removed from core ?
19:31 < thomasvs> | afaik they came from me anyway
19:31 < thomasvs> | warren: 20% day, just like at google - work on something else
19:31 < warren> | cool
19:32 < bpepple> | thl: How about importing the Core spec into FE?
19:32 < thl> | mschwendt, your opinion?
19:32 < thomasvs> | surely a package that comes from core can be trusted to meet the requirements!
19:32 < mschwendt> | I'm lacking packages to test the offered gst08 packages with. :-/
19:33 < spot> | thomasvs: HAHAHAHA
19:33 < thl> | thomasvs, ;-)
19:33 < ignacio> | thomasvs: Not really.
19:33 < bpepple> | It's not like those packages haven't been around for a while.
19:33 < spot> | oh god, it hurts
19:33 < thl> | But let's face it: We need gst08
19:33 < ignacio> | I've seen some, ahem, less-than-optimal packages in Core.
19:33 < warren> | like gnome*
19:33 < thl> | thomasvs, mschwendt, bpepple could you get that done somehow?
19:33 < ensc> | ignacio: some?
19:33 < thl> | even if it's not perfect?
19:33 < thomasvs> | thl: sure
19:33 < bpepple> | No problem.
19:34 < ignacio> | ensc: I'm trying to not be devastatingly negative here.
19:34 < thomasvs> | thl,bpepple: I would just import the latest package that was in core
19:34 < thomasvs> | bpepple: you or me ?
19:34 < thomasvs> | I have the next three days to babysit it through the build system if that matters
19:34 < bpepple> | How about my package for the gst08? It removes a lot of the unnecessary BR.
19:34 < mschwendt> | thomasvs: do you still have the latest rawhide src.rpm of gst80?
19:34 < bpepple> | And adds the missing BR or mock.
19:34 < thomasvs> | but you said you have an rpath problem
19:35 < thl> | okay, so let's make the exception "was in core can be imported to extras" for gst08
19:35 < bpepple> | mschwendt: That's what I built mine from.
19:35 < thomasvs> | mschwendt: not the latest, but the ones I submitted to warren in the first place
19:35 < warren> | thl, that's fine
19:35 < thomasvs> | bpepple: anyway, if yours work (depends on the rpath), put them in
19:35 < warren> | the gst08 package that was in rawhide I "reviewed"
19:35 < warren> | it wont break stuff, it isn't pretty
19:35 * | spot would much rather see it have a fast formal review
19:36 < warren> | if someone is willing to do the work, go ahead
19:36 < thl> | spot, agreed
19:36 < thomasvs> | but the last spec that rh used should be in cvs, no ?
19:36 < ignacio> | I tried, but rpaths are being a PITA.
19:36 < spot> | it only takes two people to rush it through.
19:36 < thl> | ignacio, ignore the rpaths
19:36 < thl> | for now
19:36 < bpepple> | spot: Ignacio, I beleve has already given a look at the gst08 package.
19:36 * | ignacio pulls up the review request
19:36 < mschwendt> | ignacio: no rpaths here with a local build of bpepple's src.rpm
19:37 < spot> | bpepple: then have him close out the review req. :)
19:37 < ignacio> | They show up using mock.
19:37 < bpepple> | I'll put up a gst08-plugin package later today, so that can be looked at.
19:38 < thl> | thomasvs, ignacio, thomasvs, mschwendt, would be great if we could have a solution until the next meeting
19:38 < thl> | anyway, let's move on
19:38 --- | thl has changed the topic to: FESCo Meeting -- EOL Policy
19:38 < mschwendt> | the rpaths will make it fail to build in the buildsystem, so NEEDSWORK anyway, right?
19:38 < thl> | bahh, I need to find time for it
19:38 < thl> | and talk to those Security SIG people
19:38 < thl> | let's ignore that for today
19:39 < thl> | okay?
19:39 --- | thl has changed the topic to: FESCo Meeting -- Encourage Extras reviews
19:39 < thl> | any new ideas in this area?
19:39 < f13> | wheeee....... EOL policy will come into effect sometime around when FC7 goes EOL... (;
19:39 < warren> | improve documentation
19:39 < thl> | f13, ;-)
19:40 < thl> | warren, well, agreed
19:40 < thl> | warren, who takes the job?
19:40 < warren> | Me
19:40 --> | Foolish (Sindre Pedersen Bjordal) has joined #fedora-extras
19:40 < thl> | when?
19:40 < warren> | I'll have a lot more time when we have FC5 out the door
19:40 < thl> | k
19:40 < thl> | anything else?
19:40 < warren> | not much
19:41 < warren> | It's just that I've had to explain the documentation to people in person far too many times lately
19:41 < warren> | because the documentation is too much details in one place, in the wrong order, etc.
19:41 < warren> | it needs to be split out
19:41 < warren> | maybe with some flow diagrams for visual aids
19:41 < warren> | with links to deeper details
19:42 < thl> | okay, just do it,
19:42 < warren> | nod
19:42 < thl> | so, moving on
19:42 --- | thl has changed the topic to: FESCo Meeting -- Broken deps report
19:42 < thl> | mschwendt, any news?
19:42 < thl> | or should we revisit this after FC5 is out to work on some details?
19:42 < mschwendt> | memory consumption on Rawhide is 3x to 4x higher than on FC4
19:43 < thl> | ?
19:43 < thl> | when runnig the script?
19:43 < mschwendt> | yes, it breaks my normal machine
19:43 < mschwendt> | which starts swapping
19:43 < mschwendt> | there's also a bug somewhere in the Yum backend it seems
19:43 <-- | Foolish has quit (Remote closed the connection)
19:44 < mschwendt> | sometimes it reloads the gzipped xml files again and again
19:44 < warren> | not beagle ?
19:44 < skvidal> | mschwendt: there is?
19:44 < mschwendt> | well, I could not complete a single run on rawhide yet
19:46 < thl> | so what do we do? Revisit this after FC5?
19:46 < skvidal> | mschwendt: you have an old sqlite, maybe?
19:47 < mschwendt> | I keep running it regulary on FC, but complete automation has moved a step into the future
19:47 < mschwendt> | maybe it just needs to start with a clean yum cache dir or so
19:47 < mschwendt> | that won't solve the memory consumption problem, however
19:47 < skvidal> | mschwendt: I've not gotten any bugs about memory usage in rawhide at all
19:47 < mschwendt> | skvidal: would be a Python issue anyway
19:48 < skvidal> | mschwendt: or sqlite
19:48 < mschwendt> | it's the python process which grows like hell
19:48 < skvidal> | the python-sqlite module
19:48 < skvidal> | it was a bug in there last time that caused the memory problems.
19:48 < skvidal> | paul fixed it
19:48 < mschwendt> | this is up-to-date rawhide, I believe
19:48 < mschwendt> | python-sqlite-1.1.7-1.2
19:49 < thl> | mschwendt, skvidal can you try to sort this out after the meeting and/or on the lists?
19:49 < skvidal> | err yah
19:49 < thl> | k, thx
19:49 --- | thl has changed the topic to: FESCo Meeting -- Weekly sponsorship nomination
19:49 < thl> | anyone?
19:49 --> | Foolish (Sindre Pedersen Bjordal) has joined #fedora-extras
19:50 --- | thl has changed the topic to: FESCo Meeting -- separate lists for bugzilla-spam
19:50 < thl> | warren ?
19:50 < jwb> | do it
19:50 < warren> | lists are created, I only need to do it now
19:51 < thl> | anything that still needs to be discussed?
19:51 < warren> | not really, I think we're good
19:51 < thl> | k, great
19:51 < warren> | only I'm just slow
19:51 --- | thl has changed the topic to: FESCo Meeting -- FE-NEEDSPONSOR tracker bug
19:51 < thl> | warren, that's still on the schedule
19:51 < thl> | we have such a bug now
19:51 < thl> | anything we need to do with it?
19:52 < thl> | it was your task, but somebody else created that bug
19:52 < warren> | I wasn't among the supporters of this idea
19:52 < thl> | ?
19:52 < warren> | oh
19:52 < warren> | only a process issue
19:52 < mschwendt> | :) does anyone think the extra ticket helps?
19:52 < warren> | dunno
19:53 < thl> | I think it does, but I'm not 100% sure
19:53 < mschwendt> | does anyone think it hurts the process? ;)
19:53 < bpepple> | Well, it makes it easy to know who's package I can't approve.
19:53 < mschwendt> | bpepple: right
19:53 < thl> | I'll remove it from the schedule
19:53 < thl> | if somebody does not like it complain to the list
19:53 < mschwendt> | is its usage documented in the wiki?
19:54 < thl> | I don't thinks so
19:54 < thl> | warren, could you handle that when you work on the docs?
19:54 < thl> | just a link and s short para should be enought afaics
19:54 < warren> | yup
19:55 < thl> | warren, thx
19:55 < warren> | no prob
19:55 --- | thl has changed the topic to: FESCo Meeting -- Free discussion
19:55 < thl> | anything?
19:55 < ignacio> | I though I had something, but I can't remember now.
19:55 < skvidal> | I think giraffes are cool
19:55 < skvidal> | oh
19:55 < jwb> | are we still waiting for plague 0.5 before discussing scratch builds again?
19:55 < spot> | i like pork.
19:55 < skvidal> | free discussion about extras..
19:55 < skvidal> | whoops
19:56 < thl> | jwb, yes, I think so
19:56 < jwb> | k
19:56 < mschwendt> | *oink*
19:56 < jwb> | i like beef
19:56 < ignacio> | Oh, I remember.
19:56 < skvidal> | I like big butts, and I cannot lie
19:56 < jwb> | lol
19:56 < thl> | I would like multilib for extras
19:56 < mschwendt> | ignacio: we certainly won't ignore such an rpath
19:56 < skvidal> | I would like to spoon my eyes out
19:56 < thl> | wine.i386 in the x86_64 tree for example
19:56 < mschwendt> | ignacio: it's in /var/tmp!
19:56 < thomasvs> | thl: ew
19:56 < ignacio> | I was talking to jbj, and he was saying that a number of things that we currently check for in the review can easily be automated.
19:57 < spot> | jbj also did a lot of drugs in his youth.
19:57 < skvidal> | yes
19:57 < skvidal> | yes he did
19:57 < thomasvs> | and he has an earring
19:57 < spot> | the difficulty with automating the review tasks is that there are far too many special case scenarios that have to be dealt with
19:58 --> | finalzone (gaim) has joined #fedora-extras
19:58 < spot> | where an intelligent human can adapt, an automated process can not.
19:58 < ignacio> | Not automating the review tasks, but automating the things the review checks for.
19:58 < spot> | thats what i mean.
19:58 < ignacio> | Such as calling ldconfig, and so on.
19:59 < spot> | given enough time, i'm sure people will find exception cases
19:59 < spot> | like packages that include so files, but dont want to call ldconfig
19:59 < thl> | ignacio, is writting a script or app that checks this stuff really worth the effort?
19:59 * | bpepple thinks the fedora-qa script does a lot of that.
20:00 < ignacio> | Maybe.
20:00 < spot> | it might be helpful for reviewers, but not as a replacement
20:00 < ignacio> | There does need to be some looking into it done.
20:00 <-- | mschwendt has quit ("Lost terminal")
20:00 < ignacio> | Or maybe just should, but still.
20:00 < jwb> | there's a fedora-qa script?
20:00 <-- | finalzone has quit (Client Quit)
20:00 < nirik> | http://fedoraproject.org/wiki/AurelienBompard
20:00 < nirik> | for the fedora-qa script. ;)
20:01 < ignacio> | Why isn't that in UsefulScripts?
20:01 < ensc> | I would think about a system which checks submitted packages (e.g. with rpmlint, various installation tests, ...), tells the results into the review system and human reviewer can decide whether the package can be accepted
20:01 < jwb> | why isn't there a package for it!?
20:01 < bpepple> | jwb: Yup, it checks a lot of the items (dup BR's, etc.)/
20:01 < ensc> | but that's nothing which can be done with some scripts
20:01 < spot> | ensc: +1
20:01 < ensc> | I wrote (resp. tarted to wrote) such a system for me diploma thesis
20:02 * | spot has to go eat lunch now, the food is getting cold
20:02 < ensc> | but it's far away from being ready
20:02 < thl> | ensc, yeah, might be a good idea
20:02 < thl> | ensc, how about asking hte list for coments?
20:02 < ensc> | thl: http://enrico-scholz.de/diplom
20:03 < ensc> | afair, I was at 15000 LOC :(
20:03 < thl> | we'll let's look at this idea after FC5 is out
20:03 < thl> | anything else?
20:03 < thl> | thomasvs, don#t like the multilib idea?
20:04 < thomasvs> | thl: I think people who want multilib in that way, should get from both trees explicitly
20:04 < thomasvs> | thl: the only way to improve true 64 bit is to make sure you can get 64-bit only systems installed
20:04 < thl> | thomasvs, wine is a exception
20:05 < thomasvs> | thl: right - so it should be installed by hand, but that's just MO
20:05 < thl> | because a wine.x86_64 would only be able to execute win x64 apps
20:05 < thl> | okay, let's stop this at this point
20:06 < thl> | anything else
20:06 * | thl will close the meeting in 30
20:06 * | thl will close the meeting in 20
20:06 * | thl will close the meeting in 10
20:06 < thl> | MARK Meeting end
20:06 < thl> | thx guys
}}}
--
Thorsten Leemhuis <fedora@xxxxxxxxxxxxx>
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
