From Fedora Project Wiki
< Extras | SteeringCommittee
Log
0:00 --- | thl has changed the topic to: FESCo meeting in progress -- init
0:00 < thl> | Hi all!
0:00 < thl> | who's around?
0:00 < c4chris> | thl, hi
0:00 < jima> | delero: yes. *quiets down and goes to rabble section*
0:00 * | abadger1999 is here
0:00 * | bpepple is here, though I have to leave early today.
0:00 * | cweyl is here (rabble)
0:01 * | nirik is sitting in the rabble seats.
0:01 * | rdieter is here.
0:01 * | mmcgrath here
0:01 * | dgilmore is here
0:01 < thl> | scop and spot won't be around today afaik
0:01 < jima> | i guess the fesco meeting may soon qualify as a spectator sport.
0:01 --- | thl has changed the topic to: FESCo meeting in progress -- M{ae}ss-Rebuild
0:01 < thl> | scop not around
0:01 < thl> | andything left to discuss?
0:02 < thl> | c4chris, thx for rebuilding the stuff btw
0:02 < c4chris> | should be all peachy, no?
0:02 < rdieter> | looks like a done-deal.
0:02 < c4chris> | thl, np
0:02 < dgilmore> | thl: i think its all done
0:02 < thl> | k, so let's move on
0:02 --- | thl has changed the topic to: FESCo meeting in progress -- Use comps.xml properly
0:03 < thl> | dgilmore, were there ever attemts to automate the pushing of comps?
0:03 < dgilmore> | thl: not yet
0:03 * | jwb is here
0:03 < thl> | well, does anybody update it now and them?
0:03 < c4chris> | I'll prepare the PackageStatus page and cleanup comps
0:03 < dgilmore> | thl: ive finally got on top of everything at work. so im going to look at it now. though someone else was also looking at it
0:03 < thl> | we probably should at least push it out once before FE6
0:04 < dgilmore> | thl: i think jeremy does it now
0:04 < thl> | dgilmore, k, thx
0:04 < thl> | so let's move on
0:04 --- | thl has changed the topic to: FESCo meeting in progress -- Activate legacy in buildroots
0:04 < thl> | dgilmore, you again :)
0:04 < dgilmore> | thl: its done
0:04 < thl> | is it documented in the wiki yet?
0:04 < dgilmore> | thl: that i havent done
0:05 * | dgilmore goes wiki editing now
0:05 < thl> | k; I'll remove it from the schedule when wiki editing was done
0:05 --- | thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report
0:05 < thl> | rdieter, tibbs, abadger1999 ?
0:05 < tibbs> | Still no quorum.
0:05 < rdieter> | passed: http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles
0:06 < rdieter> | then talked about trying to make more progress (ie, dealing with absent members)
0:06 < rdieter> | that's about it.
0:07 < thl> | okay, rdieter thx
0:07 --- | thl has changed the topic to: FESCo meeting in progress -- approve kmod's
0:07 < thl> | do you like the docs I prepared?
0:07 < thl> | okay for everyone?
0:07 < jwb> | the ones about getting things upstream?
0:08 < thl> | yes
0:08 < thl> | and the plit for packageing kmods and the extras policy
0:08 < bpepple> | Seemed ok from my quick look at it.
0:08 < c4chris> | fine with me
0:08 < jwb> | yes, i think they're good
0:09 < nirik> | so is zaptel-kmod ready for voting on then?
0:09 < thl> | nirik, good question
0:09 < thl> | let's get forward with the easy one first: gfs-kmod
0:09 < thl> | I send the details to the list
0:09 < bpepple> | nirik: I thought they were going to discuss it before deciding if they wanted to go upstream.
0:10 < thl> | gfs-kmod +1 (even if it will never head upstream, but I think this compatibility case is okay, too)
0:10 < c4chris> | gfs-kmod +1
0:10 < dgilmore> | thl: gfs +1 as long as we keep it for a certain time frame say fc6 and fc7 only
0:10 < rdieter> | gfs-kmod +1
0:10 < bpepple> | gfs-kmod +1
0:10 < thl> | dgilmore, we can't et a certain time frame
0:10 < tibbs> | +1
0:10 < thl> | because imply removing it would break people system
0:10 < thl> | o we ship it a long a there i maintainer
0:10 < tibbs> | As long as there's a maintainer for it, I see no reason why it can't be in the distro forever.
0:11 < jwb> | i think in this case, gfs is maintained by RH. so RH is upstream. +1
0:11 < dgilmore> | thl: by time frame i mean particular releases only
0:11 < dgilmore> | so we dont put it in fc8
0:11 < thl> | dgilmore, same problem;
0:11 < thl> | users system breaks after updating from fc7 to fc8
0:11 < dgilmore> | thl: there will be a point you just have to migrate
0:11 < thl> | dgilmore, sure
0:12 < jwb> | dgilmore, i think that point will be dictated by RH
0:12 < thl> | but we can't force people to migrate
0:12 < jwb> | dgilmore, as in when RHEL drops support for GFS
0:12 < dgilmore> | jwb: thats fine its a clear point even if not yet determined
0:12 < thl> | dgilmore, we talked about limiting kmod's only for a certain timeframe in the past already
0:12 < thl> | it doesn't work
0:12 < nirik> | bpepple: He implied that they were going to move forward with upstreaming it... "Given that, I'll talk to our people here and start the process,"
0:13 < thl> | I'd really like it, too, but I really also think it does not work in real life
0:14 < thl> | quite quiet now
0:14 < thl> | dgilmore, okay if we move on?
0:14 < dgilmore> | thl: sure
0:14 < thl> | k, thx
0:14 * | thl considers gfs-kmod approved
0:14 < thl> | so what about zaptel?
0:14 < dgilmore> | zaptel i say +1
0:15 < bpepple> | nirik: My interpretation from his comment in #56 was that they would discuss moving upstream, not that they were going to.
0:15 < thl> | I don't feel completely compfortable with it, but yeah, zapte +0,75
0:15 < tibbs> | I have always been +1 for zaptel.
0:15 < c4chris> | +1
0:15 < tibbs> | but I imagine that we should wait to see what they're going to do.
0:15 < dgilmore> | bpepple: yes but i think that they are realising that they wont keep it out forever and it will be in there benefit to upstream it
0:15 < jwb> | +.5
0:15 < thl> | as long as dwmw2 has no other plans where a kmod in extras might hurt
0:15 < tibbs> | One question: if they submit it upstream, and Linux says no, then what?
0:16 < tibbs> | s/Linux/Linus/
0:16 < thl> | tibbs, that can and will always happen
0:16 < thl> | but normally you have to fix stuff and submitt it again
0:16 < dgilmore> | tibbs: they resolve the issues and resumbit
0:16 < jwb> | tibbs, Linus has been known to change his mind
0:16 < thl> | it will get merged when you do a good job
0:16 < jwb> | it's the _effort_ i want to see. not the end result
0:16 < thl> | jwb, +1
0:17 < nirik> | bpepple: yeah, I suppose it could be read that way... do we wait for them to say "We intend to submit it someday" that could take a while for them to do...
0:17 < abadger1999> | jwb: +1
0:17 < bpepple> | jwb: +1
0:17 < tibbs> | So it's the mere act of them trying to upsteam, even if they know it won't succeed, that makes the module acceptable?
0:17 < thl> | tibbs, well, in real life it would me more
0:17 < thl> | tibbs, but how to enforce this?
0:17 < thl> | tibbs, the only way to enforce this is: ship no kmod's at all
0:17 < bpepple> | nirik: I'd like to give them time to decide if they are going to actually submit it upstream.
0:17 < abadger1999> | Trying to upstream means working with upstream to try to get it in.
0:17 < dgilmore> | thl: we cant
0:17 < abadger1999> | As opposed to sabotaging the effort from the start.
0:18 < jwb> | if nothing else, it will at least get reviewed
0:18 < thl> | we can also wait some more weeks (2? 4?) before we really approve zaptel for FE
0:19 < bpepple> | thl: +1
0:19 < dgilmore> | is anyone going to vote - against zaptel's inclussion?
0:19 < thl> | maybe digitum start with the process by then (but I think it'll take a bit longer)
0:19 < nirik> | it's been delayed this long... I suppose we could wait more.
0:19 < thl> | let me talk to dwmw2 and ask him for his concrete plans
0:19 < dgilmore> | we have 4.25 + right now
0:19 < thl> | and get back to zaptel next week
0:19 < nirik> | you just want a definitive statement "we intend to upstream at some point" ? or you want to see a submission on the kernel list ? or ?
0:20 < rdieter> | zaptel: +1 from me
0:20 < bpepple> | nirik: That's all I'm looking for.
0:20 < nirik> | just submitted a new comment from digium...
0:20 < jwb> | nirik, ideally a submission to the list. but at least a statement of intent to do so
0:20 < thl> | nirik, a definitive statement would be a good thing
0:20 < nirik> | see if it meets your questions?
0:20 < dgilmore> | thl: i think wmw2 is planning on useing either openpbx or redo the parts of asterisk that need zaptel
0:20 < nirik> | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583
0:20 < bpepple> | just a statement would be fine for me.
0:20 < nirik> | ie, Kevin from digium just added a comment...
0:21 < dgilmore> | i count 5.25+ thats enough to have it passed correct?
0:21 * | thl votes for "let's wait another week" now
0:21 < bpepple> | thl: +1
0:22 < ixs> | mhm.
0:22 < nirik> | " I really do want to move this
0:22 < nirik> | direction now that I have had more time to consider it and talk to members of
0:22 < nirik> | the community about it, but I need to ensure that the rest of the Digium team is
0:22 < nirik> | behind it too.
0:22 < nirik> | "
0:22 < dgilmore> | thl -1
0:22 < dgilmore> | but it wont hurt anything
0:22 < ixs> | I talked with a friend yesterday. There seem to be several zaptel clones, which are functionally the same, but have better policies.
0:22 < ixs> | we might wanna prefer these in FE.
0:22 * | thl really wants to wait after reading that statement
0:22 < thl> | ixs, submitt zaptel to lvn if you want ;-)
0:22 < dgilmore> | ixs: i have a digium and a clone T1 card both using the same driver and both work great
0:23 < rdieter> | ok, wait +1. I bet clones in Extras will get them to move faster.
0:23 < c4chris> | ok, wait one more week...
0:23 < ixs> | thl: sorry. ;D I'm not gonna submit zaptel, I have no hardware to support it.
0:23 < thl> | k, so let's move on
0:23 < nirik> | There is also the matter of dwmw2's plans...
0:23 < nirik> | ie, if things will work with and without it...
0:23 --- | thl has changed the topic to: FESCo meeting in progress -- Sponsorship nominations
0:24 < thl> | Chris Stone got several +1 on the lists
0:24 < thl> | I'll consider him approved for sponser-status if I hear no yelling here
0:24 --- | Tjikkun_ is now known as Tjikkun
0:24 < thl> | while I wait for yelling: any new nominations?
0:25 < dgilmore> | +1 for chris stone
0:25 < abadger1999> | +1 he knows his stuff
0:25 < tibbs> | I have no new nominations at this time.
0:26 < thl> | okay, I'll upgrade Chris Stone
0:26 < thl> | no new nominations in sight, so let's move on
0:26 --- | thl has changed the topic to: FESCo meeting in progress -- EPEL
0:26 * | bpepple has to leave.
0:26 < thl> | so, the current plan is in the wiki in the FESCo schedule
0:26 < c4chris> | bpepple, later
0:26 < thl> | bpepple, cu
0:26 * | mmcgrath checking
0:26 < bpepple> | later.
0:27 < thl> | mmcgrath, see the status section
0:27 < dgilmore> | thl: things should be good to go need some branches to test things and either disable checkbuildroot or give some love to rpmdevtools
0:27 < thl> | mmcgrath, http://www.fedoraproject.org/wiki/Extras/Schedule/EnterpriseExtras
0:27 < mmcgrath> | link?
0:27 < thl> | mmcgrath, ;)
0:28 < thl> | dgilmore, just creating some branches and simply start is the current proposal
0:28 < ixs> | btw: we should see how we get some rhel cds to the EPEL maintainers.
0:28 < mmcgrath> | dgilmore: am I correct in assuming all we need is 1) a cvs branch, 2) a place to sign the packages and 3) a place to publish the packages?
0:28 < dgilmore> | thl: i suggested konversation and rpmdevtools
0:28 < ixs> | otherwise they might not be able to test their packages.
0:28 < thl> | dgilmore, I suggest we start with rpmdevtools
0:28 < mmcgrath> | ixs: centos will work fine.
0:28 < jwb> | ixs, they can use CentOS
0:28 < thl> | dgilmore, and we activate it after it was build
0:28 < thl> | and then some other packages
0:29 < dgilmore> | mmcgrath: really all we need is branches we will need to setup the Makefiles and decide on where to push them
0:29 < mmcgrath> | k, who's going to be our key holders?
0:29 < dgilmore> | signing will be in the same place as current extras
0:29 < thl> | mmcgrath, the same people that hold the keys for FE
0:29 < mmcgrath> | is that fine with them?
0:29 < ixs> | mmcgrath: centos is similar right. But I'd fear that the "filing off the serials" might affect the end result for the packager. I've seen some interesting "os detection scripts" e.g.
0:29 < thl> | mmcgrath, I assume it is
0:30 < dgilmore> | mmcgrath, thl: could very well be. could be the same key even
0:30 < mmcgrath> | ixs: then they need to be less interesting.
0:30 < thl> | dgilmore, same key +1
0:30 < mmcgrath> | different repo different key.
0:31 < thl> | ixs, the centos vs. RHEL thing was discussed already; I don't want to go through it again...
0:31 < thl> | mmcgrath, okay, why not
0:31 * | mmcgrath might be too caught up in sox complance :D
0:31 < ixs> | mmcgrath: *shrug* just giving them some promo cd might be easier though. and i dunno, but the "it's for rhel, but use centos for maintainance" might not be a good idea, marketing-wise. but that's not a FE concern, but more for RH.
0:31 < ixs> | thl: fine.
0:31 < ixs> | we'll skip it.
0:31 < dgilmore> | mmcgrath: you want to generate a key and then we can decide who will do the pushes
0:32 < mmcgrath> | I'm fine with the same people signing it.
0:32 < mmcgrath> | Actually who does do the signing now?
0:32 < mmcgrath> | f13?
0:32 < thl> | mmcgrath: scop, skvidal, mschwendt, jeremy, ...
0:32 < thl> | warren
0:32 * | mmcgrath wonders who curses my name every time nagios-plugins gets updated.
0:32 < thl> | and dcbw
0:32 * | dgilmore to, they could extend the existing push scripts failyl easily i would think
0:32 < thl> | those are all iirc
0:32 < mmcgrath> | I *guess* they'll do ;-)
0:33 < f13> | mmcgrath: hrm? whats the question?
0:33 < mmcgrath> | I was just wondering who signs our extras packages and would they also sign the epel packages.
0:33 < dgilmore> | thl: i think thats all
0:33 < thl> | okay, let's move on:
0:33 < mmcgrath> | dgilmore and I can meet after the meeting and try to get a test build pushed through once the actual branch is approved.
0:33 < thl> | I think we agreed to create a testing branch?
0:34 < thl> | and use it for the initial EPEL steps?
0:34 < mmcgrath> | fine with me epel-testing?
0:34 < thl> | mmcgrath, that would be great
0:34 < f13> | mmcgrath: oh. I don't know who signs extras packages. I have no hand in it.
0:35 < rdieter> | thl: testing branch as in separate cvs branch, or testing repo? I'm definitely for the latter, not sure about the former.
0:35 < mmcgrath> | dgilmore: you have a block of time today to get together and do that?
0:35 < thl> | rdieter, only repo, not in cvs
0:35 < mmcgrath> | rdieter: +1
0:35 < dgilmore> | mmcgrath: yep i can make one
0:35 < thl> | if we need it in cvs create it later
0:35 < thl> | but I don't think we need a testing branch in cvs
0:35 < mmcgrath> | should we create an epel cvs branch then identical to the current devel branch?
0:35 < mmcgrath> | but with no packages.
0:36 < mmcgrath> | I'll start with ytalk, simple, no deps taht I know of.
0:36 < thl> | mmcgrath, I think we simply create a EL4 branch in cvs
0:36 < dgilmore> | mmcgrath: yeah add rpmdevtools and konversation :D
0:36 < thl> | that's a copy from FC3
0:36 < thl> | then update what needs to be updated
0:36 < thl> | and build it
0:37 < mmcgrath> | but we don't want to auto-copy packages over do we?
0:37 < c4chris> | mmcgrath, no
0:37 < abadger1999> | mmcgrath: No auto-copy
0:38 < thl> | so, where to upload stuff?
0:38 < mmcgrath> | k, so I'll make an emtpy EL-4 branch and stick ytalk, rpmdevtools and konversation in it.
0:38 < thl> | http://download.fedora.redhat.com/pub/fedora/linux/extras/el/testing/el5 ?
0:38 < mmcgrath> | Ill also create lookaside cache for it.
0:38 < thl> | mmcgrath, wait
0:38 < thl> | what do you mean by EL-4 branch
0:38 < mmcgrath> | oh wait, no. extras lookaside cache will be fine.
0:38 < dgilmore> | mmcgrath: we should be able to us the existing extras lookasisde cache
0:38 < thl> | what I'd like to see is this:
0:38 < tibbs> | I'm kind of at a loss as to why an IRC client would be a server application.
0:39 < thl> | currently we have package-foo/{devel,FC-5,FC-4}
0:39 < dgilmore> | tibbs: who said anything about server applications?
0:39 < mmcgrath> | thl: nod
0:39 < thl> | and what I want is: package-foo/{devel,FC-5,FC-4,EL-4}
0:39 < ixs> | tibbs: el is client as well.
0:39 < mmcgrath> | thl: yeah, thats the plan.
0:39 < thl> | okay, cuted wanted to be sure
0:40 < thl> | so, where to upload stuff?
0:40 < thl> | http://download.fedora.redhat.com/pub/fedora/linux/extras/el/testing/el4 ?
0:40 < thl> | http://download.fedora.redhat.com/pub/fedora/linux/extras/el/testing/4 ?
0:40 < mmcgrath> | thl: we might have to re-visit that one. I honestly don't know the full path extras takes to get to where it ends up.
0:40 < thl> | http://download.fedora.redhat.com/pub/fedora/linux/extras/testing/el4?
0:41 < thl> | mmcgrath, sorry, revisit what?
0:41 < mmcgrath> | if we're going to put it there lets stay consistant..
0:41 < dgilmore> | mmcgrath: It gets pushed to the master repo and from there its pulled into download.fedora.redhat.com and then out to the world
0:41 < c4chris> | I like http://download.fedora.redhat.com/pub/fedora/linux/extras/testing/el4
0:42 < thl> | c4chris, and the stable repo later?
0:42 < thl> | http://download.fedora.redhat.com/pub/fedora/linux/extras/el4
0:42 < mmcgrath> | Actually it should probably go http://download.fedora.redhat.com/pub/epel/linux/extras/4/
0:42 < c4chris> | yes
0:42 < thl> | c4chris, that will get complicated for mirrors that don#t want to mirror el stuff
0:42 < mmcgrath> | thl: ignore my revisit comment.
0:42 < thl> | mmcgrath, k :)
0:42 < c4chris> | thl, ah, didn't think about this
0:43 * | thl votest for http://download.fedora.redhat.com/pub/fedora/linux/extras/el/{,testing/}4
0:43 * | dgilmore needs to go eat
0:43 < mmcgrath> | quick question.
0:44 < mmcgrath> | bah, nevermind. No question :D
0:44 < thl> | mmcgrath ?
0:44 < thl> | okay :)
0:44 * | thl still votes for http://download.fedora.redhat.com/pub/fedora/linux/extras/el/{,testing/}4 and will wait for other opinions now
0:44 * | mmcgrath is conflicted about it.
0:45 < c4chris> | thl, ok
0:45 < thl> | mmcgrath, any better idea?
0:45 < c4chris> | mmcgrath, what's your concern?
0:45 < mmcgrath> | but I don't have really strong feelings one way or the other, I'll defer.
0:45 < mmcgrath> | does /pub/fedora/ imply stuff for fedora or stuff from fedora?
0:46 < adrianr> | I think also that http://download.fedora.redhat.com/pub/epel/linux/extras/4/ makes also more sense for me
0:46 < ixs> | thl: i prefer your choice over the epel stuff.
0:46 < thl> | mmcgrath, we can find a better place later if we want to
0:46 < ixs> | that way it is clear, it is a fedora related project
0:46 < thl> | one without the fedora in the url
0:46 < thl> | and ixs is correct: it is a fedora related project
0:46 < mmcgrath> | yeah, we don't even have a single package built yet :D
0:47 * | mmcgrath always thought it was a place for stuff for fedora.
0:47 < rdieter> | imo, go with thl's suggestion (for now at least)
0:47 < rdieter> | oops, gotta go, work emergency...
0:47 * | dgilmore back
0:47 < mmcgrath> | Honsetly I don't know who runs download.fedora.redhat.com.
0:48 < thl> | adrianr, I'll try to evaluate if that's possible
0:48 < thl> | let's revisit the porper url next week
0:48 < thl> | well, a summary:
0:48 < mmcgrath> | I think its one of the internal rh servers so we'll probably have to run it by them too. (stuff for next week)
0:48 < thl> | dgilmore and mmcgrath create some test branches in cvs
0:48 < thl> | and will get some packages build
0:49 < thl> | and look at what needs to be changed in the Makefiles and or on the buildsys
0:49 < thl> | we create a new key for signing
0:49 < thl> | but leave the packages on the buildhost for now
0:49 < thl> | that's okay for everyone?
0:49 < c4chris> | thl, +1
0:49 < ixs> | sounds sensible
0:49 <-- | rdieter has quit (Remote closed the connection)
0:49 < jwb> | yes
0:50 < mmcgrath> | +1
0:50 < abadger1999> | +1
0:50 < dgilmore> | +1
0:50 < thl> | mmcgrath, If you have any question feel free to ping me
0:51 --- | thl has changed the topic to: FESCo meeting in progress -- free discussion around extras
0:51 < thl> | so, what elase do we want to discuss?
0:51 < thl> | building against dietlibc?
0:51 < thl> | package database?
0:51 < nirik> | thl: kevin fleming from digium added yet another comment to zaptel-kmod:
0:51 < nirik> | "Due to travel and other scheduling conflicts we won't even be able to have a
0:51 < nirik> | discussion about this internally until around October 18th or so, so I can't
0:51 < nirik> | give you any commitment until after that discussion occurs."
0:51 < mmcgrath> | thl: nod
0:52 < jwb> | nirik, i take that as a good sign
0:52 < ixs> | so let's pospone the zaptel decision until then?
0:52 < thl> | nirik, thx
0:52 < nirik> | ixs: yeah, that would make sense. ;)
0:52 < jima> | thl: i keep semi-joking about getting fesco to make an official decision on sourceforge Source0 url...dunno if anyone cares, but it gets old having reviewers always suggest "the other way"
0:52 < thl> | ixs, I'll talk to dwmw2 and ask for his opinion
0:52 < thl> | jima, packaging comittee please
0:52 < jima> | ok
0:53 < jima> | thanks :)
0:53 < ixs> | jima: well, reviewers are entitled to their opinion of course, but they are wrong sometimes too. ;D
0:53 < thl> | abadger1999, anything we need to discuss regarding the package database?
0:53 < jwb> | jima, and for what it's worth, i think it's silly to make a rule on that. if sf changes some day, it'll require a revision
0:53 < abadger1999> | I installed a xen guest for testing ysterday.
0:54 < c4chris> | abadger1999, package database ?
0:54 < ixs> | comps.xml?
0:54 < jima> | jwb: hey, even if the rule is "either way is fine," it'd be better than it is now (imo).
0:54 < abadger1999> | The new TurboGears packages are almost approved. (python-tgfastdata and python-cheetah still have to be approved for the new turbogears to go in)
0:54 < abadger1999> | So we're making slow but steady progress.
0:54 < thl> | ixs, comps.xml? We discussed this half an hour ago
0:54 < tibbs> | Yes, those two packages could use some high-priority review lovin.
0:54 < skvidal> | thl: what is this about generating a new key?
0:54 < skvidal> | for fe signing?
0:54 < abadger1999> | c4chris: Yes.
0:54 < thl> | abadger1999, k
0:55 < ixs> | thl: what else do you mean with the package database then?
0:55 < thl> | skvidal, for epel signing
0:55 < jima> | skvidal: for epel signing
0:55 < jima> | thl: jinx!
0:55 < c4chris> | abadger1999, great news!
0:55 < skvidal> | epel?
0:55 < abadger1999> | If anyone wants to review tgfastdata and python-chetah that would help :-)
0:55 < skvidal> | enterprise extras?
0:55 < dgilmore> | skvidal: Extras packages for Enterprise Linux
0:55 < jima> | Extras Packages for Enterprise Linux, iirc
0:55 < thl> | skvidal, Extras Packages for Enterprise Linux
0:55 < skvidal> | ah
0:55 < skvidal> | okay
0:55 < jima> | dgilmore: argh
0:56 < jima> | skvidal: where've you been? ;)
0:56 < dgilmore> | jima: vacation
0:56 < skvidal> | jima: working
0:56 < jima> | ...
0:56 < abadger1999> | c4chris: Are you a member of any sysadmin groups in the account system?
0:56 < jima> | you guys need to get your cover stories straight.
0:56 < nirik> | abadger1999: can possibly look at them this weekend... the review queue is growing again. ;(
0:56 < dgilmore> | jima: skvidal knows better than me
0:56 < c4chris> | ixs, http://fedoraproject.org/wiki/Infrastructure/PackageDatabase
0:56 < c4chris> | abadger1999, no. why?
0:57 < ixs> | c4chris: thx
0:57 < ixs> | looks like a nice feat
0:57 < abadger1999> | nirik: Thanks. lmacken is packaging and I've been reviewing about one a week (lots of other stuff to do.)
0:58 < abadger1999> | c4chris: I've set the packagedb test server up with the fedora accounts system. But you need to be in one of the sysadmin groups for the accounts system to let you in.
0:58 < c4chris> | abadger1999, I see
0:59 < thl> | k, so what about dietlibc ?
0:59 < thl> | do we want to ignore it?
0:59 < c4chris> | abadger1999, how do I become a member there ?
0:59 < thl> | or is this a topic for the packaging committee?
0:59 < tibbs> | Not sure the packaging committee would want this.
0:59 < c4chris> | thl, I have a slight problem having FE packages linked against dietlibc
1:00 < tibbs> | But even if it did, it would be nice to know what extras folks think.
1:00 < abadger1999> | c4chris: You apply and someone sponsors. But mmcgrath might have a better idea of which group would have the appropriate amount of access.
1:00 < daniel_hoza> | certain packages will misbehave when linked against glibc.
1:00 < daniel_hoza> | due to features, not bugs, in glibc.
1:00 < c4chris> | daniel_hozac, Oh
1:00 * | mmcgrath not paying attention. Whats going on?
1:00 < thl> | c4chris, I think linking against dietlibc or other libc packages should always be approved by FESCo
1:01 < tibbs> | Can you link dynamically against dietlibc?
1:01 --> | rdieter (Rex Dieter) [] has joined #fedora-extras
1:01 < thl> | tibbs, no idea
1:01 < c4chris> | mmcgrath, abadger1999 maybe we pursue this later at admin meeting ?
1:01 < daniel_hoza> | tibbs: it's possible.
1:01 < delero> | tibbs: i think it would defeat the purpose
1:01 < abadger1999> | mmcgrath: I'll hop over to f.admin to fill you in.
1:01 < tibbs> | Defeat what purpose?
1:02 < dgilmore> | tibbs, thl: i would say its ok to link against dietlibc but it should be dynamic if at all possible
1:02 < tibbs> | Static linking is almost never what we want in a distro where we care about security issues.
1:02 < delero> | tibbs: of avoiding the run-time dyn link overhead
1:02 < delero> | tibbs: couldn't agree more
1:03 < tibbs> | Do the packages under consideration include private copies of dietlibc?
1:03 < c4chris> | tibbs, yes, that's my feeling too
1:03 < daniel_hoza> | tibbs: of course not.
1:03 < tibbs> | Or is there already a dietlibc package in Extras?
1:03 < thl> | dgilmore, that might open the door for a lot of confution
1:03 < thl> | and mess
1:03 < thl> | confusion
1:03 < tibbs> | Ah, so dietlibc is indeed in extras already.
1:03 < daniel_hoza> | dietlibc has been in Extras since it was dropped from Core.
1:03 < mmcgrath> | c4chris: come to #fedora-admin
1:04 < thl> | dgilmore, other might want to import and use there faviorite libc of choice
1:04 < tibbs> | So on one hand it seems odd to say that there's this package in extras but extras packages can't use it.
1:04 < dgilmore> | thl: yes it might but if a package needs dietlibc instead of glibc it should be smart enought to know what its doing
1:04 < ixs> | mhm. afaik there are only a handfull of programs which really gain by being linked against dietlibc. mostly this is in the embedded market.
1:04 < thl> | dgilmore, that why I proposed that FESCo approves such packages
1:04 < ixs> | is this really needed for FE/FC?
1:05 < dgilmore> | thl: that could be a good gatekeeper
1:05 < daniel_hoza> | ixs: e.g. util-vserver will run in to security issues if linked against glibc, because glibc might load libraries from untrusted environments.
1:06 < ixs> | daniel_hozac: interesting I didn't knew about that, but it sounds like one of the use-cases for linking against dietlibc. But mostly linking against it is just for size, see the embedded stuff.
1:07 < tibbs> | So I have no problem with dynamically linking against dietlibc. Static linking anything that isn't needed in the initramfs or very early at boot should be right out, though.
1:07 < thl> | would it make sense to build foo once as "foo" against glibc and once as foo-dietlibc ?
1:08 < ixs> | thl: please do not.
1:08 < ixs> | this makes it just difficult on the maintainer if something breaks.
1:08 < thl> | ixs, well, we would only allow that if the maintainer really want this stuff
1:08 < ixs> | if the maintainer wants his package built against glibc and against dietlibc, he is perfectly able to do so by modifying the spec accordingly.
1:08 < ixs> | thl: ohh. okay. just on requests. hmm.
1:09 < ixs> | might be nice if you want fedora as the basis for embedded development. however, I think that is not exactly our target group.
1:09 < delero> | it seems to me that if you're going to dyn link against diestlibc, you might as well use glibc which is always in memory and cache hot
1:10 < thl> | let's stop here
1:10 < thl> | and discuss this further on hte list
1:10 <-- | Sonar_Guy has quit (Remote closed the connection)
1:10 < thl> | anything elase to discuss?
1:10 * | bpepple is back.
1:10 * | thl will close the meeting in 60
1:11 < ixs> | +1
1:11 * | thl will close the meeting in 30
1:12 * | thl will close the meeting in 10
1:12 < thl> | -- MARK -- Meeting End