Extras/SteeringCommittee/Meeting-20061005

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 | 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 | Trying to upstream means working with upstream to try to get it in. 0:17 <   dgilmore> | thl: we cant 0:17 | 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 | +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 | 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 | +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 |  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 | 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 | 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 | 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 | 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 | 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 | nirik: Thanks.  lmacken is packaging and I've been reviewing about one a week (lots of other stuff to do.) 0:58 | 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 | 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 | 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